[vdanen@mandriva.com: [Maintainers] proposals: more encryption/auth enhancements]

[Vincent Danen]

I'd like to revisit this.  The original pre-2008.0 message is included
for the particulars.

And I'll tell you why I want to revisit it.  It's no secret to anyone
here that I've been developing a server-oriented distro for the last 4.5
years, where security was the primary "feature".  Due to various
circumstances, etc. I've stopped developing Annvix and all my machines
are currently running 2008.1 right now with the aim to move them to CS5
as soon as it hits beta.

However, going from Annvix to Mandriva has been a *massive* leap
backwards in terms of security.  Annvix evolved so much from the 9.2
release that I forked, and despite largely tracking cooker since then,
quite a bit of it is different, so I have a different view of things and
I know what's worked for me and what hasn't.  You also learn a) a
greater appreciation for those doing the core "stuff" and b) that you
don't always have to be one of the sheep when it comes to this stuff.
=)

Now, I could easily package pam_passwdqc and stick it in contrib quite
simply.  That's no problem.  TCB support is a little trickier.  TCB
doesn't *need* to be enabled, but it does need to be in main (because
util-linux would need to be patched and there would be a dependency on
libtcb).  Also, implementing TCB support *without* blowfish support in
glibc is not really my idea of time well-spent as TCB can work fine with
md5/crypt passwords, but why go through the effort to get a half
implementation?  Putting blowfish support in glibc, and then tcb, would
work best.  And pam_tcb can replace pam_unix completely without forcing
the use of the /etc/tcb/* layout; you can still use /etc/shadow.

The effort should be minimal.  I already did this years ago for Annvix
so it should be extremely straightforward to do it.  And yes, I'm
willing to do the work and testing to make sure it works.

I just don't want to start and have someone freak out and/or revert my
changes, so I'm bringing this up again.  If there is no one violently
against it, then I'll do it.

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

--- Begin Message ---

I figured I'd cc maintainers@ on this.  I'm not sure if the 2008 roadmap
is already defined or not, or when the projected release date is going
to be, but there are a few very nice enhancements we could add to
Mandriva.  None of this is speculation or conjecture; I've been using
all of these things in Annvix for quite some time.  (Annvix is my little
test-bed for some of this more radical stuff).

Everyone knows my big thing/passion is security, and the more proactive
security we can have, the better.

The first proposal is to add blowfish support to glibc.  This would
allow use to use blowfish-based passwords in addition to the traditional
md5 password hash.  SUSE currently does this, and has for years.  To
enable the use of blowfish support, glibc needs to be patched and so
does shadow-utils.

http://www.openwall.com/crypt/

I've forward ported the shadow-utils patches for blowfish support quite
a while ago and it works great.

In addition, I think we should drop using pam_unix by default and use
pam_tcb instead.  tcb is *much* nicer, and from a user's point of view,
there is absolutely no difference.  Essentially, tcb removes /etc/shadow
and replaces it with a directory structure, like /etc/tcb/user/ where
each user has their own shadow file.  The benefit here should be
obvious; if some tool is exploitable and has access to /etc/shadow, it
could read not just the user's password hash, but everyone's (because
this is a single file).  With tcb, they only can and only ever will be
able to see their own shadow password.  Of course, if someone actually
has access to the root user, then all bets are still off, so this is no
different than the current /etc/shadow in that regard, but if, for
instance, you authenticate some website against system accounts, the
file accessed only contains that user's shadow password, and not
everyone's.

http://www.openwall.com/tcb/

tcb works great. Highly recommended.

Another good pam module to add is pam_passwdqc.

http://www.openwall.com/passwdqc/

This pam module does some very strong (configurable, of course) password
checking and offers passwords as well.  It replaces pam_cracklib.  Quite
a few distros are starting to use this one as well (maybe not by
default, but packaging them).  I think we should use it by default.

For instance, on Mandriva, you get:

[root@atlas pam.d]# useradd goo
[root@atlas pam.d]# passwd goo
Changing password for user goo.
New UNIX password: BAD PASSWORD: it's WAY too short
Retype new UNIX password: passwd: all authentication tokens updated successfully.

I used the same password (foo) and it allowed it (although, granted, a
normal user couldn't do that).  However, on Annvix, using pam_passwdqc,
it's enforced, even for root:

[root@ares etc]# useradd goo
[root@ares etc]# passwd goo
passwd: updating all authentication tokens for user goo.

You can now choose the new password or passphrase.

A valid password should be a mix of upper and lower case letters,
digits, and other characters.  You can use a 6 character long
password with characters from at least 3 of these 4 classes, or
a 5 character long password containing characters from all the
classes.  An upper case letter that begins the password and a
digit that ends it do not count towards the number of character
classes used.

A passphrase should be of at least 3 words, 8 to 40 characters
long and contain enough different characters.

Alternatively, if noone else can see your terminal now, you can
pick this as your password: "person&ride;fourth".

Enter new password: Weak password: too short.
Try again.

You can now choose the new password or passphrase.
...

Again, using the same password.  The length and complexity are
completely controllable and the defaults might be too much for some
people, so something like drakauth should allow it to be configurable.
Configuration is simple:

[root@ares etc]# grep passwdqc /etc/pam.d/system-auth
password        required        pam_passwdqc.so min=disabled,12,8,6,5
max=40 passphrase=3 match=4 similar=deny random=42 enforce=everyone
retry=3

Oh, for tcb and blowfish, consider this:

[root@atlas pam.d]# grep goo /etc/shadow
goo:$1$3kv1oBrG$ywRVf3.jWID0r1YA5rUyH/:13676:0:99999:7:::

[root@ares etc]# cat /etc/tcb/goo/shadow
goo:$2a$08$YQbCTXtQQBL84DUjcksHv.DLmeOqPbUzZtfL.T4SleTn.gZ1mNcfS:13676::::::

The first is obviously Mandriva with md5 password and the second is
Annvix with tcb and a blowfish password.

So there is three proposals here, but they all work extremely well
together:

1) enable blowfish password support (patches to glibc and shadow-utils)
2) use pam_tcb instead of pam_unix (easy to incorporate, no patching
needed)
3) use pam_passwdqc instead of pam_cracklib (easy)

If we're looking at making some noise about Mandriva and security for
future versions, using AppArmor and writing a tool to configure it is a
good start.  Enhancing some of the other stuff would be welcome as well
and show some real progress to security.  My opinion of Mandriva
"proactive" security right now is essentially msec, which I think blows.
The reporting features are great, the changing perms and whatnot behind
your back is awful.  The security levels could be put to much better use
than defining permissions (i.e. enable/disable apparmor, default
password strength requirements, etc.).

Having a 2008 or 2008.1 with AppArmor (enabled and easily configurable
out of the box), blowfish passwords, pam_tcb, and pam_unix is a *real*
step towards good security.

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

Attachment: pgp00025.pgp
Description: PGP signature

--- End Message ---

Attachment: pgp00026.pgp
Description: PGP signature