OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: Dawes, Rogan (ZA - Johannesburg) (rdawesdeloitte.co.za)
Date: Mon Jul 08 2002 - 02:01:06 CDT

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

    >
    > I have one more specific question regarding daemons that take
    > authentication, and switch to another uid. For something
    > like a telnetd,
    > or sshd that uses PAM.... in order to drop to a shell as the
    > uid of the
    > authenticated user, do they really need root? If you have the
    > authentication information for the user, then you could call
    > the system
    > call equivalent of su, right? So the daemon is actually going after a
    > privilege gain rather than a drop, because it starts as some
    > account that
    > can really only bind a special port.
    >

    Apart from the fact that "su" is setuid root in order to achieve this?

    AFAIK, the ONLY way to become a different user under Unix is if root says
    you can. Either via a suid root binary ("su"), or a service/daemon running
    as root, e.g. telnet, sshd, rshd, etc. I suspect this is essentially the
    same under NT/2000 as well.

    It may be possible to code a limited "getprivs" program analogous to su,
    that would return the "privileges" of the user credentials supplied.
    Something like sshd's privsep code, where a limited root process simply
    validates authentication credentials, and returns a "user owned" token that
    allows them to do what they need to. e.g. a user owned fd, or pty, or
    whatever.

    Well, it looks like I was talking rubbish. Even under sshd's privsep, the
    privileged ssh daemon still forks a user owned process. I don't see a clean
    interface to this that could be used by arbitrary processes.

    See http://www.citi.umich.edu/u/provos/ssh/privsep.html

    It sounds to me like we want something like "sudo" for applications . . .

    Rogan