[Ksecretservice-devel] Fwd: Re: Re: ACL handling

[Valentin Rusu]

Hello all,

I forward this mail exchange I had with Michael to the list ...
Promise, next time I'll post it directly here.

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

Ok for that.

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

Ok

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

Suppose an executable A wants to share it's secrets with another executable
B, but wants to deny sharing with any other executable. In this case, an
external policy file would be required, and this file would be under the
responsibility of executable A developer.

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

Ok for now.

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

I'll make a schema to document this.

> Regards,
> Michael

Valentin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/ksecretservice-devel/attachments/20101006/581251ba/attachment.sig