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

Re: Open Xlock as root

>>>>> "Ethan" == Ethan Benson <erbenson@alaska.net> writes:

    Ethan> On 3/12/99 Thomas Meinders wrote:

    Ethan> the only other solution I can think of is to create either a new PAM 
    Ethan> module/helper program that will verify the calling user's password 
    Ethan> and the root password.  this module could be used only for programs 
    Ethan> that require it such as the *locks

I certainly agree, and was just looking at viable options before I
finished reading your email here ...

    Ethan> modifying the main pam_unix and pam_pwdb helpers to always check 
    Ethan> root's password would not be a good solution since it would almost 
    Ethan> effectively unshadow the root password.

I agree here, too, in that changing the present pam_pwdb would
definitely be a bad move.  First of all, it shouldn't be the default
to always check root's password, for obvious reasons.  Second of all,
on a picky level, that's just a bunch of processing that we don't need
to be doing.  Thirdly, checking against root's password also
effectively doubles the chances that a password-guesser will
inadvertently get access.

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

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.

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.

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?)

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.

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



William Evans                 < william . evans @ computer . org >

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