On Sat, Jan 10, 2015 at 06:19:51PM +0100, Dominick Grift wrote: > On Sat, Jan 10, 2015 at 11:49:29AM -0500, Stephen Smalley wrote: > > 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. > > I can live with this "logical inconsistency", and other "gotchas" but i would prefer that tools/libraries like sesearch would some how communicate this. > It may be documented, and discussed but besides a handful of kernel coders and a few others, i bet not many are aware of this inconsistency, and other gotchas > If the tools would some how show that there is a special case, then policy authors would not be left totally in the dark but how would one implement that... > There is a difference between not being hidden from view, and being prominently visible. I prefer the latter in instances like these to avoid this embarrassment. > > > > 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. > > > > > > > > -- > Dominick Grift -- Dominick Grift
Attachment:
pgppYnaAqorF9.pgp
Description: PGP signature
_______________________________________________ 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.
