[Authentication] Some input
lemma at confuego.org
Sat Jul 11 02:34:25 PDT 2009
On Friday 10 July 2009 20:40:54 Dieter Plaetinck wrote:
> And now the "real" input, which are mostly just thoughts that popped
> into my head:
> - configurable encryption for persistent storage? algo, key size etc.
> gnupg integration?
This is currently meant to be implementation-defined though the algorithms
used for negotiating a session remain to be specified.
> - master password unlocks key, key unlocks data?
That's one way to do it, though at least KWallet uses the hashed password as a
key to decrypt all of a wallet's ("collection") contents. Not quite sure about
keyring, but I guess it's currently the same.
> - 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 :)
> - datastore : some kind of binary format?
Implementation defined. While most users will be using encrypted files for
storing their secrets they might also be written to a TPM, a smartcard or even
some central server (ldap?).
> - 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).
> - 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.
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/authentication/attachments/20090711/8233374b/attachment.pgp
More information about the Authentication