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/ _______________________________________________ Selinux mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
