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

Re: Open Xlock as root



Ethan Benson wrote:
> >Okay, I'll take this one step further.  Why force a check to root's
> >password?  Would it be perhaps more advantageous to check somebody
> >else's password, like the administrator's, so that root's password is
> >never entered into the equation?  Perhaps putting the name of the user
> >to check against in a root-read-only file in /etc/ (so that nobody
> >else can see who's account to hack into) would allow some flexibility.
> 
> I like this idea, the ability to specify a user would be good, for
> example the sysadmin could choose his normal user account instead of
> the root password.  I don't know if the separate file is really
> necessary I suppose it would be an interesting option

This seems reasonable.

I'd opt for adding a command line option to the helper binrary: 'extra'?
That would say 'if you fail to authenticate the current uid' then log
the the fact that you went on to check against the passwords of the
users listed in /etc/security/admins.conf .

This puts the control in the local admins. (Who might dedicate an
account for this particular purpose, or use their own, or use root's,
whatever..). It does not subvert the whole (dubious) idea of shadow
protection, and would be turned on and off via a pam_unix.so (or
pam_pwdb.so) module argument.

One thing to be aware of: there is no protection from someone
maliciously running the helper binary from a perl script (say) and brute
forcing these extra user's passwords. But at least this way, if you
don't want this feature on your system, you can remove the
/etc/security/admins.conf file.

Anyone want to submit such a patch?

Cheers

Andrew



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