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

[Vincent Danen]

* [2008-04-30 17:09:30 +0200] Fabrice Facorat wrote:

> 2008/4/30 Vincent Danen <vdanen@mandriva.com>:
>
> >  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 first proposal is to add blowfish support to glibc.
>
> +1
>
> >  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.
>
> I don't agree.
> We should keep /etc/shadow by default, or make pam_tcb use /etc/shadow
> by default.
> Now an option could be add in drakauth ( and/or draksec ) to switch to
> /etc/tcb/user/.
>
> Why ? because I'm using NIS, and so I need /etc/shadow, and I don't
> think that there's support for /etc/tcb/user/ in NIS.

This doesn't matter.  pam_tcb can use /etc/shadow just as well as using
/etc/tcb/*.  There is a conversion tool to convert from /etc/shadow to
/etc/tcb, and I believe a reverse as well.  Using pam_tcb does not mean
you *have* to use /etc/tcb.

An excerpt from my Annivx docs:

"To actually authenticate against tcb, you need pam_tcb installed; the
upgrade will have done this for you. As with nsswitch.conf, if you made
no changes to the default /etc/pam.d/system-auth file, the new pam will
replace the file with calls to pam_tcb instead of pam_unix. Regardless
of this change, because pam_tcb understands shadow passwords, if you
choose not to convet to tcb, your existing shadow entries will continue
to be read. If you have followed the instructions up to this point and
have deleted the old shadow files, your system will be using tcb
immediately."

http://annvix.org/User_Guide/tcb

> >  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.
>
> again. Could be enabled in higher security levels by draksec.

Well, it can be used by default, you just change the system-auth file
depending on the security level.  It's completely configurable; there's
no need to "swap" modules depending on the security level, just adjust
the configuration.

> >  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)
>
> but keep using /etc/shadow by default except for higher security levels

I'd like to explore the possibility of using NIS with TCB first before
making that determination.  Otherwise it would be just as simple as
leaving /etc/shadow alone and the users can select "Authentication:
shadow or tcb" and let them choose, regardless of security level.

> >  3) use pam_passwdqc instead of pam_cracklib (easy)
>
> still using pam_cracklib by default escept for higher security levels.

Disagree.  pam_passwdqc is quite configurable, so let's configure it
instead of using two different modules.

> >  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.
>
> +1
>
> >  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.
>
> I don't agree.Msec is just not correctly designed and used.

You're right.  And that's why it 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: pgp00067.pgp
Description: PGP signature