I disagree. I've had to have technical discussions justifying my belief that certain common things should be available to all domains such as /dev/urandom and more recently /proc/sys/vm/overcommit_memory. Discussions around those reasonable defaults basically rotate around the philsophical notion of least privilege. So seeing there's an entire swath of ports that programs can bind to by default is crazytalk and blows that notion out of the water. Further, it is bad policy. Consider sshd, or any other daemon that does nothing but bind to a port and listen for connections. It does not need the ability to bind to to anything other than its' daemon port, not even epheremal ports. Yet it can, regardless of policy considerations. Which is the underlying point here. If someone gains access to a server through a compromised service, they can bind a backdoor to that epheremal range or at least exfil data. This is bad, bad, bad and rather surprising because until it was pointed out by this thread I would not have considered it possible due to the...vehemence... in which least privilege has been upheld. On Fri, Jan 9, 2015 at 3:52 PM, Stephen Smalley <stephen.smalley@xxxxxxxxx> wrote: > Ports in the local port range can be auto-assigned by the kernel to > unbound sockets on first use. So it makes no sense to control them, > and there isn't even an LSM hook in the place where such auto-port > selection occurs. Controlling binding to ports is only useful when > the port number is a "name" (i.e. a well-defined value that is > expected to correspond to a specific service), to prevent spoofing of > security-relevant services like sshd. > > On Fri, Jan 9, 2015 at 4:05 PM, Dominick Grift <dac.override@xxxxxxxxx> wrote: >> https://bugzilla.redhat.com/show_bug.cgi?id=1174405 >> >> This is a inconsistency in SELinux >> >> >> >> _______________________________________________ >> 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. > _______________________________________________ > 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. _______________________________________________ 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.
