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.
