OpenSSL libcrypto/libcrypt

Robert Connolly 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 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.linuxfromscratch.org/pipermail/hlfs-dev/attachments/20070518/e6e5654e/attachment.sig>


More information about the hlfs-dev mailing list