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

Re: xlockmore (pam)

Aleph One:
> On Mon, 9 Sep 1996, Elliot Lee wrote:
> > What is wrong with just plain using getpwnam() and getspnam()? If they
> > fail then obviously you don't have read permissions 
> Simple. If using getpwname or getspname directly the application must be
> suid or sgid to whatever owns the shadow file. This means than any
> vulnerability in the program could cause a security breach. It much easier
> to verify a small program whose only purpose it to handle the
> readin/writing to the shadow file that say verifying xlock.

Actually, recent (non-PAM) versions of xlockmore and vlock should be
fairly safe.  They do one thing you probably can't do with PAM: get
the user's encrypted password at startup using getspnam(), and do
setuid(getuid()) as soon as possible.  This means that most of the
code (fancy screen savers etc.) is run as the calling user (not root),
and it is also possible to handle errors better.

With PAM and/or a helper program run at the time the user is
authenticated, you can do one of two things if you get an error
because you can't get the necessary information: (1) unlock and exit,
or (2) don't unlock.  Now let's say we are using NIS...  (1) is bad
because anyone can unlock a workstation by unplugging it from the
network.  (2) is bad because you can't unlock and save your work
if the network or the NIS server goes down.  Not good.

The alternative is to use xlockmore-3.9 and vlock-0.9 unmodified,
without PAM support, and make them setuid root (setgid shadow may
not be enough if you have to use a port <1024 to get the info).

Of course, you lose the pluggability - both shadow and non-shadow
passwords are supported, MD5 and other fancy algorithms can be
supported by linking with a small shared libcrypt.so library (or
adding MD5 to libc, or adding libcrypt.so to /etc/ld.so.preload
- works only with ld.so-1.8.x which is beta), but that's all.
But maybe it is a small price to pay for making *lock programs
more reliable.  Not many people will use S/Key with xlock...

To repeat: setuid root xlockmore (version 3.9 or later) *should*
be secure (probably modulo the recent libXt bugs, but that affects
many other programs anyway, such as xterm).



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