[Authentication] project ideas

[Michael Leupold]

Hi Ben,

Nice to see a new face on this list.

Am Mittwoch, 24. Februar 2010 03:20:59 schrieb Ben Kibbey:
> One of the main reasons for writing pwmd was the use of the "target"
> attribute in an XML element path. This lets the client share the same
> data with another application although located somewhere else in the
> document. Similar to XML entities and the HTML "target" attribute. So if
> I have an application (Mutt MUA) that needs server configuration details
> it requests an element by a configured element path then pwmd returns
> that elements content. With the use of the "target" attribute another
> application (Exim MTA) that requires the same data as another (Mutt in
> this case) can get the same data although located in another element.
> The XML document looks like this:
> 
>       <root name="isp">
>               <username>someuser</username>
>               <password>somepassword</password>
>       </root>
>       <root name="exim" target="isp"/>
>       <root name="fetchmail" target="isp"/>
>       <root name="isync" target="isp"/>
>       <root name="mutt" target="isp"/>
> 
> This way I only need to update the "isp" data for all applications that
> use it. If there is a way to have the Secrets Service do this that would
> be cool.

The concept used in the Secret Service API is a bit different but can in some 
ways achieve similar things. Secret items in the API are usually not stored 
and retrieved by name ("isp", "exim", ...) but by attributes. This basically 
means that you wouldn't store an imap account's password using the name "isp" 
as its identifier but would attach attributes likes 
"server=imap.myisp.com:993" or "type=email" which would enable the item to be 
found by several applications.

One major difference is that the daemon itself doesn't actually parse the 
secret data. It's just treated as a binary blob. Of course this makes refering 
to elements inside some hierarchy pretty much impossible. As I don't know how 
pwmd is used I don't know if that's a must-have feature though (I'm trying to 
imagine how that would work in an application's gui but can't really figure 
out how it would be used).

> It would be cool to see gconfd (not sure what KDE uses for configuration
> management) and the Secrets Service merged into the same server.  Maybe
> a flag in a configuration data that requires the client to authenticate
> before retrieving it.

There's already some (afaik non-public) KDE API for storing secrets using the 
current KWallet through the means of the KConfig system. I don't believe 
merging configuration and storage of secrets is that good an idea. I'd like to 
keep the two separated. Especially since I fear the result might get so 
complicated we might face a problem finding someone to maintain it - after all 
configuration systems and password management daemons don't seem to be among 
the top 10 "projects I'd like to maintain".

> A way to connect to the DBus server as another user. pwmd uses a local
> socket that any user can connect to. Since it's a unix domain socket,
> file permission (ACL) and SO_PEERCRED based access work fine. I'm
> thinking about Exim support in the example above.

This might well be possible using peer2peer D-Bus (basically not a bus but a 
socket connecting a client and a daemon directly). Making an application that 
already speaks the API communicate like that might be trivial but I don't 
really know enough about possible security implications or the likes.

Currently only the session-bus is part of the spec. It might be interesting to 
see if the API could be used like that as well. I can't tell you if this is 
something keyring and kwallet would support though (haven't given it any 
thought up to now).

Do you think there's a real need for offering "your own" secrets to a 
different user account? Shouldn't actually the other applications run under 
"my account" if they want to use my precious secrets?

> Also require as few dependencies as possible. Nothing GUI related since
> this may bloat non-GUI related apps.

The basic idea behind a daemon implementing the secret service is that the gui 
is completely up to the daemon which would eg. ask for a password if that's 
required to unlock the collection of secrets. So no gui is needed for the 
client part.

> Just some ideas. I hope the Secrets Service can use some of them.  You
> can find pwmd at http://bjk.sourceforge.net/pwmd/.

Yeah, fresh ideas are always welcome.

Kind regards,
Michael