net_admin audit for setsockopt SO_SNDBUFFORCE

net_admin audit for setsockopt SO_SNDBUFFORCE

[cgzones]

Hi list,
this thread[1] about setsockopt(...,...,SO_SNDBUFFORCE), which
triggers widely due to systemd, let me think about the recent SELinux
kernel fixes: the reordering of dac_read_search and dac_override and
also the cap_wake_alarm fix.

Would it make sense to test, if the send buffer is really set to a
higher value than wmem_max, before testing for the cap_net_admin
permission[2]?
(might also apply to SO_RCVBUFFORCE)

Best regards,
    Christian Göttsche


[1] http://oss.tresys.com/pipermail/refpolicy/2017-March/009185.html
[2] https://github.com/torvalds/linux/blob/ae50dfd61665086e617cc9e554a1285d52765670/net/core/sock.c#L715


p.s.: friendly ping on https://marc.info/?l=selinux&m=148944677530753&w=2

Re: net_admin audit for setsockopt SO_SNDBUFFORCE

[Stephen Smalley]

On Tue, 2017-03-21 at 16:06 +0100, cgzones wrote:
> Hi list,
> this thread[1] about setsockopt(...,...,SO_SNDBUFFORCE), which
> triggers widely due to systemd, let me think about the recent SELinux
> kernel fixes: the reordering of dac_read_search and dac_override and
> also the cap_wake_alarm fix.
> 
> Would it make sense to test, if the send buffer is really set to a
> higher value than wmem_max, before testing for the cap_net_admin
> permission[2]?
> (might also apply to SO_RCVBUFFORCE)

Probably not, since SO_SNDBUFFORCE only exists to allow a process with
CAP_NET_ADMIN to override the wmem_max limit per the man page.  IOW,
only processes with CAP_NET_ADMIN should ever use that option. 
dontaudit'ing that does not seem like a good idea either; I think you
have to allow it or risk silent breakage.

What would perhaps be better would be to introduce LSM hooks to allow
finer-grained distinctions to be made among the different CAP_NET_ADMIN
cases, ala issue #26.  Then the impact of allowing net_admin would be
less significant.


> 
> Best regards,
>     Christian Göttsche
> 
> 
> [1] http://oss.tresys.com/pipermail/refpolicy/2017-March/009185.html
> [2] https://github.com/torvalds/linux/blob/ae50dfd61665086e617cc9e554
> a1285d52765670/net/core/sock.c#L715
> 
> 
> p.s.: friendly ping on https://marc.info/?l=selinux&m=148944677530753
> &w=2
> 
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho
> .nsa.gov.

Re: net_admin audit for setsockopt SO_SNDBUFFORCE

[Russell Coker]

On Tuesday, 21 March 2017 2:01:04 PM AEDT Stephen Smalley wrote:
> On Tue, 2017-03-21 at 16:06 +0100, cgzones wrote:
> > Hi list,
> > this thread[1] about setsockopt(...,...,SO_SNDBUFFORCE), which
> > triggers widely due to systemd, let me think about the recent SELinux
> > kernel fixes: the reordering of dac_read_search and dac_override and
> > also the cap_wake_alarm fix.
> > 
> > Would it make sense to test, if the send buffer is really set to a
> > higher value than wmem_max, before testing for the cap_net_admin
> > permission[2]?
> > (might also apply to SO_RCVBUFFORCE)
> 
> Probably not, since SO_SNDBUFFORCE only exists to allow a process with
> CAP_NET_ADMIN to override the wmem_max limit per the man page.  IOW,
> only processes with CAP_NET_ADMIN should ever use that option. 
> dontaudit'ing that does not seem like a good idea either; I think you
> have to allow it or risk silent breakage.

We have had sshd, tor, and rpcbind denied access to that for some time without 
any apparent breakage.

> What would perhaps be better would be to introduce LSM hooks to allow
> finer-grained distinctions to be made among the different CAP_NET_ADMIN
> cases, ala issue #26.  Then the impact of allowing net_admin would be
> less significant.

Yes that would be good.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

Re: net_admin audit for setsockopt SO_SNDBUFFORCE

[Stephen Smalley]

On Wed, 2017-03-22 at 22:49 +1100, Russell Coker wrote:
> On Tuesday, 21 March 2017 2:01:04 PM AEDT Stephen Smalley wrote:
> > On Tue, 2017-03-21 at 16:06 +0100, cgzones wrote:
> > > Hi list,
> > > this thread[1] about setsockopt(...,...,SO_SNDBUFFORCE), which
> > > triggers widely due to systemd, let me think about the recent
> > > SELinux
> > > kernel fixes: the reordering of dac_read_search and dac_override
> > > and
> > > also the cap_wake_alarm fix.
> > > 
> > > Would it make sense to test, if the send buffer is really set to
> > > a
> > > higher value than wmem_max, before testing for the cap_net_admin
> > > permission[2]?
> > > (might also apply to SO_RCVBUFFORCE)
> > 
> > Probably not, since SO_SNDBUFFORCE only exists to allow a process
> > with
> > CAP_NET_ADMIN to override the wmem_max limit per the man
> > page.  IOW,
> > only processes with CAP_NET_ADMIN should ever use that option. 
> > dontaudit'ing that does not seem like a good idea either; I think
> > you
> > have to allow it or risk silent breakage.
> 
> We have had sshd, tor, and rpcbind denied access to that for some
> time without 
> any apparent breakage.

Two concerns with that:
1) The breakage might be subtle and not apparent, but nonetheless real.
  They are presumably using SO_SNDBUFFORCE for a reason, not just for
fun.  At the least, it may be degrading performance, possibly
increasing potential for DoS, or similar.

2) If we dontaudit net_admin now for SO_SNDBUFFORCE, and any of these
programs later introduce code (or any of the libraries that they use do
so) that actually requires net_admin for another purpose, we won't see
the denial and users will experience breakage with no indication as to
cause.

> 
> > What would perhaps be better would be to introduce LSM hooks to
> > allow
> > finer-grained distinctions to be made among the different
> > CAP_NET_ADMIN
> > cases, ala issue #26.  Then the impact of allowing net_admin would
> > be
> > less significant.
> 
> Yes that would be good.
> 

Re: net_admin audit for setsockopt SO_SNDBUFFORCE

[Russell Coker]

On Wednesday, 22 March 2017 9:28:13 AM AEDT Stephen Smalley wrote:
> > > Probably not, since SO_SNDBUFFORCE only exists to allow a process
> > > with
> > > CAP_NET_ADMIN to override the wmem_max limit per the man
> > > page.  IOW,
> > > only processes with CAP_NET_ADMIN should ever use that option. 
> > > dontaudit'ing that does not seem like a good idea either; I think
> > > you
> > > have to allow it or risk silent breakage.
> > 
> > We have had sshd, tor, and rpcbind denied access to that for some
> > time without 
> > any apparent breakage.
> 
> Two concerns with that:
> 1) The breakage might be subtle and not apparent, but nonetheless real.
>   They are presumably using SO_SNDBUFFORCE for a reason, not just for
> fun.  At the least, it may be degrading performance, possibly
> increasing potential for DoS, or similar.

For TOR the issue of DoS is relevant, although I am dubious about the idea 
that TOR might be unable to operate with the default buffer settings of any 
supported OS.  Also I'm generally dubious about the idea that a DoS might be 
enabled by preventing a daemon from enlarging it's buffers rather than being 
prevented by it.

Generally rpcbind should not be exposed to the public Internet, if it is then 
you might have bigger problems than buffer sizes.

As sshd is one of the most common targets of attack on the Internet it seems 
very unlikely to me that buffer sizes would be the problem.  For most servers 
it's just non-stop probes and attempts to brute-force passwords on port 22.

> 2) If we dontaudit net_admin now for SO_SNDBUFFORCE, and any of these
> programs later introduce code (or any of the libraries that they use do
> so) that actually requires net_admin for another purpose, we won't see
> the denial and users will experience breakage with no indication as to
> cause.

Yes this is a real issue.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/