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

[Arjen de Korte]

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

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

Best regards, Arjen
-- 
Eindhoven - The Netherlands
Key fingerprint - 66 4E 03 2C 9D B5 CB 9B  7A FE 7E C1 EE 88 BC 57