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/ _______________________________________________ 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.
