OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: Darren Kenny (Darren.Kennyireland.sun.com)
Date: Tue Feb 20 2001 - 02:48:57 CST

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    The 'NORM' in situations like this is that the application (in this case
    httpd) is run initially as root - which is usually the case to bind to
    port 80 - and then it setuid's to the user nobody. The main thing is that
    the httpd process has root privileges still, it can temporarily setuid to
    root to do things that require root privileges (such as authentication) and
    then drop back down to the lower privilege for everything else... That's
    usually how this is handled as it should be possible for any PAM library to
    be able to assume it's root when it's doing privileged operations like
    authentication.

    Hope this helps,

    Darren.

    Roger Dunk wrote:
    >
    > Thanks guys. That does make sense now. I'll think I'll do what you suggested
    > and modify unix_chkpwd. I guess the thing that stumped me (and caused untold
    > hours of pain) was that the default PAM libs that shipped with the Cobalt
    > RAQ3 must have already allowed user/group 'http' to verify any
    > login/password against /etc/shadow, which I automatically assumed to be the
    > norm. Ohh well, you live and learn eh.
    >
    > Cheers...
    > Roger
    >
    > ----- Original Message -----
    > From: "Ben Collins" <bcollinsdebian.org>
    > To: <pam-listredhat.com>
    > Sent: Tuesday, February 20, 2001 2:57 PM
    > Subject: Re: /etc/shadow problem
    >
    > > >
    > > > This question comes up often enough that I've considered writing a
    > number of
    > > > unix_chkpwd variants that could be shipped with Linux-PAM (but not
    > enabled by
    > > > default!). I'm still not sure if this is a good idea, or if it's just
    > inviting
    > > > trouble when admins start using that functionality without examining the
    > > > security implications...
    > > >
    > >
    > > You could probably modify unix_chkpwd to check a config file, or
    > > hardcoded group for "trusted" users that can verify any uid, then make
    > > it suid root. Would require some special care, but it might prove
    > > useful. Then you can just make the web server's uid/gid part of the
    > > trusted group, so it can verify from pam_unix.so.
    > >
    > > Ben
    > >
    > > --
    > > -----------=======-=-======-=========-----------=====------------=-=-----
    > -
    > > / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux
    > \
    > > ` bcollinsdebian.org -- bcollinsopenldap.org -- bcollinslinux.com
    > '
    > >
    > `---=========------=======-------------=-=-----=-===-======-------=--=---'
    > >
    > >
    > >
    > > _______________________________________________
    > > Pam-list mailing list
    > > Pam-listredhat.com
    > > https://listman.redhat.com/mailman/listinfo/pam-list
    >
    > _______________________________________________
    > Pam-list mailing list
    > Pam-listredhat.com
    > https://listman.redhat.com/mailman/listinfo/pam-list

    _______________________________________________
    Pam-list mailing list
    Pam-listredhat.com
    https://listman.redhat.com/mailman/listinfo/pam-list