[Mageia-sysadm] Saving and sharing passwords in mageia teams

[nicolas vigier]

On Sat, 19 Feb 2011, Buchan Milne wrote:

> On Friday, 18 February 2011 23:45:02 nicolas vigier wrote:
> > Hello,
> > 
> > We often need to register some accounts on various websites for the
> > Mageia project (domain name registration, twitter, identica, etc ...).
> > And we need to be able to share the account informations (login and
> > password) with other people inside teams. So we need something like a
> > password database, with permissions to restrict access to only some
> > people or groups of people. We can store this database on Mageia servers,
> > but I think it should be encrypted, so that root access on the server
> > does not give access to the passwords.
> 
> This is not an uncommon requirement, in my work environment we need to be able 
> to share the local root passwords (e.g. in case a system administrator needs 
> to be able to restore something that prevents user logins from working).
> 
> However, in work environments, access to privileged passwords may need to be 
> auditable.

This tool could probably be used also outside Mageia.

> 
> > I have looked at existing tools, but didn't find one that would allow
> > us to do this easily. So I'm thinking about writting some scripts to do
> > it. It would work like this :
> > 
> >  - all users first need to upload their gnupg public key in ldap
> 
> I was already considering the requirement for GPG public keys in LDAP for 
> 'privileged user password recovery'. E.g., use the same process as 
> unprivileged users, but encrypt the key sent to the user with their gpg public 
> key (providing a second level of authentication - if we consider access to the 
> mailbox one level).

Good idea !

> I believe there may also an LDAP-based keyserver, which could provide even 
> more re-use.

A keyserver using LDAP would be nice. If not too difficult to setup.

> 
> >  - we have a command to create a password on the server, with a list
> >    of groups/users who can access this password :
> >     $ mgapassword create passwdname %group1 %group2 user1 user2 ...
> 
> Should we leverage existing (e.g. LDAP) groups?

Yes, I think we should use ldap groups.

> >  - a command to save the value of a password :
> >     $ mgapassword set passwdname < value
> >       or
> >     $ mgapassword edit passwdname
> >  - an other command to retrieve a password :
> >     $ mgapassword get passwdname
> >  - a command to list the passwords you can access :
> >     $ mgapassword list
> > 
> > All commands connect to the server using ssh and the ldap account. When
> > saving a password, the client ask to the server the list of gpg keys of
> > all users who should have access to the password, then encrypt the
> > password with all keys and send it encrypted to the server.
> 
> Where are the passwords stored?

Stored on the server in encrypted files. Maybe in a database.

> > The command to retrieve a password connect to the server, then the server
> > sends the password encrypted for the key of the user, which is decrypted
> > locally using the private gpg key of the user.
> > 
> > When new users are added into a group, they cannot access passwords
> > immediatly (as it is not encrypted for their keys), so someone needs to
> > retrieve and save the passwords, to encrypt them for the new users.
> 
> This general approach was what I was considering for our work environment.
> 
> > So, what do you think about this ? Or maybe someone knows existing tools
> > that can do this ?
> 
> I have not seen any I liked.
> 
> Our work environment has a basic inventory database (the primary use was to 
> generate kickstart files), the web front end is in ... Catalyst (and possibly 
> try and implement a more complete CMDB). My plan was to integrate the CatDap 
> features into this (using CatalystX::Features maybe). Adding a shared password 
> module that could be tied into CatDap and our work webapp would also be 
> interesting to me.
> 
> But, for now, a command-line tool would be adequate.
> 
> I will look at the LDAP side (schema, ACLs, suoport for adding GPG public key 
> from CatDap) over the weekend.

Thanks.