[SRU] ACL covering all IPv4 addresses is broken in 2.2.1

[Charles Lepple]

Binary package hint: nut

$ lsb_release -rd
Description: Ubuntu 8.04
Release: 8.04

$ apt-cache policy nut
nut:
  Installed: 2.2.1-2.1ubuntu7
  Candidate: 2.2.1-2.1ubuntu7
  Version table:
 *** 2.2.1-2.1ubuntu7 0
        500 http://us.archive.ubuntu.com hardy/main Packages
        100 /var/lib/dpkg/status

To accept connections from all IPv4 addresses, the following statement would be used in /etc/nut/upsd.conf:

ACL all 0.0.0.0/0
ACCEPT all

Instead of accepting all addresses, it rejects all (the default if no ACLs match).

This bug was fixed upstream, and released as part of nut-2.2.2. The patch is here:

http://svn.debian.org/viewsvn/nut?rev=1269&view=rev

A temporary workaround is to create two rules which cover the full set of IPv4 addresses:

ACL all0 0.0.0.0/1
ACL all128 128.0.0.0/1
ACCEPT all0
ACCEPT all128

[Chuck Short (zulcss)]

Hi,

Thanks for the bug report can you try the package in my ppa? (http://launchpad.net/~zulcss/+archive)

Thanks
chuck

[Charles Lepple (clepple)]

Chuck,

version 2.2.1-2.1ubuntu7.2~ppa1 seems to have fixed the ACL bug.

regards,
- Charles

[Charles Lepple (clepple)]

Noticed that this bug is still marked as "incomplete" - do you need any more information?

[Chuck Short (zulcss)]

Yes can you try the package in my ppa. (http://launchpad.net/~zulcss/+archive)

Thanks
chuck

[Charles Lepple (clepple)]

I tried the package in your PPA on 2008-06-30 (see above), and as far as I can tell, the patch included in 2.2.1-2.1ubuntu7.2~ppa1 fixes this bug (that is, I can now use 0.0.0.0/0 as an ACL entry instead of having to use two separate 1-bit netmasks).

(Should I set the status to "confirmed" myself? I assumed that "confirmed" meant that the package maintainer was confirming the validity of the bug report.)

$ lsb_release -rd
Description: Ubuntu 8.04
Release: 8.04

$ apt-cache policy nut
nut:
  Installed: 2.2.1-2.1ubuntu7.2~ppa1
  Candidate: 2.2.1-2.1ubuntu7.2~ppa1
  Version table:
 *** 2.2.1-2.1ubuntu7.2~ppa1 0
        500 http://ppa.launchpad.net hardy/main Packages
        100 /var/lib/dpkg/status
     2.2.1-2.1ubuntu7.1 0
        500 http://us.archive.ubuntu.com hardy-updates/main Packages
     2.2.1-2.1ubuntu7 0
        500 http://us.archive.ubuntu.com hardy/main Packages

[Chuck Short (zulcss)]

Thanks Ill get this fixed for hardy, I can take of the rest thanks for you help in testing this.

chuck

[Charles Lepple (clepple)]

Excellent. Thanks for handling this!

[Chuck Short (zulcss)]

Impact: Nut was shipped with a bug that causes the reverse intention when using ipv4 acls. In this case, instead of accepting the connections it rejects them.

STEPS TO REPRODUCE:

1. See above.

I have attached the debdiff which fixes this issue. If you have any questions please feel free to contact me.

Regards
chuck

[Steve Langasek (vorlon)]

Hi Chuck,

I have doubts whether this particular bug warrants an update. My understanding from reading the patch is that the reason the acl fails to work as intended is not because the sense of the acl is inverted, but because the acl matches no addresses instead of all addresses.

So since denying appears to be the default, it seems that the only case broken by this is giving all IP addresses access to nut. Is this ever really a good idea? Or have I overlooked some other reason that this makes sense?

If the only use case this breaks is something which is simply a bad security policy, I don't see this as justifying pushing a new SRU on its own and requiring people to re-download the package.

[Charles Lepple (clepple)]

On Fri, Aug 22, 2008 at 6:26 PM, Steve Langasek wrote:
> So since denying appears to be the default, it seems that the only case
> broken by this is giving all IP addresses access to nut. Is this ever
> really a good idea? Or have I overlooked some other reason that this
> makes sense?

Steve,

Sorry to jump in again, but I know that a lot of sysadmins prefer to
centralize their access control rules at the OS level, rather than
deal with the nuances of each application's ACLs. In that situation,
an all-open ACL is acceptable, since the OS (in this case,
iptables/netfilter) would have finer-grained control.

Note also that newer versions of NUT are dropping ACLs in favor of
binding to interfaces (with a failsafe default of not binding to any
interfaces automatically). I believe the rationale was that by binding
to a specific interface, there is no chance for someone to exploit any
potential holes in the NUT ACL code.

Hope that helps.

--
- Charles Lepple

[Steve Langasek (vorlon)]

Hi Charles,

Well, most sysadmins that I know, including the sysadmin that is me :),
prefer security in depth and don't want an either-or choice between
application-level and system-level ACLs.

> Note also that newer versions of NUT are dropping ACLs in favor of
> binding to interfaces (with a failsafe default of not binding to any
> interfaces automatically). I believe the rationale was that by binding
> to a specific interface, there is no chance for someone to exploit any
> potential holes in the NUT ACL code.

That's not a meaningful solution for users who want to allow remote access
from certain addresses and only have one interface.

[Charles Lepple (clepple)]

On Aug 26, 2008, at 8:11 PM, Steve Langasek wrote:

> Hi Charles,
>
> Well, most sysadmins that I know, including the sysadmin that is
> me :),
> prefer security in depth and don't want an either-or choice between
> application-level and system-level ACLs.

Understood, but at the very least, application-level ACLs are
probably better handled by something like libwrap, with a common
syntax, and a more thoroughly-inspected codebase. We don't want to
lull users into thinking that the NUT ACLs are a complete replacement
for firewall rules.

>> Note also that newer versions of NUT are dropping ACLs in favor of
>> binding to interfaces (with a failsafe default of not binding to any
>> interfaces automatically). I believe the rationale was that by
>> binding
>> to a specific interface, there is no chance for someone to exploit
>> any
>> potential holes in the NUT ACL code.
>
> That's not a meaningful solution for users who want to allow remote
> access
> from certain addresses and only have one interface.

This is starting to stray from the original issue in this bug
regarding 2.2.1. I don't want to misrepresent the intentions of the
rest of the NUT team - do you mind if I quote this message and some
history on the NUT developer list, and CC you?

[Arnaud Quette (aquette)]

Hi there,

2008/8/27 Charles Lepple :
> On Aug 26, 2008, at 8:11 PM, Steve Langasek wrote:
> ...
> This is starting to stray from the original issue in this bug
> regarding 2.2.1. I don't want to misrepresent the intentions of the
> rest of the NUT team - do you mind if I quote this message and some
> history on the NUT developer list, and CC you?

back from vacation, I've not seen anything about this on nut-dev...
Charles, are you waiting for an ack from Steve?

about the NUT ACL removal, the idea is simply that it's better managed
by a central system like the firewall, which offers more features in a
central point. We are in general trying to simplify NUT and reduce it
to its real aim / added value: acquiring and proxying data from UPS
devices, and eventually propose complementary feature like monitoring
these data and acting upon UPS events.

hope that helps too,
Arnaud

[Steve Langasek (vorlon)]

On Wed, Aug 27, 2008 at 12:37:20AM -0000, Charles Lepple wrote:
> > Well, most sysadmins that I know, including the sysadmin that is
> > me :),
> > prefer security in depth and don't want an either-or choice between
> > application-level and system-level ACLs.

> Understood, but at the very least, application-level ACLs are
> probably better handled by something like libwrap, with a common
> syntax, and a more thoroughly-inspected codebase. We don't want to
> lull users into thinking that the NUT ACLs are a complete replacement
> for firewall rules.

Well, that's fine (though I think any user who concludes that an
application-level ACL implementation is a complete replacement for firewall
rules has really not been paying attention); but I don't think philosophical
points about whether the ACL feature should be used are a very strong
justification for a stable release update.

> > That's not a meaningful solution for users who want to allow remote
> > access from certain addresses and only have one interface.

> This is starting to stray from the original issue in this bug
> regarding 2.2.1. I don't want to misrepresent the intentions of the
> rest of the NUT team - do you mind if I quote this message and some
> history on the NUT developer list, and CC you?

Yes, that's fine.

On Tue, Sep 02, 2008 at 01:14:11PM -0000, Arnaud Quette wrote:

> about the NUT ACL removal, the idea is simply that it's better managed
> by a central system like the firewall, which offers more features in a
> central point.

That is contrary to the best practices security model relied upon by nearly
all network servers. I don't think that's an improvement, really; but
that's fairly off-topic for this bug report.

Anyway, based on the evidence I stand by the conclusion that the impact of
this bug is not severe enough to warrant an SRU; I'm rejecting the upload
from the queue now.

[Charles Lepple (clepple)]

As a follow-up to the discussion here, libwrap replaces the old NUT ACL functionality in the upcoming nut-2.4.0 release. This provides application-level connection filtering using a fairly well-known ACL syntax.