> >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
This archive was generated by hypermail 2b30 : Fri Jul 05 2002 - 10:28:25 PDT