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

Sat Feb 19 02:26:54 CET 2011

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