[Nut-upsdev] ACLs, binding to an interface, and libwrap

[Arjen de Korte]

> As a second layer of defense, how do you all feel about the "TCP
wrappers" functionality in libwrap? As I understand it, the
> hosts.allow and hosts.deny files offer the same level of granularity
that the NUT ACL functionality provided, but with the advantage of a
more well-known (and hopefully well-scrutinized) codebase.
>
> Many Linux distributions have shipped libwrap for years, and it
> should be fairly easy to stub out the glue code if people do not want to
bother with libwrap.
>
> Thoughts?

I have mixed feelings about this. What are we trying to achieve here by
adding libwrap? If you only want be able to monitor the UPS status
remotely, we already provide nut-cgi for that to do so via a web interface
(which is much more convenient than having to install a NUT client).

When SSL support is not used/compiled in, the use of cleartext information
(and passwords) doesn't allow it to be run over non-trusted networks in
the first place. It is probably better to open a secure shell (already
uses libwrap) in that case and run whatever you need through the loopback
interface.

When SSL support is used, setting up server- and client- certificates (and
hence, securing the information *both* ways) would be trivial. Probably
the only thing needed would be rate limiting the number of incoming
connections to prevent people overloading upsd with connections. This is
something that can be done much easier through a firewall than through
libwrap.

Last but not least, I don't think it is a good idea to expose such a
critical piece of infrastructure like NUT to a (potentially) hostile
environment, no matter how many layers of security are built in. Thats the
basic reason why I added the option of binding to one (or more) interfaces
instead of weeding out the incoming connections we don't like afterwards.

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