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

[Peter Selinger]

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.

I would in fact argue that running a service on a privileged port adds
security, because it prevents an ordinary user from running an
upsd-impersonator program on an unprivileged port. What is to prevent
an ordinary user from running some software that listens on port 3493?
For example, while the real upsd is being restarted? This would
prevent the real upsd from claiming the port (denial of service), and
worse, could give the user the ability to shut down any slaves.

By running upsd on a privileged port, you ensure that only an
authorized server runs there. This, I believe, is the reason
privileged port exist in the first place. It seems quite reasonable to
me.

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. 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.
 
> 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.
> 
> -- 
> 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
> 
> _______________________________________________
> Nut-upsdev mailing list
> Nut-upsdev at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
>