Ok, preliminary builds and testing seem ok here, but this will be a bit
convoluted and may break some existing cooker installs with the
potential of locking you out of the system (although I will attempt to
minimize this).

Out of the below steps, the first two are complete:

1. Update glibc to handle blowfish passwords (13mnb does this)
2. Provide pam_userpass (in main now)
3. Provide tcb
4. Update shadow-utils to handle TCB support
5. Update util-linux-ng to not provide vipw,vigr (provided in
shadow-utils)
6. Update pam to not build pam_unix and provide new system-auth file
7. Update tcb to require new shadow-utils (Requires(pre)) due to the
three groups shadow-utils now provides, and conflicts on pam_tcb for
older pam
8. Updated passwd to drop suid root privs and make it sgid shadow

With the above changes, the system will still, by default, use shadow
passwords and will work 100% as it currently does. The only notable
change will be that any new passwords will use blowfish rather than md5.

There is a tcb_convert and tcb_unconvert scripts that convert
/etc/shadow to /etc/tcb/* and vice versa, however I want to write a
wrapper script that is more robust as there are a few other things that
need to be changed (i.e. system-auth needs to use write_to=tcb rather
than the default write_to=shadow, and nsswitch.conf's shadow entry needs
to s/files/tcb/).

The tricky part is making this seamless on upgrades, particularly if the
user has changed system-auth. There are symlinks provided that link
pam_unix.so to pam_tcb.so but it didn't look like it was working
properly when I tested, so I'd prefer to have it use pam_tcb directly
rather than rely on symlinks (which means that other packages, like
mirrordir, that doesn't use system-auth will also need to be updated).

I was thinking that in pam's %post it should look for system-auth.rpmnew
and if found, do some sed/perl magic to change the system-auth file
(i.e. change all occurances of pam_unix.* to pam_tcb with it's options).

Also, I don't like adding three groups in the shadow-utils package, and
would prefer to have these in the setup package as these are
administrative groups *required* for authentication to work properly.
They are just as important as the root, bin, adm, etc. groups and I'd
like them in setup to provide static gid's rather than dynamically
assigned gids in shadow-utils (i.e. using gid's 16, 17, and 18
probably). This will also prevent some circular dependencies between
tcb and shadow-utils (tcb could require setup >= foo, rather than
requiring shdow-utils >= foo, when shadow-utils also requires tcb).

I'm planning on committing this stuff sometime next week unless someone
has a severe problem with it. I've been testing using 2008.1, but
want/need to setup a cooker vm first to double-check everything in there
first before I push anything. I also want to write the tcb conversion
script too.

It sounds like quite a bit, but the end result is the exact same
functionality although the implementation is a bit different. Once nice
thing is that we can drop another suid root program (passwd). And, as
has been noted, the system could use TCB by default for higher security
levels and /etc/shadow for lower ones (although I'm not sure why we
can't just use TCB for everything).

Once all of that is done I'll probably introduct pam_passwdqc to replace
pam_cracklib, or at least make it available (the only downside to
pam_passwdqc is that it doesn't retain password history).

I'd also like to know about the groups being added to setup first before
I commit any of this as I can see problems being caused if some people
install shadow-utils with it's dynamic-group-adding mojo and then later
getting the groups added via setup.

--
Vincent Danen @ http://linsec.ca/