Re: [Cooker] proposals: more encryption/auth enhancements

[Vincent Panel]

On Wed, Apr 30, 2008 at 4:21 PM, Vincent Danen <vdanen@mandriva.com> wrote:
> Was told that cooker would be a better place to discuss, so here we
>  go...
>
>  --
>  Vincent Danen @ http://linsec.ca/
>
>
> ---------- Forwarded message ----------
> From: Vincent Danen <vdanen@mandriva.com>
> To: maintainers@mandriva.com
> Date: Tue, 29 Apr 2008 18:29:33 -0600
> Subject: [vdanen@mandriva.com: [Maintainers] proposals: more encryption/auth
> enhancements]
> 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/
>
>
> ---------- Forwarded message ----------
> From: Vincent Danen <vdanen@mandriva.com>
> To: Anne Nicolas <anne.nicolas@mandriva.com>
> Date: Tue, 12 Jun 2007 10:00:10 -0600
> Subject: [Maintainers] proposals: more encryption/auth enhancements
> 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/
>
>

Well, thanks for forwarding this to cooker, but I don't see anything
to discuss... what could be the drawback of adding TCB and
pam_passwdqc in Mandriva ?