RFC: https://bugzilla.redhat.com/show_bug.cgi?id=1174405

RFC: https://bugzilla.redhat.com/show_bug.cgi?id=1174405

[Dominick Grift]

https://bugzilla.redhat.com/show_bug.cgi?id=1174405

This is a inconsistency in SELinux

Re: RFC: https://bugzilla.redhat.com/show_bug.cgi?id=1174405

[Stephen Smalley]

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@gmail.com> wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=1174405
>
> This is a inconsistency in SELinux
>
>
>
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.

Re: RFC: https://bugzilla.redhat.com/show_bug.cgi?id=1174405

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 1526 bytes --]

On Fri, Jan 09, 2015 at 04:52:18PM -0500, Stephen Smalley 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.

Okay for the sake of argument let's say that makes sense to me. Should SELinux not somehow communicate this to the user.

First we had the scenario where selinux denies and not logs denials (user space object managers) and now we have the scenario where
selinux allows even if there is no rule to allow it

As a policy writer it gave me confidence to know that "if selinux blocks it logs" and that "selinux denies access by default". Now that those things turn out to not be true. Its a black box. voodoo.

> 
> On Fri, Jan 9, 2015 at 4:05 PM, Dominick Grift <dac.override@gmail.com> wrote:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1174405
> >
> > This is a inconsistency in SELinux
> >
> >
> >
> > _______________________________________________
> > Selinux mailing list
> > Selinux@tycho.nsa.gov
> > To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> > To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.

-- 
Dominick Grift

[-- Attachment #2: Type: application/pgp-signature, Size: 648 bytes --]

Re: RFC: https://bugzilla.redhat.com/show_bug.cgi?id=1174405

[eric gisse]

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@gmail.com> 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@gmail.com> wrote:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1174405
>>
>> This is a inconsistency in SELinux
>>
>>
>>
>> _______________________________________________
>> Selinux mailing list
>> Selinux@tycho.nsa.gov
>> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
>> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.

Re: RFC: https://bugzilla.redhat.com/show_bug.cgi?id=1174405

[Paul Moore]

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.

--
paul moore
www.paul-moore.com



On January 9, 2015 5:24:22 PM eric gisse <jowr.pi@gmail.com> 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@gmail.com> 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@gmail.com> 
> wrote:
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1174405
> >>
> >> This is a inconsistency in SELinux
> >>
> >>
> >>
> >> _______________________________________________
> >> Selinux mailing list
> >> Selinux@tycho.nsa.gov
> >> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> >> To get help, send an email containing "help" to 
> Selinux-request@tycho.nsa.gov.
> > _______________________________________________
> > Selinux mailing list
> > Selinux@tycho.nsa.gov
> > To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> > To get help, send an email containing "help" to 
> Selinux-request@tycho.nsa.gov.
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.

Re: RFC: https://bugzilla.redhat.com/show_bug.cgi?id=1174405

[Dominick Grift]

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@gmail.com> 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@gmail.com> 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@gmail.com> 
> > wrote:
> > >> https://bugzilla.redhat.com/show_bug.cgi?id=1174405
> > >>
> > >> This is a inconsistency in SELinux
> > >>
> > >>
> > >>
> > >> _______________________________________________
> > >> Selinux mailing list
> > >> Selinux@tycho.nsa.gov
> > >> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> > >> To get help, send an email containing "help" to 
> > Selinux-request@tycho.nsa.gov.
> > > _______________________________________________
> > > Selinux mailing list
> > > Selinux@tycho.nsa.gov
> > > To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> > > To get help, send an email containing "help" to 
> > Selinux-request@tycho.nsa.gov.
> > _______________________________________________
> > Selinux mailing list
> > Selinux@tycho.nsa.gov
> > To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> > To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.
> 
> 
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.

Re: RFC: https://bugzilla.redhat.com/show_bug.cgi?id=1174405

[Stephen Smalley]

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@gmail.com> 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@gmail.com> 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@gmail.com> 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@gmail.com>
>> > wrote:
>> > >> https://bugzilla.redhat.com/show_bug.cgi?id=1174405
>> > >>
>> > >> This is a inconsistency in SELinux
>> > >>
>> > >>
>> > >>
>> > >> _______________________________________________
>> > >> Selinux mailing list
>> > >> Selinux@tycho.nsa.gov
>> > >> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
>> > >> To get help, send an email containing "help" to
>> > Selinux-request@tycho.nsa.gov.
>> > > _______________________________________________
>> > > Selinux mailing list
>> > > Selinux@tycho.nsa.gov
>> > > To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
>> > > To get help, send an email containing "help" to
>> > Selinux-request@tycho.nsa.gov.
>> > _______________________________________________
>> > Selinux mailing list
>> > Selinux@tycho.nsa.gov
>> > To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
>> > To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.
>>
>>
>> _______________________________________________
>> Selinux mailing list
>> Selinux@tycho.nsa.gov
>> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
>> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.
>
>

Re: RFC: https://bugzilla.redhat.com/show_bug.cgi?id=1174405

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 6465 bytes --]

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

> 
> On Sat, Jan 10, 2015 at 4:56 AM, Dominick Grift <dac.override@gmail.com> 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@gmail.com> 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@gmail.com> 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@gmail.com>
> >> > wrote:
> >> > >> https://bugzilla.redhat.com/show_bug.cgi?id=1174405
> >> > >>
> >> > >> This is a inconsistency in SELinux
> >> > >>
> >> > >>
> >> > >>
> >> > >> _______________________________________________
> >> > >> Selinux mailing list
> >> > >> Selinux@tycho.nsa.gov
> >> > >> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> >> > >> To get help, send an email containing "help" to
> >> > Selinux-request@tycho.nsa.gov.
> >> > > _______________________________________________
> >> > > Selinux mailing list
> >> > > Selinux@tycho.nsa.gov
> >> > > To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> >> > > To get help, send an email containing "help" to
> >> > Selinux-request@tycho.nsa.gov.
> >> > _______________________________________________
> >> > Selinux mailing list
> >> > Selinux@tycho.nsa.gov
> >> > To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> >> > To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.
> >>
> >>
> >> _______________________________________________
> >> Selinux mailing list
> >> Selinux@tycho.nsa.gov
> >> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> >> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.
> >
> >

-- 
Dominick Grift

[-- Attachment #2: Type: application/pgp-signature, Size: 648 bytes --]

Re: RFC: https://bugzilla.redhat.com/show_bug.cgi?id=1174405

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 6990 bytes --]

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@gmail.com> 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@gmail.com> 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@gmail.com> 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@gmail.com>
> > >> > wrote:
> > >> > >> https://bugzilla.redhat.com/show_bug.cgi?id=1174405
> > >> > >>
> > >> > >> This is a inconsistency in SELinux
> > >> > >>
> > >> > >>
> > >> > >>
> > >> > >> _______________________________________________
> > >> > >> Selinux mailing list
> > >> > >> Selinux@tycho.nsa.gov
> > >> > >> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> > >> > >> To get help, send an email containing "help" to
> > >> > Selinux-request@tycho.nsa.gov.
> > >> > > _______________________________________________
> > >> > > Selinux mailing list
> > >> > > Selinux@tycho.nsa.gov
> > >> > > To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> > >> > > To get help, send an email containing "help" to
> > >> > Selinux-request@tycho.nsa.gov.
> > >> > _______________________________________________
> > >> > Selinux mailing list
> > >> > Selinux@tycho.nsa.gov
> > >> > To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> > >> > To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.
> > >>
> > >>
> > >> _______________________________________________
> > >> Selinux mailing list
> > >> Selinux@tycho.nsa.gov
> > >> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> > >> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.
> > >
> > >
> 
> -- 
> Dominick Grift



-- 
Dominick Grift

[-- Attachment #2: Type: application/pgp-signature, Size: 648 bytes --]

Re: RFC: https://bugzilla.redhat.com/show_bug.cgi?id=1174405

[Stephen Smalley]

Well, I noted it in the technical reports I wrote originally for
SELinux.  I guess it didn't get carried into documentation written by
others, although it has been discussed on this list and the Fedora
SELinux list various times.  Also, even if we were to implement such a
check, we'd have to dontaudit it in most cases because the kernel
would automatically be scanning the range for an available and allowed
port, and various userspace libraries do exactly the same thing when
trying to bind to an available port.  Which would render it a
mysterious denial on random send/connect and bind calls.

On Sat, Jan 10, 2015 at 12:43 PM, Dominick Grift <dac.override@gmail.com> wrote:
> 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@gmail.com> 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@gmail.com> 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@gmail.com> 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@gmail.com>
>> > >> > wrote:
>> > >> > >> https://bugzilla.redhat.com/show_bug.cgi?id=1174405
>> > >> > >>
>> > >> > >> This is a inconsistency in SELinux
>> > >> > >>
>> > >> > >>
>> > >> > >>
>> > >> > >> _______________________________________________
>> > >> > >> Selinux mailing list
>> > >> > >> Selinux@tycho.nsa.gov
>> > >> > >> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
>> > >> > >> To get help, send an email containing "help" to
>> > >> > Selinux-request@tycho.nsa.gov.
>> > >> > > _______________________________________________
>> > >> > > Selinux mailing list
>> > >> > > Selinux@tycho.nsa.gov
>> > >> > > To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
>> > >> > > To get help, send an email containing "help" to
>> > >> > Selinux-request@tycho.nsa.gov.
>> > >> > _______________________________________________
>> > >> > Selinux mailing list
>> > >> > Selinux@tycho.nsa.gov
>> > >> > To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
>> > >> > To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.
>> > >>
>> > >>
>> > >> _______________________________________________
>> > >> Selinux mailing list
>> > >> Selinux@tycho.nsa.gov
>> > >> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
>> > >> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.
>> > >
>> > >
>>
>> --
>> Dominick Grift
>
>
>
> --
> Dominick Grift
>
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.

Re: RFC: https://bugzilla.redhat.com/show_bug.cgi?id=1174405

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 9385 bytes --]

On Sat, Jan 10, 2015 at 01:54:01PM -0500, Stephen Smalley wrote:
> Well, I noted it in the technical reports I wrote originally for
> SELinux.  I guess it didn't get carried into documentation written by
> others, although it has been discussed on this list and the Fedora
> SELinux list various times.  Also, even if we were to implement such a
> check, we'd have to dontaudit it in most cases because the kernel
> would automatically be scanning the range for an available and allowed
> port, and various userspace libraries do exactly the same thing when
> trying to bind to an available port.  Which would render it a
> mysterious denial on random send/connect and bind calls.

You hinted that implementing a check for this could affect performance, and so i am no longer in favor of that solution.

however i would like some of the tools to be aware of this issue.

for example if i do

sesearch -A -s sshd_t -t port_type -c tcp_socket -p name_bind

That it returns somehow that this access to ports in the local port range will be allowed. So that auditors see that it is allowed even though there is no rule to allow it.
At least then they know there is something going on and can look for documentation about it.

The problem is how does one implement that in an informative way without relying on customizable identifiers.

> 
> On Sat, Jan 10, 2015 at 12:43 PM, Dominick Grift <dac.override@gmail.com> wrote:
> > 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@gmail.com> 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@gmail.com> 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@gmail.com> 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@gmail.com>
> >> > >> > wrote:
> >> > >> > >> https://bugzilla.redhat.com/show_bug.cgi?id=1174405
> >> > >> > >>
> >> > >> > >> This is a inconsistency in SELinux
> >> > >> > >>
> >> > >> > >>
> >> > >> > >>
> >> > >> > >> _______________________________________________
> >> > >> > >> Selinux mailing list
> >> > >> > >> Selinux@tycho.nsa.gov
> >> > >> > >> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> >> > >> > >> To get help, send an email containing "help" to
> >> > >> > Selinux-request@tycho.nsa.gov.
> >> > >> > > _______________________________________________
> >> > >> > > Selinux mailing list
> >> > >> > > Selinux@tycho.nsa.gov
> >> > >> > > To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> >> > >> > > To get help, send an email containing "help" to
> >> > >> > Selinux-request@tycho.nsa.gov.
> >> > >> > _______________________________________________
> >> > >> > Selinux mailing list
> >> > >> > Selinux@tycho.nsa.gov
> >> > >> > To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> >> > >> > To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.
> >> > >>
> >> > >>
> >> > >> _______________________________________________
> >> > >> Selinux mailing list
> >> > >> Selinux@tycho.nsa.gov
> >> > >> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> >> > >> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.
> >> > >
> >> > >
> >>
> >> --
> >> Dominick Grift
> >
> >
> >
> > --
> > Dominick Grift
> >
> > _______________________________________________
> > Selinux mailing list
> > Selinux@tycho.nsa.gov
> > To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> > To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.

-- 
Dominick Grift

[-- Attachment #2: Type: application/pgp-signature, Size: 648 bytes --]

Re: RFC: https://bugzilla.redhat.com/show_bug.cgi?id=1174405

[Vincent Brillault]

Hi,

I'm not sure I understand the "performance" impact considerations.
Indeed, if we were to try to control the binding to 'ephemeral' ports
individually, the looping that Stephen proposed would definitely have a
huge impact if all port are denied (as the kernel will have to loop over
all of them to find out that all bindings are denied).

However, does considering all these ports individually make sense?
If we can consider them as a group, not individually, I believe that we
could control 'ephemeral' bindings with almost no performance hit.
For example, we could create a permission 'ephemeral_bind' in addition
to bind and named_bind:
- bind controls the ability to invoke the bind system calls
- named_bind controls the ability to bind a given non ephemeral port
- ephemeral_bind would controls the ability to bind any 'ephemeral' port

Would that make sense?

I'm not a kernel/selinux developper, so I can't judge the amount of work
needed to implement such a solution, but I don't think that this issue
can be discarded for 'performance' reasons.

Cheers,
Vincent Brillault

Re: RFC: https://bugzilla.redhat.com/show_bug.cgi?id=1174405

[Stephen Smalley]

On 01/10/2015 03:39 PM, Vincent Brillault wrote:
> Hi,
> 
> I'm not sure I understand the "performance" impact considerations.
> Indeed, if we were to try to control the binding to 'ephemeral' ports
> individually, the looping that Stephen proposed would definitely have a
> huge impact if all port are denied (as the kernel will have to loop over
> all of them to find out that all bindings are denied).

Yes, that was what I meant.

> However, does considering all these ports individually make sense?
> If we can consider them as a group, not individually, I believe that we
> could control 'ephemeral' bindings with almost no performance hit.
> For example, we could create a permission 'ephemeral_bind' in addition
> to bind and named_bind:
> - bind controls the ability to invoke the bind system calls
> - named_bind controls the ability to bind a given non ephemeral port
> - ephemeral_bind would controls the ability to bind any 'ephemeral' port
> 
> Would that make sense?
> 
> I'm not a kernel/selinux developper, so I can't judge the amount of work
> needed to implement such a solution, but I don't think that this issue
> can be discarded for 'performance' reasons.

You can bind to a port in the local port range in three different ways:

1) Call bind(2) with the port number explicitly specified.  That case we
could trivially check via SELinux today if we wanted to do so just by
removing the range check from selinux_socket_bind.  But it would leave
the check trivially bypassable by using one of the other two means until
you hit the desired port number, which is why we did not impose this
check in the first place (in addition to the fact that such ports can
have no security semantics since they are "randomly" assigned on demand).

2) Call bind(2) with a zero port number specified.  In that case, the
port is automatically selected by the ipv4 code after we have already
passed the selinux_socket_bind() hook call, so we cannot apply a check
based on the specific port number unless we hook the ipv4 (and ipv6)
code, in multiple places no less, which I don't see as maintainable.  We
could apply your generic ephemeral_bind check from selinux_socket_bind()
in this case but this will still be bypassable using the third way below.

3) Call sendto()/sendmsg() or connect() on an unbound socket.  In that
case, the port is automatically selected by the ipv4 code after we have
already passed the selinux_socket_sendmsg() or selinux_socket_connect()
hook call.  We'd either have to dig down into the inet_sk state within
those hooks to see if the socket was unbound or place a hook down in the
ipv4 code (and the ipv6 code) if we wanted to even apply your
ephemeral_bind check.  The former is possible but seems a bit of a
layering violation while the latter seems unmaintainable.

Now, let's say we implement this ephemeral_bind permission check.  What
domains that currently are allowed to create UDP or TCP sockets do you
think will need this permission?  I'll wager they all do, because they
will be creating sender UDP sockets for DNS lookups and other purposes
that will just be using the local port range.  So what did you gain?

Re: RFC: https://bugzilla.redhat.com/show_bug.cgi?id=1174405

[Paul Moore]

On Sat, Jan 10, 2015 at 2:15 PM, Dominick Grift <dac.override@gmail.com> wrote:
> On Sat, Jan 10, 2015 at 01:54:01PM -0500, Stephen Smalley wrote:
>> Well, I noted it in the technical reports I wrote originally for
>> SELinux.  I guess it didn't get carried into documentation written by
>> others, although it has been discussed on this list and the Fedora
>> SELinux list various times.  Also, even if we were to implement such a
>> check, we'd have to dontaudit it in most cases because the kernel
>> would automatically be scanning the range for an available and allowed
>> port, and various userspace libraries do exactly the same thing when
>> trying to bind to an available port.  Which would render it a
>> mysterious denial on random send/connect and bind calls.
>
> You hinted that implementing a check for this could affect performance, and so i am no longer in favor of that solution.
>
> however i would like some of the tools to be aware of this issue.
>
> for example if i do
>
> sesearch -A -s sshd_t -t port_type -c tcp_socket -p name_bind
>
> That it returns somehow that this access to ports in the local port range will be allowed. So that auditors see that it is allowed even though there is no rule to allow it.
> At least then they know there is something going on and can look for documentation about it.
>
> The problem is how does one implement that in an informative way without relying on customizable identifiers.

Perhaps a mention in the relevant man pages?

-- 
paul moore
www.paul-moore.com

Re: RFC: https://bugzilla.redhat.com/show_bug.cgi?id=1174405

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 2142 bytes --]

On Sun, Jan 11, 2015 at 10:49:03AM -0500, Paul Moore wrote:
> On Sat, Jan 10, 2015 at 2:15 PM, Dominick Grift <dac.override@gmail.com> wrote:
> > On Sat, Jan 10, 2015 at 01:54:01PM -0500, Stephen Smalley wrote:
> >> Well, I noted it in the technical reports I wrote originally for
> >> SELinux.  I guess it didn't get carried into documentation written by
> >> others, although it has been discussed on this list and the Fedora
> >> SELinux list various times.  Also, even if we were to implement such a
> >> check, we'd have to dontaudit it in most cases because the kernel
> >> would automatically be scanning the range for an available and allowed
> >> port, and various userspace libraries do exactly the same thing when
> >> trying to bind to an available port.  Which would render it a
> >> mysterious denial on random send/connect and bind calls.
> >
> > You hinted that implementing a check for this could affect performance, and so i am no longer in favor of that solution.
> >
> > however i would like some of the tools to be aware of this issue.
> >
> > for example if i do
> >
> > sesearch -A -s sshd_t -t port_type -c tcp_socket -p name_bind
> >
> > That it returns somehow that this access to ports in the local port range will be allowed. So that auditors see that it is allowed even though there is no rule to allow it.
> > At least then they know there is something going on and can look for documentation about it.
> >
> > The problem is how does one implement that in an informative way without relying on customizable identifiers.
> 
> Perhaps a mention in the relevant man pages?

That is better than nothing in my opinion but I do not believe this is prominently visible enough on its own. In my view we should pro-actively inform users about this and other inconsistencies.

> 
> -- 
> paul moore
> www.paul-moore.com
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.

-- 
Dominick Grift

[-- Attachment #2: Type: application/pgp-signature, Size: 648 bytes --]