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

Re: Open Xlock as root

On 3/12/99 william.evans@computer.org wrote:

However, making a modified pam_pwdb (or a skeleton module) to check root's password, so that it can be inserted into xlock's pam file like this:

auth       sufficient   /lib/security/pam_rootpassok
auth       required     /lib/security/pam_pwdb shadow

where pam_rootpassok is the module to check root's password.  In this
situation, all the administrator would have to do would be to put this
line in those services where (1) it makes sense to use it, and (2) the
administrator really wants it.  In other words, don't use it somewhere
unless required.

I like this idea, I think it is probably better to write a small separate module then to tinker with the current ones possibly introducing bugs. this lets the sysadmin remove that root check easily and permanently even with upgrades of the *lock utilities (as long as the package is done right and considers the pam.d/* file as a configuration file...), where the setgid shadow will likely come back every time the package is updated (by RPM at least, Debian has a system that allows suid changes to be preserved even in package upgrades)

One argument against doing this is valid: if somebody gets to the
xlocked terminal and starts guessing passwords to get in, this module
effectively gives them two possible solutions instead of just one,
thereby increasing the odds that they find one.  Granted, the odds are
still slim, and hopefully root's password is sufficiently obscure, but
the odds are still increased.

true, but prior to PAM this is how these utilities used to work, they checked both root's and the user's password, and there was no choice in the matter short of modifying the source. with PAM we can cleanly leave this up to the local sysadmin.

The question here is: should the module be made, allowing the
administrator to slightly weaken their system?  I vote yes, and given
enough time, I'll even work on the module.  (On that note: does it
make any sense to have account/password/session components when all
it's there for is authentication?)

I do not see any reason for any function other then auth. and as to your first question, one of the reasons for PAM is to give the admin more control over how secure or not his system is, with PAM you can remove security entirely (just replace pam.d/login file's contents with pam_permit.so) so the choice is already there to SEVERELY weaken security an added choice to allow two passwords to open *lock is nothing compared to what you already have the option to do.

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

Other options are there, like allowing any user from a specific group
to work, but I really think putting in too much complicates it and
opens up too much for practical use.  Keeping it simple with root's or
one user's password is better (IMO).

yes we don't want to make it to complicated as that just leads to more bugs. I tend to think allowing more then 2 passwords to work is getting excessive. the only time I can think where more then the user's and root's (or roots normal account instead) is where there is multiple sysadmins, in this case they can either just have it check root's (which they all presumably know) or else they would need an extra shared account, perhaps this is a good place for that separate passwd file you suggested above.

that separate file does have an advantage in that even if someone gets/guesses its password it does them little good (except for breaking into users' locked consoles) since it is not a valid user account on the system.

-- Ethan Benson To obtain my PGP key: http://www.alaska.net/~erbenson/pgp/

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