[Ksecretservice-devel] Re: ACL handling

Michael Leupold lemma at confuego.org
Tue Oct 5 08:27:05 CEST 2010


Hi Valentin,

Am 03.10.2010 23:47, schrieb Valentin Rusu:
>
> Hello,
>
> Since our last meeting, last week, I figured out how to get the caller 
> process PID using the QT4 API, hinted on my way by Havoc Pennington.
>
> Now, that I'm able to get the caller PID, I'm now able to get the 
> calling process information, such as the cmdline and executable file.
>

Awesome!

> Here is what I'm trying to implement next :
>
> - when a process opens a session and create a collection, we'll store 
> along in this collection information about the calling process,
>
> - when a process opens a collection for reading, we can check that 
> it's executable file (or cmdline ?) is the same before allowing it,
>
> - this behavior should be adjusted by the means of o policy file ; the 
> policy file should be under the responsibility of the client 
> application (e.g. Kontact application should install it's policy file 
> it it wants ACL handling).
>
> What do you think about this ?
>

I currently planned to store ACLs per-collection inside the collection 
itself. This is necessary because otherwise an application could just 
create a policy file or add itself to a config file (like with KWallet) 
to gain access (also, multiple applications usually have access to the 
same collection).

Thus I'd propose the following:
- When creating or unlocking a collection, the "credentials" (exe name) 
is retrieved
- it's checked against what the collection already knows and if the 
application is not authorized we have a dialog popping up (I'd take care 
of that and introduce it to the abstract UI so you can make use of it). 
The dialog would be similar in functionality to the one from KWallet. 
Alternatively the user could disable ACL checking altogether (by a 
config value also stored inside the collection).

I'm not yet sure what you mean with the policy file. Could you please 
explain a bit more?

> I also think the service specification should be updated and agreed 
> upon before going further with the implementation. Where can I found 
> the latest specification in order to get it updated ? I currently know 
> this location :
>
> http://people.gnome.org/~stefw/secrets/html/index.html 
> <http://people.gnome.org/%7Estefw/secrets/html/index.html>
>

Back then we decided that ACL handling will not be part of the spec 
because every daemon should be free to choose whether to implement it or 
not (ACL checking only partly secures the daemon right now, the biggest 
attack vector is LD_PRELOADing an library that spies upon a collection 
inside an authorized application). This also means that ACLs have to be 
transparent to any client. As ACL handling might pop up a dialog (as 
mentioned above), the operations requiring ACLs can only be the ones 
which return Prompt objects (which is actually the only restriction :-)).

If you have further questions, you can also try to reach me on IRC 
though frankly I'll almost be working 24/7 from Wednesday to Friday.

Regards,
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/ksecretservice-devel/attachments/20101005/369db1f5/attachment.htm 


More information about the Ksecretservice-devel mailing list