[Authentication] Some input

[Dieter Plaetinck]

On Sat, 11 Jul 2009 11:34:25 +0200
Michael Leupold <lemma at confuego.org> wrote:

> Hi,
> 
> On Friday 10 July 2009 20:40:54 Dieter Plaetinck wrote:
> > - can it be usable without dbus? some people don't like dbus. simple
> >   CLI program to query the database?
> 
> While it should be possible it's currently not planned as part of the 
> specification. After all even CLI programs may use the D-BUS :)
Yes, but some people don't want to have dbus installed at all.  I don't
want to go into a discussion here about how good or bad dbus is.  But
it's a fact that some people don't want it all, so the option to
interact with the secret store without going through dbus would
be nice.

> > - ACL for apps: a plaintext config maintained by user? maybe itself
> >   stored within the secret storage?  would apparmor/selinux/..
> > already support something like this?
> 
> ACLs aren't part of the specification either but are currently used
> by keyring/wallet. AFAIK keyring uses /proc to find out, KWallet just
> trusts whichever name the applications says it has. As I understand
> it SELinux could be used to manage some of those ACLs. Still ACLs are
> currently not meant to be part of the API. They can't be a required
> part anyway because there's no guarantee that all platforms will have
> sufficient support for low-level features required to implement them
> (eg. Windows is a target platform for KDE and I fear we won't see
> proper ACL on it).
I see.  One thing that would really scare me if any app/script could
get to any of the secrets it shouldn't see.  A simple way to do
this might be to have collections named after the argv/cmdline
(whichever is most secure) of processes. Eg a collection named
'/usr/bin/perl myscript.pl' can only be accessed by that script.
Of course things like this are too user-specific to end up in the spec,
as long as it would be possible i'm happy.

> 
> > - unlocking ssh keys by unlocking the secret store? or the other way
> >   around: unlocking the secret store with an ssh key? or hell..
> >   make the secret store an ssh-agent ? gnupg? PAM ?
> >   type master pass once, have ssh/gnupg/pam (login) for free?
> 
> As I understand it most of those features will be able to live on the
> client- side though eg. PAM support may require an additional call to
> unlock a collection using a password.
> 
> > - the previous could be taken a step further: some people have
> >   encrypted blockdevices (hard disks) in Linux which they unlock at
> >   boot time (or in initramfs for / ), could this be integrated
> > somehow?
> 
> I think it should well be possible provided the daemon (which is
> running inside a user's session on the session bus) is up before and
> there's a way to unlock it (eg. after user login inside the X
> session). I'd categorize this as a client feature as well.

fair enough.


> On a sidenote not everything has been settled. The thin line between 
> implementation- and specification defined features is currently still
> sketchy and we might reconsider where to put a feature if we see the
> need. Yet I think it's best to keep the spec as slim as possible.

I agree with that. "kiss" philosophy.

> 
> Regards,
> Michael

Dieter