[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: PAM and shadow



 
> 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)
> 
> /sbin/pwdb_chkpwd
> 
>> 
>>  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*
	bugs.


>>  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
	shoot for).

	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).
	
 
> Cheers
> Andrew


--
Jim Dennis  (800) 938-4078		consulting@starshine.org
Proprietor, Starshine Technical Services:  http://www.starshine.org



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []