[Nut-upsdev] Re: [nut-commits] svn commit r731
Henning Brauer
hb-nut at bsws.de
Wed Jan 24 00:14:25 CET 2007
* Peter Selinger <selinger at mathstat.dal.ca> [2007-01-23 23:41]:
> Henning Brauer wrote:
> > * Peter Selinger <selinger at mathstat.dal.ca> [2007-01-23 17:51]:
> > > Arjen de Korte wrote:
> > > > >> > root's socket ownership can have more consequences. don't do that.
> > > > >> Root doesn't own the socket, since we drop privileges before
> > > > >> backgrounding, just a short while later.
> > > > > root DOES own the socket, because it gets opened by root. that is
> > > > > recorded and does not change by the daemon dropping privileges.
> > > >
> > > > Oops! Point taken, this *has* to go (I didn't realize that).
> > > >
> > > > Fortunately, the trouble with STATEPATH requires rewriting the load_conf()
> > > > function anyway, so this takes no additional effort. People wanting to use
> > > > privileged ports (for whatever reason there may be) will have to run the
> > > > server as root then and accept the consequences.
> > >
> > > I don't think this is a good idea. If this is indeed determined to be
> > > a security problem (I still fail to see why exactly), then there
> > > should still be an option, for those who need it, of opening a
> > > privileged port and then dropping root. That is definitely safer than
> > > opening a privileged port and then continuing to run a potentially
> > > messy application as root.
> >
> > how the owner of sockets affects things is operating system dependent.
> > as I mentioned before, it is definately possible to have packet filters
> > based on socket ownersip in place; socket buffer allocation rules
> > (especilly under memory pressure) can be different, there's certainly
> > more.
> >
> > why do you want to support this in the first place? There is a risk
> > (are you 100% certain the pre-privdrop codepath is bugfree? that's why
> > you keep the lines of code running as root as low as possible...). I
> > cannot imagine anyone running nut ona privileged port - and if anybody
> > should, it's ... just plain wrong and still debatable wether nut should
> > support its users doing stupid things.
>
> I'm not so sure. Why is it any more unreasonable to run NUT on a
> privileged port than for other services, such as ftp, ssh, nameserver,
> http, ntp...? All of them run on privileged ports.
ssh, dns and even ntp are infrastructural processes that really profit
from the protection againt regular users they get from running on a
privileged port. at least ssh and ftp have to have parts running as
root in any case.
nut, on the other hand, is really not in the same league. given the
risk associated with opening sockets as root, and the almost
nonexistant benefit, there is no justification to do so.
> On the other hand, I don't understand the significance of packet
> filters or buffer allocation rules based on socket ownership. Since
> NUT is a service run by the system administrator, if it gets
> preferential buffer allocation, that would be all the more
> desirable.
so, when your system is under severe memory pressure, you prefer to be
able to remotely query yor UPS status over beeing able to log in via
ssh...?
> I don't see it as a security risk. Ditto for packet
> filters. As I understand you, port ownership will affect whether
> people connecting to that port can gain root access.
err, no, not directly.
opening the socket as root however leaves a window (until dropping
privs) where a bug might allow remote attackers to gain root access,
yes.
> > why don't you do it the other way round; open the listening sockets
> > after dropping privileges (and thus lose privileged ports, but you're
> > on the safe side), and if really anybody cries later because he is
> > using a low port and discovers that doesn't work any more, reconsider
> > adding the button.
that is still what I propose :)
--
Henning Brauer, hb at bsws.de, henning at openbsd.org
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
More information about the Nut-upsdev
mailing list