Data security

[Ivan Čukić]

p.s. When I said we can do something by signing apps, I meant we can
forbid running unsigned apps altogether - d-bus is inherently
insecure, so we can't auth against nepomuk only...

On 5 January 2012 21:22, Ivan Čukić <ivan.cukic at kde.org> wrote:
> 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



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