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

[Peter Selinger]

Arjen de Korte wrote:
> 
> 
> > 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.
> 
> Why would you want to restart upsd? This will never happen automatically,
> so you'd have to be logged in as 'root' on a console (or via ssh, or
> whatever). In that case, you'd notice that NUT is unable to claim the port
> and take appropriate action (NUT *will* complain about not being able to
> claim the port). I'm not worried about this. If an ordinary user is able
> to convince upsd to restart (or stop, which would be just as easy), you're
> toast anyway. If people are worried about whether or not upsd is
> legitimate, they need to run NUT with SSL enabled.

Your argument supports the thesis that running on a privileged port
need not be the default. It doesn't support why we should make it
impossible to do so.
 
> > 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.
> 
> I'm a little worried that we're talking about the theoretical possibility
> that someone might be running NUT on a privileged port. So far, I have no
> reports on this (and no proof of the contrary either). I feel strongly
> with Henning that we should limit our exposure to attacks, by running as
> little code as possible as root. If that means we loose the possibility of
> running NUT on a privileged port, that's something we really should
> consider. 

Yes, we should limit our exposure to attacks. But this should be based
on real security considerations, not some kind of paranoia. I have not
seen any evidence that opening a port as root just before dropping
privileges is, in fact, a security problem. There's some issue about
buffer allocation in low memory conditions, which is, in my opinion,
not a security consideration but one of convenience.

> Short of the fact that people may not be able to open a high
> port in a firewall for some insane corporate policy, I see no real
> benefits for the privileged ports.

Perhaps a reasonable solution is to drop privileges by default
immediately after chroot() and reading upsd.conf, and to allow an
option for delaying it until after the sockets are opened. In fact, if
the socket opening fails, one could print an error message such as
"Unable to open privileged port 678 as user 'nut'. If you really want
to do this, please retry with the --privileged option".

-- Peter