[Date Prev][Date Next] [Thread Prev][Thread Next]
Re: PAM and shadow
- From: Jim Dennis <jimd starshine org>
- To: pam-list redhat com
- Subject: Re: PAM and shadow
- Date: Wed, 30 Dec 1998 18:32:32 -0800
> Jim Dennis wrote:
>> How? What is the name of the "little helper binary" and
>> how does one call it from within one's own code?
> (On a redhat system this is)
>> I certainly hope you aren't suggesting that Wichert
>> creates *another* little helper binary. Let's make
> ldd /sbin/pwdb_chkpwd
> libpwdb.so.0 => /lib/libpwdb.so.0 (0x4000b000)
> libc.so.5 => /lib/libc.so.5 (0x4002a000)
> If you want to use pam_unix, you probably do not want to use a binary
> linked against the pwdb library.
Actually I don't like dynamically linked SUID
binaries at all. I'm still remembering a few LD_PRELOAD*
>> So, Andrew --- about your new years resolution: Are
>> we going to see a few more releases this year --- maybe
>> even approach 1.x. Are we going to get OPIE and/or S/Key
>> (TM) "out of the box" so we can discourage the scourge of
>> reusable passwords over insecure links?
> I work for a living. I do PAM things when I can. I don't write modules
> that I don't have a use for, so if you want to see these modules, please
> find/test/advocate them = please tell me whether what is "out there"
> appears to work and please arrange that they can be built within the
> Linux-PAM build tree.
There is a pam_opie out there. It's reasonably easy to
build but includes *no* documentation. You have to
devine or know from other experience to go get the NRL
OPIE sources, configure and build those, comment out
the part of it's make "install" target that replaces your
login, su, and ftpd binaries, and then you get to figure
out for yourself how to get PAM to call the thing.
I realize that you work for a living. So does Linus.
The question comes down to this: what can we do to
get this ball rolling?
Of course, the last time I asked about "1.0, when" the
response seemed like: "who cares? 1.0 is just another
number" That basically pissed me off.
I don't think PAM is ready for prime time. Red Hat's
decision make it the default (three of their versions
ago) was brave and foolhardy at the same time. I think the
remaining work as more to do with documentation and
packaging and much less to do with coding.
This 'pam_chkpwd' issue is a perfect example. lockvc is
one of a whole class of programs that need to do this
(under 'screen' there is the [Ctrl]+[A],[X] --- lock session
feature). For best practice and optimal modularity they
should all do this the same way.
One-time passwords are another example. I've come || that
close to just switching to FreeBSD because of the lack
support for OTP in GNU/Linux distributions. I actually
have recommended it for some of my customers. (Yes, I
know I *can* get it running under Linux. But I also know
--- from two years of work as "the answer guy" that the
average sysadmin --- let alone the average user --- can't).
I'm not asking for more modules or more coding. I'm
asking for *some* of the existing base of modules to be
polished, integrated and packaged. It appears that there
are aspects of PAM and the RFC's that relate to SSO/XSSO
that are hung up "in committee" (with the IETF and TOG,
or whatever). Fine! Let's get our code base together to
whatever degree consistency with the current drafts allow
and plan on changes for 1.1 or whatever.
I'd offer to do more myself, but I can't. I'm not a
developer, I'm a sysadmin, writer and tech support guy.
I'm PAM's "customer." I'm sorry if I sound grumpy.
PAM was an exciting project when I first hear about it.
Now (two years later) it seems like it's been 70% done
and making no progress. Obviously it isn't very 'sexy'
to most of the freeware world since there haven't been
developers clamoring to "take it over" --- but it needs
to get further along. This is particularly true if
it's to become part of the LSB (which I think it should
I recently bit the bullet and installed OPIE on one of my
systems. I'll try to post a PAM/OPIE mini-HOWTO draft
to this list in a couple of days to solicit suggestions.
Hopefully that will solve that problem.
> If people send me patches, I'm resolved to make more releases. Now that
> I have a CVS tree for Linux-PAM, I can sanely develop things in
> parallel. I'll release code I've written when it is written.
> [I'm going to be really reticent about distributing anything that comes
> close to reversible cryptography, but I have added a script to the
> latest release (see modules/download-all). I'll be more than happy to
> add download "instructions" to this file for stuff that falls into the
> crypto category..]
Have you ever used OPIE or S/Key? They don't use any
*reversible* cryptography. They use MD5 (or MD4 or even
MD2), One could write a version that used SHA-1 (NIST Hash)
--- or Haval, or Snefru.
These are *hashing* algorithms and are specifically
*allowed* even by our insane crypto regulations.
I could understand this concern with regards to
SRP (Standford University's 'secure remote password')
facility --- which also doesn't use crypto --- but
which implements a zero-knowlege proof that is not
as clearly "legal" However, S/Key and OPIE are pretty
obviously not crypto (any more than MD5 and SHA-1 are).
(As far as I know you already have MD5 as well as
DES hashing built into pam_unix and pwdb. So there
is no crypto algorithm in OPIE that's not already
in PAM. Furthermore DES used as a hash is more readily
converted to reversible cryptographic use than MD5 and
DES hashing as been the default Unix password storage
algorithm for about 30 years).
Jim Dennis (800) 938-4078 email@example.com
Proprietor, Starshine Technical Services: http://www.starshine.org
[Date Prev][Date Next] [Thread Prev][Thread Next]