Data security

[Martin Gräßlin]

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
* 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

Summary: full disk encryption isn't worth the effort.

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 ;-)

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

Cheers
Martin
-------------- 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/dd8c44e9/attachment.sig>