Data security

[Ivan Čukić]

The first step that is plausible will be activity data encryption - via encfs.

As for the other things, signing executables to be able to access
nepomuk could provide some security - the key wouldn't be on the
device, so there would be no problem of somebody else using our key.
But I don't think this is possible to do in the time-frame we have.

One of the things we need for any of this to actually work, is for
strigi not to put the file contents in nepomuk. And we will have the
problems of reindexing files on unmount/remount of encfs folders...
Will talk with  trueg about it.

Cheerio,
Ivan

On 5 January 2012 20:55, Martin Gräßlin <mgraesslin at kde.org> wrote:
> 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
> _______________________________________________
> Active mailing list
> Active at kde.org
> https://mail.kde.org/mailman/listinfo/active
>



-- 
Cheerio,
Ivan

--
While you were hanging yourself on someone else's words
Dying to believe in what you heard
I was staring straight into the shining sun