This behavior has a) always been present in SELinux, b) documented in the original SELinux technical report and the LSM-based SELinux technical report, and c) discussed plenty of times before. So you're free to disagree but it isn't new or hidden from view. It was viewed as logically inconsistent and not useful to impose a restriction upon bind(2) to a port number in the local port range when such port numbers have no security semantics and can be obtained by any process that can create a socket just by connecting (TCP) or sending (UDP) on that socket. At that time, the ipv4 code will cheerfully assign an available port number out of that local port range to the socket if it is unbound. If you truly want to control port numbers in that range, it is not a mere matter of removing the exemption from the selinux_socket_bind hook but also introducing a new LSM hook inside the ipv4 code to keep trying until it finds a port number that is allowed. The potential overhead of applying such checking could be non-trivial and would show up on connect() and sendto()/sendmsg() calls. You are free to submit a patch to do exactly that, with performance measurements if you wish. On Sat, Jan 10, 2015 at 4:56 AM, Dominick Grift <dac.override@xxxxxxxxx> wrote: > On Fri, 2015-01-09 at 22:02 -0500, Paul Moore wrote: >> I think there is a point of clarification that may help put everyone at >> ease... SELinux provides two permissions relevant to socket bind() >> operations, bind and name_bind. The name_bind operation controls the >> socket's ability to bind to a specific port, while the bind operation >> controls the ability of a domain to bind a socket. Those of you who wish >> to restrict a domain from performing a socket bind() operation, regardless >> of the port, would likely find your answer with the socket:bind permission. >> > > Good to know but the socket bind access vector is checked on the domain > type and not on the port type > > Thus is you have a process with a requirement to bind a socket to a port > < ephemeral, then it is automatically also able listen on ports >= > ephemeral from an selinux pov > > Although this is good to know and in rare cases may be useful, it is in > my view indeed still a consolation prize at best > >> -- >> paul moore >> www.paul-moore.com >> >> >> >> On January 9, 2015 5:24:22 PM eric gisse <jowr.pi@xxxxxxxxx> wrote: >> >> > 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. >> >> >> _______________________________________________ >> 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.
