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 gid 'shadow'. 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 from scratch. robert
pgpZV68QahU1p.pgp
Description: PGP signature
-- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
