[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20060702032110.GQ1128@annvix.org>
Date: Sat, 1 Jul 2006 21:21:10 -0600
From: Vincent Danen <vdanen@...sec.ca>
To: owl-users@...ts.openwall.com
Subject: Re: tcb and friends with shadow-utils 4.0.12
* Solar Designer <solar@...nwall.com> [2006-07-02 05:40:26 +0400]:
> > I'm working towards integrating tcb fully into Annvix here ...
>
> Great!
>
> We definitely want our stuff to be accepted by other distributions.
It's good stuff, so even though the integration may be a bit painful at
first, I think it'll be worth it.
> > The problem I'm having is with passwd; it's segfaulting on me when I try
> > to change a password. I've got my /etc/pam.d/system-auth nearly
> > identical to the openwall one (in Owl/packages/pam/system-auth.pam):
> [...skipped...]
>
> It looks OK to me.
>
> > A few things I noticed, and I was originally trying to stick pam_tcb in
> > there as a replacement for pam_unix, which is why I kept the last
> > pam_deny.so call in there. Of course, with pam_unix this works ok, but
> > with pam_tcb it doesn't, so I had to remove it. Does pam_tcb negate the
> > need for pam_deny?
>
> I don't understand why pam_deny could be needed there at all.
Me neither, but this is how it was in Mandriva, so it was how it carried
over. It worked, so I never much bothered examining it closer.
> > Anyways, my big problem here is with passwd segfaulting when I try to
> > change my password
>
> I'm afraid that you'll have to debug the segfault. Even if it's caused
> by misconfiguration, this suggests that you have a bug in some C code,
> perhaps in the passwd program itself.
I'm suspecting the libuser backend. Upon some further looking, passwd
seems to be doing something directly with /etc/shadow via the libuser
interface which has support for LDAP, passwd, and shadow files. I
think, in order to continue using that passwd implementation (which
actually looks like it's being maintained by RH), would be to write a
tcb backend for libuser, something I'm not overly interested in doing.
> > I've changed perms, so that /etc/shadow is owned root:shadow and mode
> > 0440.
>
> Once you fully migrate your system to tcb, you should remove /etc/shadow.
That's the impression I had gotten.
> > I've used tcb_convert to enable my tcb filesl my /etc/tcb files
> > are owned [user]:auth, and the directories are all sgid auth. My own
> > shadow file (/etc/tcb/vdanen) is owned vdanen:auth and is 640.
>
> That's correct.
>
> > I'm wondering if I missed a patch to passwd perhaps?
>
> No, tcb does not require a patch to passwd.
I didn't think it should.
> > We use a separate
> > passwd package that provides just passwd itself (it's the freebsd passwd
> > with pam support). I noticed passwd isn't in the owl shadow-utils
> > package (in fact, I'm at a loss as to which package in openwall is
> > providing passwd since I don't see it it in util-linux either).
>
> We use the implementation from SimplePAMApps with our modifications (not
> related to the use of tcb):
>
> http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/SimplePAMApps/
>
> SimplePAMApps is a package that provides small PAM-only implementations
> of login, passwd, and su. It is essentially unmaintained upstream - so
> we're maintaining it ourselves. (Maybe we should be making releases of
> "our" SimplePAMApps separately from Owl.)
Yeah, I finally updated my CVS copy of owl and started grepping for
passwd and found that. I was fiddling with it a bit before I had to
take off, and there's some gcc4 cleanup that's needed I think in order
for passwd to compile properly.
But I plan on dropping that in on my test vm and see if that makes a
difference. If so, it'll be nice because our passwd is the only thing
that uses libuser, so if I can drop it, fantastic. The other stuff I
see in SimplePAMApps look to already be provided by util-linux, so the
only thing I'm really interested in is passwd.
I should, now that I'm thinking of it, just try the passwd program from
the shadow-utils suite too... that might work.
> > It's good that auth works... it means I'm heading in the right
> > direction. Hmmm... wait.. looks like it's wanting to use /etc/shadow
> > regardless of the USE_TCB setting in login.defs
>
> The USE_TCB setting is for the shadow suite utilities only (such as
> useradd, etc.)
I suspected that as I was forward-porting the patches.
> > (unless it requires the shadow file to exist still?).
>
> With proper configuration, it should not.
>
> > Hmmm... do I need to put tcb into the shadow line in /etc/nsswitch.conf?
>
> Yes, you do. We have:
>
> passwd: files nisplus nis
> shadow: tcb nisplus nis
> # To not use tcb, replace the "tcb" with "files":
> #shadow: files nisplus nis
> group: files nisplus nis
>
> > Ok, looks like I need to have "files tcb bla..." in the nsswitch.conf;
>
> Not exactly. You replace "files" with "tcb" - but you do that on the
> "shadow" line only.
Right. I didn't think that passwd and group had any bearing on this. I
did put "files tcb" and using getent saw passwords being shown up twice.
Of course, once the shadow file is gone, having "files" in there won't
matter, but also won't serve any useful purpose.
> > /usr/bin/passwd is sgid shadow.
>
> That's correct. We have it like this:
>
> -rwx--s--x 1 root shadow 6884 2006-05-06 03:56 /usr/bin/passwd
Yeah, I was looking at your control files in CVS and picked up the
appropriate perms for some files based on that.
> > Oh, all I did was add three groups: auth, shadow, and chkpwd (gid's 27,
> > 28, and 29 respectively). Are any users required to operate things? I
> > didn't notice anything looking through the slides and spec files.
>
> No, you only needed to add the groups.
Ok, good.
> > The following are the patches I took and rediffed from the openwall
> > shadow-utils package:
> >
> > Patch4: shadow-4.0.12-avx-man.patch
> > Patch6: shadow-4.0.12-avx-crypt_gensalt.patch
> > Patch7: shadow-4.0.12-avx-usergroupname_max.patch
> > Patch8: shadow-4.0.12-avx-tcb.patch
>
> If those patches are derived from ours, you could want to give due
> credit to our project by not dropping the "-owl-" from the filenames.
> Under our conventions, if we were the maintainers of Annvix, the
> filenames would be shadow-4.0.12-owl-avx-tcb.diff and the like.
Fair enough. I did note in the changelog where the patches came from,
but your notation is good too. In fact, openwall was where I got the
idea of tagging stuff with -avx- or -fdr- or -mdk-, etc. but now that I
think about it, the tagging of -avx- was to note that I forward-ported
it, but on casual observation it wouldn't show who I forward-ported
from, so I'll change the patch names to reflect that.
Hopefully using a non-libuser-"aware" passwd will solve the problem as
I'm seriously thinking that is where it's coming from.
Thanks for the info... I'm hoping to get tcb fully integrated in the
next few days and will let you know when it's complete.
As an aside, I planned on doing up some comparisons with other distros
and highlighting some of Annvix's features compared to them in a
slideshow presentation in the next month or so and fully planned to give
openwall credit for our glibc patchset and the tcb stuff (there are some
other bits from owl in Annvix too, I think, which would get rooted out
and noted). Bottom line is I fully intend to give credit where credit
is due. =)
--
{FEE30AD4 : 7F6C A60C 06C2 4811 FA1C A2BC 2EBC 5E32 FEE3 0AD4}
mysql> SELECT * FROM users WHERE clue > 0;
Empty set (0.00sec)
:: Annvix - Secure Linux Server: http://annvix.org/ ::
Content of type "application/pgp-signature" 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.
