Re: Ports 0-1023?

[Brian Hatch <vuln-dev () ifokr org>]

> > Take
> > suexec, part of Apache.  It's a suid executable that has a quite rigid
> > set of conditions that must be correct for it to run a CGI as a
> > different user.  The most important rule being that the suexec program
> > is only called from the webserver user, which is specified at suexec
> > compile time.
> >
> > Something like this would be needed for user 'telnetd' to let you
> > log in as you, instead of it.
>
> I've never looked at the su source, but that's pretty much exactly what I 
> had in mind.

Well 'su' has only two checks: if the supplied password is correct,
and if the user is in the wheel group.  And that later requirement
is only for some OSs.

See suexec's security model at http://httpd.apache.org/docs/suexec.html
I think a service-specific uid-granting program would probably not
have all the same requirements because Apache CGI execution is a bit
more interesting, but the guts are probably the same.  You'd only really
need one suid program to do this if you write it to read a config file, ala

        $ cat uid-granter.conf
        # invoking-program   expected-user   suid-to, ...

        /usr/sbin/sshd       sshd            *
        /usr/sbin/imapd      imapd           !root,*
        ...

> It seems like a good idea to me to keep as much of the authentication code 
> in one place as possible, and let programs call that.  At present, that 
> seems to be PAM.  Just seems a better idea than letting each program 
> reimplement the same thing, and having that many more opportunities to get 
> it wrong.

I think that authentication (PAM) should be very separate from
any uid-granting executable.  And really, I can't see a way
to make it work all in PAM anyway.

> I'm also trying to enable daemons that don't really need to be root at all, 
> the ones that only wanted root in order to bind to a low port (save of 
> course that at present the DO have to be root at least part of the time to 
> ge the low port).

Getting that change to a standard kernel is not likely, unfortunately.
It's a great idea, if done right, but we seem to have enough
documentation about dropping privs instantly for progs that never
require root for authentication/uid switching that this doesn't seem
a very important change.  Likewise we have enough workarounds
(inetd/xinetd/etc that can listen as root and setuid() before execing
the actual program) that it's not so problematic.

But some sort of uid-granting helper app could be useful in some scenarios.


> Add to that some daemons that also needed root to 
> authenticate people.. and could just do so through PAM, and you might make 
> a dent in reducing the amount of code run as root.

For things that do not need to have root to setuid(), then I don't
see how much code you're going to save.  Drop privs, close unneeded
file descriptors, etc, and you're done.  Probably ~10 lines.






--
Brian Hatch                  "Not propaganda, goodfacts, as
   Systems and                opposed to realfacts.  Facts
   Security Engineer          the government has endorsed."
http://www.ifokr.org/bri/

Every message PGP signed

Attachment: _bin
Description: