[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAATLsPY1cgFy0E_eCLHjE=+Cdfp8jKcFW4SeXFLFR3vsR2otVg@mail.gmail.com>
Date: Tue, 20 Mar 2012 10:24:59 +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 Mon, Mar 19, 2012 at 02:48, Solar Designer <solar@...nwall.com> wrote:
> As far as I'm aware, 0.60 is the latest. That's what both Owl and ALT
> Linux use (with patches).
>
Thank you, I downloaded and read the sources. They're about the same size
as hardened-shadow's progs/ part (that also has useradd and other
utilities).
> 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.
>
> Is our pam_tcb somehow less compatible with Linux-PAM's pam_unix than
> your module is?
>
I think so. Let me go into more detail (thank you for interest).
The following module parameters are supported by pam_unix and
pam_hardened_shadow, but not pam_tcb: use_first_pass, try_first_pass. Also,
it was arguably easier for me to take pam_unix and remove unneeded parts
rather than compare pam_unix and pam_tcb and see what's different. Finally,
it seems Linux-PAM is more often updated than pam_tcb, so I wanted to make
sure pam_hardened_shadow is based on the latest version of that code.
Above issue is rather minor. However, pam_tcb can't be used without
patching glibc. It uses Owl-specific extensions like crypt_gensalt_ra and
crypt_ra, and it's generally easier to add a PAM module than to
custom-patch glibc (or to patch tcb like in Gentoo:
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-auth/tcb/files/tcb-gentoo.patch?revision=1.2&view=markup).
hardened-shadow works with vanilla glibc (tested on various distros), and
adds a prefix= PAM module parameter to allow using a different hash
algorithm (the list of possible algorithms is not hardcoded in the module,
so it seems future-proof to me).
Finally, pam_tcb lacks license headers in the files, so I was slightly
concerned about re-using that code.
Do you have any concerns about hardened-shadow's pam/ code having a dual
BSD-3 and GPL license or something related to that?
> > 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.
>
> At this time, I don't see why you couldn't just use pam_tcb as-is.
That's good question. There are at least two reasons:
1. hardened-shadow uses a different directory layout than tcb:
# ls -ld /etc/hardened-shadow
drwxr-xr-x 173 root hardened-shadow 4096 Mar 6 22:53 /etc/hardened-shadow
# ls -ld /etc/hardened-shadow/root
drwx--x--- 2 root hardened-shadow 4096 Feb 29 21:52
/etc/hardened-shadow/root
# ls -l /etc/hardened-shadow/root
total 12
-rw-r----- 1 root hardened-shadow 15 Feb 29 21:22 aging
-rw-r----- 1 root hardened-shadow 106 Feb 29 21:22 shadow
-rw-r----- 1 root hardened-shadow 9 Feb 29 21:52 shell
The shell file is added so that chsh doesn't have to be SUID, and aging
file is added so that the shadow file can be replaced without locking. The
users have no access to tools that modify the aging file. If they race the
admin with updating the shadow file that contains the password hash, they
can't gain anything. The admin changes user's passwords mostly for password
recovery. If he wants to prevent user from logging in, aging should be used
instead; it's documented in the man pages (not just hardened-shadow ones,
but also shadow-utils):
Note: if you wish to lock the account (not only access with a password),
> you should also set the EXPIRE_DATE to 1.
Comments about that design choice are also welcome.
2. Duplication of code.
The knowledge how to manipulate /etc/hardened-shadow (or /etc/tcb) should
not be duplicated in the PAM module and other utilities, especially if they
are separately maintained.
In hardened-shadow I moved all such re-used code to common/ , especially
file.c
(hardened_shadow_{fd,open_user_directory,open_user_file,replace_user_file,asprintf_shadow}).
I would need to update pam_tcb anyway to use those functions instead of
libtcb.
> > The pam_tcb code would need some changes anyway, e.g. to use
> > hardened-shadow.h.
>
> What would it need to use from there, specifically? Is that about your
> first comment above (de-duplication of some code? shadow file rewrites?)
Yes, the above answer should also address this question. Here's an exact
listing of hardened_shadow_ common functions used in the pam/ directory:
pam_hardened_shadow_passwd.c: if (!hardened_shadow_read(fd, where,
length)) {
pam_hardened_shadow_passwd.c: if (!hardened_shadow_starts_with(sp,
prefix)) {
pam_hardened_shadow_passwd.c: if
(!hardened_shadow_asprintf_shadow(&shadow_contents, spwd)) {
pam_hardened_shadow_passwd.c: if (hardened_shadow_replace_user_file(user,
pwd->pw_uid, shadow_contents, "shadow")) {
pam_hardened_shadow_passwd.c: pam_syslog(pamh, LOG_ERR,
"hardened_shadow_replace_user_file failed");
support.c: && hardened_shadow_starts_with(*argv,
unix_args[j].token)) {
support.c: } else if (hardened_shadow_starts_with(*argv, "prefix=")) {
By the way, pam/ directory itself is only about 700 lines of code, compared
to ~2 KLOC of pam_tcb. Now pam_hardened_shadow also uses code from common/,
but the above grep output indicates it's not a lot of functions, and those
functions could be extracted to an even smaller library, to make it more
obvious what code is used in pam_hardened_shadow.
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.
