[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120314225300.GA5880@openwall.com>
Date: Thu, 15 Mar 2012 02:53:00 +0400
From: Solar Designer <solar@...nwall.com>
To: owl-dev@...ts.openwall.com
Subject: Re: hardened-shadow, a shadow suite that has tcb built-in
On Wed, Mar 14, 2012 at 12:46:12PM +0100, Pawe?? Hajdan, Jr. wrote:
> I'd like to announce my little project I've published recently:
> hardened-shadow.
Thank you for bringing this to owl-dev. You may also want to announce
it on oss-security (maybe a bit later).
It's an impressive amount of work you did.
> It's an alternative implementation of shadow utilities
> (login, su, passwd and so on), inspired by Openwall's tcb.
Actually, for these three things you mentioned, we use SimplePAMApps
(with our patches), not the shadow suite. In fact, I was considering
releasing a new version of SimplePAMApps (maybe under a different name)
with our patches already in it for possible reuse by other distros
(since SimplePAMApps itself is not maintained for over a decade except
in distros that use it).
We use the shadow suite for programs like useradd, etc.
Which implementations did you look at when working on yours?
> The advantage is that you don't need separate patches (that are often out
> of sync) or libraries. Everything: programs, PAM module and NSSwitch module
> are in the same package. Also, it works with vanilla glibc. Finally, it's
> smaller than shadow-utils, and should be easier to fully audit.
This sounds good, except that for the PAM and NSS modules it could be
better to just use those we have in our tcb. And when its /etc/tcb mode
is not needed, then for NSS just use glibc's. By introducing your
alternatives, you potentially increase the total number of bugs in
implementations that are in use on different systems. While I admit
that I am guilty for doing similar things (re-implementations) in other
cases, arguably there has to be a good reason to introduce a new
implementation. What are your reasons to introduce and maintain yet
another pam_unix clone when we already have and maintain pam_tcb?
> The drawback is that it's new (so not really tested; also, some security
> bugs are likely to be lurking around), and doesn't support some features
> like SELinux or NIS. I'd like to add SELinux support, and I'm rather
> unenthusiastic about NIS; anyway I'm open to the opinions of the community
> about that).
FWIW, I noticed that you also excluded gpasswd - you could want to
document that in your list of missing features.
> The project's homepage is http://code.google.com/p/hardened-shadow/ .
>
> I'm currently looking for people interested in using hardened-shadow, as
> well as some form of security audit of this very young codebase.
We haven't decided on our possible use of it yet, but we'll need to
consider moving to it as an alternative to upgrading the shadow suite in
Owl (and forward-porting our patches). Moreover, we'll also need to
decide on staying with SimplePAMApps + patches vs. moving to your
implementations of these programs. As to PAM and NSS modules, I think
we'll just stay with ours (so we'll have almost no incentive to audit
yours even if we do use other parts of hardened-shadow).
BTW, I noticed that your license is slightly weird ("the entire
permission notice in its entirety"). I understand that you may have to
keep weird wording for source files not written entirely by you, but for
your brand new source files I suggest that you switch to canonical BSD
license wording and preferably reduce the number of clauses - make it
2-clause like in FreeBSD, or take a step further to "0-clause" like we
did in passwdqc:
http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/passwdqc/passwdqc/LICENSE?rev=1.7
Thanks again,
Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
