Data security

[Lamarque V. Souza]

Em Thursday 05 January 2012, Martin Gräßlin escreveu:
> On Thursday 05 January 2012 20:23:12 Marco Martin wrote:
> > Hi all,
> > 
> > there is a thing that is still missing pretty much completely, and was
> > part of the feature plan since the beginning...
> > 
> > it's an (admittely) pretty vague security model for the data stored on
> > the device.
> > 
> > now, this can mean different things:
> > * security of the device itself against stealing: how much can be done
> > about is kinda limited, apart some usual, as low level as possible
> > things such as full disk encryption (and possibly some way to shut it
> > down remotely). This is something that would add a real value compared
> > to other mobile platforms around
> 
> Full disk encryption is a nice thing, but
> * you need to enter the passphrase and in case that the complete disk is
> encrypted it has to be before the kernel is loaded, that is IMHO pretty
> much impossible without a keyboard

	With a proper configured initrd and ksm enabled kernel we can try 
creating a touch enabled window with a numpad to enter the key, like 
smartphones do when entering the pin for the sim card.

> * even if we only encrypt the home folder we have the problem of opening
> the folder before PA is started.
> * if a running system (standby or really running) is lost/stolen the disk
> encryption does not help as a) the key is stored in RAM and b) PA does not
> require a password to unlock and c) even if it would require some password
> mechanismn it cannot be secure due to the constraints in input device

	Have not used disk encryption before, does it need to keep the key in 
RAM after mounting the partition? If not then if we use a initrd we can 
discard the key after using it.
 
> Summary: full disk encryption isn't worth the effort.

	Maybe. There is also the performance factor, have anyone here used disk 
encryption? Does it uses too much RAM or CPU?
 
> Shut down remotely: I have no idea how this could work without having a
> central server the system has to connect to. If we setup something like
> that we run into data protection issues. I don't like software calling
> home, even if it is open source software ;-)

	Do the devices we usually test PA comes with TPM chips? 
	http://en.wikipedia.org/wiki/Trusted_Computing
 
> If there is a different solution, I am open to it.
> 
> > * security model of the data even against the applications:  should be
> > the nepomuk store doing some sort of authentication on who can access it
> > and what data? this could be desiderable as well, not sure about the
> > technical feasability tough, in part because all our stuff communicates
> > with the easily eavesdroppable dbus (nepomuk, contour, activity
> > manager), in part because whatever you can really sandbox an installed
> > c++ app is a bit questionable.
> 
> I doubt it is possible at all if all processes are run by the same user. In
> case the shell (nepomuk, contour, activity manager) would run as a
> different user I think it becomes possible.
> 
> For the same user it doesn't make much sense. D-Bus is wide open (kwallet
> sends passwords unencrypted) and I guess even p2p D-Bus is open to other
> processes of the same user. It might be possible to encrypt the
> communication (DH key exchange should be good enough), but that does not
> solve the authentication problem. Authentication is IMHO just not possible
> in an open system. If we distribute keys for our applications a
> "malicious" application could grab it and still talk to nepomuk. Even if
> it gets generated at first install it has to be somewhere on the
> filesystem and other processes can just read the file. This would of
> course not be possible if it is another user.
> 
> In case of another user only root exploits or exploits in the shell would
> make it possible to access it. Root exploits are rather unlikely to be a
> problem here. But exploiting Plasma should not be that difficult: let's
> face it, security against exploits was never an issue, so I'm pretty sure
> that it's easy to own Plasma (or KWin or any other software designed to be
> only run by user).

	I agree with you here. I do not see the fact D-Bus is open as problem 
because usually there is only one user account in tablets and smartphones. We 
can even impose only one user account as a policy.
 
> > probably at least some form of authentication for qml only stuff to the
> > metadata model and the dataengines is desiderable *and* feasible tough.
> > maybe with a derivation of the remote plasmoid authorization?
> 
> Isn't remote plasmoid authorization based on "user clicks ok?". Automating
> that would not add any security, or am I missing something?
> 
> I would recommend to go for the low hanging security issues first: using
> PAM for login.
> 
> For those now knowing how a window manager guy knows stuff about security:
> I did my Master thesis at an IT security chair and IT security was my main
> subject during my Master studies.

	Cool, we have our security overlord already :-D

-- 
Lamarque V. Souza
KDE's Network Management maintainer
http://planetkde.org/pt-br
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/active/attachments/20120105/da3e5ba7/attachment-0001.html>