[Nut-upsdev] Re: [nut-commits] svn commit r731

[Henning Brauer]

* Arjen de Korte <nut+devel at de-korte.org> [2007-01-23 12:58]:
> 
> >> The listen_add() function doesn't need root access, so this shouldn't be
> >> a problem. Provided the listening socket is above 1023, setuptcp()
> >> doesn't need root access either.
> >
> > of course
> >
> >> However I don't want to limit ourselves here
> >> (there may be people wanting to setup a low port), so I want to setup
> >> the server listening sockets as root at least at startup of upsd.
> >
> > that is a really bad idea.
> 
> Maybe it is, but it is what we have been doing for years. I don't want to
> change this without fully understanding (and documenting) the changes and
> the impact this may have on system administrators.

well, let me make it more clear: it is outright dangerous.

> > 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.

> > there is no point in having nut using privileged ports.
> Probably not, but I don't want to take the risk of breaking existing
> configurations here. I wouldn't bet that nobody is running NUT on a
> privileged port because of some insane corporate policy that doesn't allow
> opening up high ports, while some low port is already opened up for
> instance. Yes, that sucks, but unless there is a significant security
> benefit to do otherwise, I'm not ready to change this.

there IS a significant security risk. sockets can get special treatment 
depending on who the owner is. And if it is only packet filtering by 
socket owner uid/gid.

-- 
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