tcb - the alternative to shadow

Chris Adams cmadams at hiwaay.net
Tue Aug 29 14:05:46 UTC 2006


Once upon a time, Chris Ricker <kaboom at oobleck.net> said:
> On Thu, 24 Aug 2006, Chris Adams wrote:
> > Once upon a time, Neal Becker <ndbecker2 at gmail.com> said:
> > > This looks interesting:
> > > 
> > > http://www.openwall.com/presentations/Owl/mgp00020.html
> > 
> > I can't see that right now (no text in that site), but I would say if it
> > is anything like Tru64 Unix TCB, run away!
> 
> It's not ;-)

A little late on the reply here, but one problem I see is that it limits
the number of local users.  Since each user gets a direct subdirectory
of /etc/tcb, you can only have as many users as you can have
subdirectories (link count is 15 bits on ext2/3 IIRC, so 32767 users).

Not everyone with lots of users has multiple servers, so NIS/LDAP are
not automatically the answer.

With a bunch of users, you could also run into performance problems with
directory lookups (ext3 with hashed directories helps).

A better method would be to do something like MD5 hash the username and
then use the first two characters as directories.  For example,
"cmadams" hashes to "78dcb16738542f0a8853801c41757a70", so you could use
"/etc/tcb/7/8/cmadams".

Also, you've just given all users write access to the filesystem
containing /etc (they can then fill it up, hard link to privileged
files, etc.).  I don't think you'd really want to give users ownership
of the directory; that would bypass all password strength policies and
such (the user could just overwrite their shadow file).  Even if you
keep the directories owned by root, users can still overwrite the
contents of their shadow file entry with arbitrary content, which leads
to all kind of possible attacks against daemons that read the file (e.g.
how will sshd handle a 16000 byte shadow entry?).

-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.




More information about the fedora-devel-list mailing list