Data security

[Lamarque V. Souza]

Em Thursday 05 January 2012, Martin Gräßlin escreveu:
> On Thursday 05 January 2012 19:03:43 you wrote:
> > 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.
> 
> AFAIK the key is needed always in RAM as each read and write operation on
> the encrypted disk needs the key. At least there would not be any use of
> cold boot attacks if the key is not in RAM:
> http://en.wikipedia.org/wiki/Cold_boot_attack
> 
> > > 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?
> 
> I used it several years ago and the impact on CPU was so noticable that I
> stopped using it. I think the system I had back then is comparable to
> low-end ARM devices we have today.
> 
> But I have never tested with an SSD which might improve the situation
> 
> > > 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
> 
> How would TPM help here?

	We can use it to store certificates, keys or something, whatever instead 
of the harddisk/flash memory. We can also use it to lock the device if it is 
stolen. The problem is how to unlock in case the user has done something (like 
wronly typing the password too many times). Hmmm for this last feature we 
would need a hardware keyboard to type the password since the TPM chip ask for 
the password before booting the Linux kernel, so forget it.
 
> > > 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
> 
> there are more competent people in KDE for that :-) I mostly learned how to
> break systems, not how to make them secure that nobody else can break them.

	Ok, so we have our hacker to try to break our implemenation :-P 

-- 
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/77782c6a/attachment-0001.html>