Data security

[Martin Gräßlin]

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?
> 
> > 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.

Cheers
Martin
> 
> --
> Lamarque V. Souza
> KDE's Network Management maintainer
> http://planetkde.org/pt-br
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/active/attachments/20120105/35216020/attachment.sig>