[ On Wednesday, December 11, 2002 at 18:39:27 (-0500), Niels Provos wrote: ]
> Subject: Re: replacement for /etc/passwd
>
> Owl solved this problem a while ago.  I suggest that you investigate
> their solution:

Here the relevant excerpts are included and cleaned up a bit from the
"text page" links of:

    Openwall GNU/*/Linux
    Solar Designer, Rafal Wojtczuk
    NordU2002 (February 18-22, 2002, Helsinki, Finland)
    CanSecWest / core02 (May 1-3, 2002, Vancouver, Canada)
    http://www.openwall.com/presentations/core02-owl-html+images/


	Traditional password shadowing


	Password hashes and aging information of all users are stored in
	a single file

	passwd(1) possesses the privilege to alter all entries in the
	shadow file

	The traditional filesystem layout forces passwd(1) to be SUID
	root

	chage(1) possesses the privilege to read all entries in the
	shadow file

	A passwd process compromise is fatal

	The problem cannot be fixed by assigning a dedicated user for
	/etc/shadow access



	Owl: tcb - the alternative to shadow


	Each user is assigned a separate shadow file

	Each user is the owner of their shadow file

	Access to shadow files is group-restricted to allow for password
	policy enforcement

	The move to tcb is transparent for existing applications which
	rely on interfaces such as getspnam(3) (and thus on NSS) or PAM;
	no modifications to application sources are needed



	Owl: tcb: Filesystem layout


	owl!root:~# ls -ld /etc/tcb/
	drwx--x---      root    shadow   1024 Nov 27 12:14 /etc/tcb/

	owl!root:~# ls -l /etc/tcb/
	drwx--s---      root    auth     1024 Nov 27 12:14 root
	drwx--s---      joe     auth     1024 Nov 27 12:14 joe

	owl!root:~# ls -l /etc/tcb/joe/
	-rw-r-----      joe     auth       85 Nov 27 12:14 shadow

	owl!root:~# cat /etc/tcb/joe/shadow
	joe:$2a$08$ghnh1Q5K6kE24bY9xqQa5uSXwG2YO4O5lbj.yfLKp8BVFBusqLwxi:11320:0:99999:7:::

	The per-user directories are also used as scratch space for
	temporary and lock files which are needed during password change



	Owl: tcb: Required privileges


	passwd(1) is made SGID shadow
	chage(1) is SGID shadow

	A possible compromise would only let one bypass password policy
	enforcement for their own account

	Group auth may be used to grant a process read access to all
	password hashes should the need arise

	No real need for any SUID binaries on the entire system


Something (fairly minor) is wrong with this scheme though, or in my
understanding of it.  It doesn't seem possible for the 'auth' group to
have access to all the shadow files since group 'auth' alone cannot gain
access to anything under /etc/tcb (since that directory only searchable
by group 'shadow' (and of course the superuser)) and with set-group-id
to 'auth' it's not possible to also be granted group 'shadow' privileges
(and obviously users cannot be granted access to the group 'shadow' by
default!).

Overall though this is indeed quite an interesting scheme.  It only
hides information in the shadow files that's not commonly needed by
programs that map UID->username and vice versa, and so it should address
the performance problem well enough.

It addresses one of the concerns I mentioned with Alan Post's proposal,
namely the fact that it makes it impossible (without a bug in some
set-group-id 'shadow' program) for anyone else to steal the contents of
some user's shadow file.  Indeed even the user can't read or write his
or her own shadow file's contents without the assistance of a
set-group-id 'shadow' program, and so also addresses Alan's own concern
by making it possible to maintain the current rule of 'passwd' requiring
authentication before allowing a password to be changed.

With the addition of shell and full-name fields to the /etc/tcb/*/shadow
files then 'chfn' and 'chsh' can also be setgid to 'shadow' and not
setuid to 'root', and I think this information could also be safely
gathered and stored in a cache file to speed up access (with the only
added risk being that a compromise of group 'shadow' would then make it
possible for an attacker to modify everyone's full name and shell).

--
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>