robert at linuxfromscratch.org
Fri May 18 06:34:52 PDT 2007
I've been reviewing a lot of versions of login utilities (bsd, shadow,
legacy-shadow, pwutils, busybox), and have been making a list of ideas:
In order for a test suite to work the passwd, adduser, etc, commands need to
support a '--directory=/tmp/chroot/etc/' option. This is also usefull for
creating chroot files without needing to write the etc/shadow file by hand,
and without being root.
I'm curious about an 'adduser --hidden-user' option. So a user can be added
to /etc/shadow, but not /etc/passwd. This would work with Grsecurity's hiding
processes you don't own... so there isn't any way for a regular user to know
the uid of the 'named' daemon, for example. This is an obscurity feature, so
I'm not so sure how good an idea it is.
And/or, an option to add a user to /etc/passwd, but not /etc/shadow. So the
user, like 'named', can be added to run a daemon, but would never be capable
of logging in. We can already do this by using 'x' as the password
in /etc/shadow, but my idea is higher in the code... so the user can't even
run /bin/passwd because their login-name isn't in /etc/shadow.
/bin/passwd doesn't need to be suid root just so it can write to 1 file. sgid
is plenty, with /etc/shadow owned by root with write permission for
Disable DES password creation, unless explicitly built to. Always allow DES
decryption. DES is obsolete, and should not be the default anymore. Warn
about DES passwords on every login, unless explicitly built not to, to annoy
the user to reset their password so md5/sha/bcrypt is used instead.
/etc/shadow should be able to function without encoded passwords, if built to,
and use clear text passwords and simple file permission protection
on /etc/shadow. To support systems in countries where encryption is illegal.
Disable PAM all together, and remove the code for it. Search securityfocus for
PAM vulnerabilities, I got 585 results. If you want to use PAM, use
Shadow-utils or Pwutils. I don't believe dynamically loaded modules are
practical or secure in this type of application, and perhaps any suid-root
application. PAM passes root permissions to more applications, instead of
less, which makes root more vulnerable.. being able to login with a PAM
fingerprint scan is not impressive if another PAM module is configured to do
something weaker... PAM is not a 'least privilege' system, it's a system
vulnerable to privilege escalation.
OpenSSL's libcrypto is the most robust crypto library available. It is very
unlikely that Glibc's, or uClibc's, libcrypt will ever be competitive in any
aspect. And in hindsight it looks like libcrypt should have never been added
to libc packages in the first place... it's not a priority to libc
developers, and pretty much does not fit into their project goals.
The openssl-src/apps/ directory contains a passwd.c file which
emulates /bin/passwd, des and md5 only, but the code design is friendly for
adding more algorithms. Instead of porting shadow-utils to openssl, I think
it would be more sensible to port openssl to shadow-utils, and start sortof
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the hlfs-dev