DragonFly users List (threaded) for 2007-03
Re: To be a new DFly commiter
Dnia 17-03-2007, So o godzinie 00:05 +0100, Simon 'corecode' Schubert
> firstname.lastname@example.org wrote:
> >>> c) add support for openwall tcb - the alternative to shadow (with pam
> >>> module) which is more secure than pam_unix and pam_pwdb, because tools
> >>> like 'passwd' or 'chage' don't neet SUID, instead it use SGID 'shadow'.
> >>> Group 'auth' may be used to read-only access to all password hashes.
> >> I am not convinced that this improves security. Could you please detail your
> >> security considerations? My point is: current tools have been exposed to
> >> security audit for over 20 years now, so unless something else is conceptually
> >> more secure, chances are high that we should stick with the original system.
> > I made a mistake in this point,
> > SGID shadow can only read users list (can not read/write passwords).
> > SGID auth can read passwords, but can not write it.
> > Every user have its own shadow file whitch is owned by this user.
> > Write to user's shadow file can only this user or root.
> > There is not required SUID root for passwd and related tools.
> > For more you can read on http://openwall.com/tcb/.
> Yes, I read the docs and I think this is a quite nice and simple scheme to restrict access and to get rid of a couple of setuid root binaries. We definitely should discuss this. I'm not talking about integrating the sources because I suspect they are GPL, but about the principle itself.
Tcb is licensed under terms of BSDL.
> Short for everybody too lazy to read:
> master.passwd is being split into single per-user files. these are located in per-user dirs with mode $user:auth 710 and the files $user:auth 640. this way only root+user can change the files and therefore the password. only root+user+group auth can read/check the password. don't know about chsh(1) etc.
Czas wybrac dobra nazwe!