Nut upsdev - Sep 2008 - ACLs, binding to an interface, and libwrap

All,

There was some discussion recently on Ubuntu Launchpad regarding the  
bug in NUT 2.2.1 where it was not possible to connect with an accept- 
all ACL:

https://bugs.launchpad.net/bugs/235653

The package was patched for the upcoming Ubuntu release (intrepid),  
but the discussion drifted to the merits of application-level ACLs  
(comment 11 and beyond).

Steve Langasek brings up a good point about "security in depth,"  
citing a case where binding to an interface isn't granular enough,  
but I still tend to agree with Arjen and Arnaud that ACLs are better  
handled by a central firewall.

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?

-- 
Charles Lepple
clepple at gmail

> 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