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

syslog options, OPIE (S/Key) -- When?

	Hi all,

	I'm in need of the following:

	syslog options:


		I'd like to find (or build) a modified 
		copy of PAM passwd that would log the following
		sort of information about attempts to change passwords:

May  9 01:13:41 myhost passwd: failed for root from
May  9 01:17:41 myhost passwd: forced for jon from  /dev/tty4 (jimd)
May  9 08:13:41 myhost passwd: changed for gary from  /dev/ttyS1 

		... the idea here is to know whenever a passwd change
		is attempted -- and when it was successful,
		forced by root, or failed.  I also want to know where
		it came from (device or IP address) and the ownership of 
		the controlling tty (in the case of forced changes).

		This last requirement gives a hint as to which member
		of "wheel" issued a change.  That would be a useful --
		though not "strong" -- audit issue.

		(While we're on the topic of syslogging it would
		also be nice to syslog all 'chmod +s' attempts and

		The main reason I want this is because I create
		a lot of accounts for FTP and POP only access.  I 
		like to set the /etc/passwd shell field to /bin/passwd
		for those accounts -- so the user can still change their 
		password -- but such that they cannot access shell 
		services on these servers.  (Yes, I'm using the 
		wu-ftpd guestgroup -- chroot configuration to prevent
		rhosts type attacks.  Yes, I monitor the bugtraq and
		linux-alert lists for the latest buffer overflow 
		announcements.  Yes, I create an immutable .rhosts
		that's empty.  No, I don't want to see another debate
		about the merits of limited service access and the 
		dangers of IFS and other environment variable attacks
		on shell scripts as login shells).

		What I'd like to do with this log is to use my 
		existing log monitor (just a shell script at
		this point -- that does a "tail -f" piped into an
		awk script) to mail confirmation/warning messages
		off to a user any time a change is attempted.
		(I'd also write the script to mail root about 
		failures and forces).

	OPIE (S/Key)

		The other thing I'm anxiously awaiting is an
		OPIE (or other S/Key compatible) PAM module for
		one-time passwords.  Although I use SSH for 
		most of my work -- many of my customer/users
		don't have ssh available to them.  I *really* want
		to discourage the use of reusable passwords throughout
		the Internet.


		Naturally I'd like to see sshd's RSA authentication 
		method turned into a PAM module -- and to see 
		sshd's password authentication (which it falls 
		back to when there isn't an appropriate entry 
		in the .ssh/authorized_keys file) use PAM
		(so that it would work un-modified if I change
		my PAM authentication to use MD5 or SHA or 
		to use some "as yet unknown" client/server database

	"As yet unknown" database authentication:

		Eventually I'd like to see a fairly generic
		client authentication module for use with 
		mSQL, Postgres '95, or some other client/
		server database system.  The idea here is that
		some of my clients distribution software 
		electronically.  I've recommended that they 
		use a method like this -- and they haven't risen
		to the challenge of doing a custom package.
		However I'd use it to allow a "Web Store" to 
		create an account -- and to allow the client
		to access it.  The problem is that this customer
		has 100's of thousands of current subscribers in
		their database.  It's not feasible to make an
		/etc/passwd file that large.

		(The plan would be to use full name, city and
		state as the key and phone number as the initial
		password -- with a forced change at initial login.
		Considering the nature of the software being 
		distributed -- a risk analysis suggests that this
		weak authentication mechanism is nonetheless sufficient
		-- so long as it can be reasonably shown that this level
		of customer access can't be subverted to get "real"
		access to the server).

	I'm excited about PAM -- since it is the first real effort
	in the last 27 years (so far as I can tell) to improve the
	authentication model for Unix -- and to allow differential
	(limited) access to the services on a given host.

Jim Dennis,                                info@mail.starshine.org
Proprietor,                          consulting@mail.starshine.org
Starshine Technical Services              http://www.starshine.org

        PGP  1024/2ABF03B1 Jim Dennis <jim@starshine.org>
        Key fingerprint =  2524E3FEF0922A84  A27BDEDB38EBB95A 

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