[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 15 Mar 2012 17:03:09 +0100
From: Paweł Hajdan, Jr. <phajdan.jr@...il.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 23:53, Solar Designer <solar@...nwall.com> wrote:
> > 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.
>
Interesting, is 0.60 the latest version of SimplePAMApps? If not, where's
the latest version? Here are links I could find easily:
http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/SimplePAMApps/
http://sisyphus.ru/en/srpm/Sisyphus/SimplePAMApps/sources
I'm going to take a closer look.
> Which implementations did you look at when working on yours?
I was looking at shadow-4.1.4.3 from http://pkg-shadow.alioth.debian.org/ .
> 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?
That's a good question, and I was also thinking about it before making that
decision.
First, when adding tcb support to shadow, I noticed there is some
duplication (of code but also of knowledge, i.e. coupling) that could be
solved by moving more code to libtcb, or re-implementing the whole thing as
a single package (that's what I did with hardened-shadow).
The hardened_shadow PAM module and NSSwitch module use code from common/,
especially file.c.
I decided to base hardened_shadow PAM module on pam_unix instead of pam_tcb
because I want hardened-shadow to be as compatible with shadow-utils and
pam_unix as possible.
Note that I'm going to work more on that PAM code, so contributions to
bring it closer to pam_tcb (or replace it with pam_tcb) could be
interesting. The pam_tcb code would need some changes anyway, e.g. to use
hardened-shadow.h.
If that would be useful to you, I'm fine with exposing some hardened-shadow
functions as a shared library, in a way similar to libtcb.
> FWIW, I noticed that you also excluded gpasswd - you could want to
> document that in your list of missing features.
Right, that was also on purpose - I think nowadays password-protected
groups are not really used, and they increase complexity of the tools. As
with rest of issues, I'm open to the opinions of the community - if there
is some important enough use case I can change my mind.
> 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).
>
Sure, if you only want to take some parts I'm fine with that. If you decide
to use it and make changes, your patches are welcome (that should make your
maintenance efforts easier and also further encourage other projects to
re-use it). Those patch submissions could realistically lead to granting
you commit privileges for 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
>
Ah, I missed that one. Fixed in git now: switched to 2-clause BSD and used
canonical wording where possible.
Thanks!
Content of type "text/html" skipped
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.
