Strange context on unix_stream_socket

Strange context on unix_stream_socket

[Ole Kliemann]

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

I'm having an odd problem:

I am running my own MCS constrainted policy on Ubuntu 12.04. At 
some point I have a process with context 

    sub_t:s0:c20-s0:c20.c29

From this process I try to access a jack daemon with mplayer. For 
this purpose unix stream sockets are being used. I then get an 
avc denial saying that

    process sub_t:s0:c20-s0:c20.c29

tried to access 

    unix_stream_socket sub_t:s0

which is prohibited by mcs constrain. The socket is on sockfs and 
has no file associated with it.

The problem is that under no circumstances the policy allows the 
creation of anything with 'sub_t:s0'. 

Using an auditallow rule like

    auditallow any_type sub_t:unix_stream_socket { create relabelto relabelfrom };

clearly shows that indeed no socket with a context like that is 
created nor relabel to.  And yet it exists.


I'd highly appreciate any hint on this matter. Including how to 
debug further. How can I display the security context of a socket 
on sockfs? 

Best regards
Ole

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

Re: Strange context on unix_stream_socket

[Ole Kliemann]

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

On Sat, Jan 25, 2014 at 09:59:44PM +0100, Ole Kliemann wrote:
> I'm having an odd problem:
> 
> I am running my own MCS constrainted policy on Ubuntu 12.04. At 
> some point I have a process with context 
> 
>     sub_t:s0:c20-s0:c20.c29
> 
> From this process I try to access a jack daemon with mplayer. For 
> this purpose unix stream sockets are being used. I then get an 
> avc denial saying that
> 
>     process sub_t:s0:c20-s0:c20.c29
> 
> tried to access 
> 
>     unix_stream_socket sub_t:s0
> 
> which is prohibited by mcs constrain. The socket is on sockfs and 
> has no file associated with it.
> 
> The problem is that under no circumstances the policy allows the 
> creation of anything with 'sub_t:s0'. 
> 
> Using an auditallow rule like
> 
>     auditallow any_type sub_t:unix_stream_socket { create relabelto relabelfrom };
> 
> clearly shows that indeed no socket with a context like that is 
> created nor relabel to.  And yet it exists.

With strace and GDB I managed to find out this much:

mplayer open several sockets and listens on at least one of them. 
All these sockets have correct context. I determined the context 
using

    'stat -L /proc/PID/fd/FD'

I hope that is a valid method.

It then accept a connection on a listening socket, probably 
coming from the jack daemon. As we know, the system call 
accepting a connection on a socket returns a new socket itself. 
At the point the system call returns, this new socket is found in 
/proc/PID/fd/ and has the offending context.

Now I don't know much about these sockets. Process A listens on 
socket S0 and accepts the connection of process B. A new socket 
S1 appears. Who, in terms of policy, is the creating process for 
socket S1? How does the kernel determine the context of such a 
socket?

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

Re: Strange context on unix_stream_socket

[Ole Kliemann]

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

On Sun, Jan 26, 2014 at 01:29:22PM +0100, Ole Kliemann wrote:
> On Sat, Jan 25, 2014 at 09:59:44PM +0100, Ole Kliemann wrote:
> > I'm having an odd problem:
> > 
> > I am running my own MCS constrainted policy on Ubuntu 12.04. At 
> > some point I have a process with context 
> > 
> >     sub_t:s0:c20-s0:c20.c29
> > 
> > From this process I try to access a jack daemon with mplayer. For 
> > this purpose unix stream sockets are being used. I then get an 
> > avc denial saying that
> > 
> >     process sub_t:s0:c20-s0:c20.c29
> > 
> > tried to access 
> > 
> >     unix_stream_socket sub_t:s0
> > 
> > which is prohibited by mcs constrain. The socket is on sockfs and 
> > has no file associated with it.
> > 
> > The problem is that under no circumstances the policy allows the 
> > creation of anything with 'sub_t:s0'. 
> > 
> > Using an auditallow rule like
> > 
> >     auditallow any_type sub_t:unix_stream_socket { create relabelto relabelfrom };
> > 
> > clearly shows that indeed no socket with a context like that is 
> > created nor relabel to.  And yet it exists.
> 
> With strace and GDB I managed to find out this much:
> 
> mplayer open several sockets and listens on at least one of them. 
> All these sockets have correct context. I determined the context 
> using
> 
>     'stat -L /proc/PID/fd/FD'
> 
> I hope that is a valid method.
> 
> It then accept a connection on a listening socket, probably 
> coming from the jack daemon. As we know, the system call 
> accepting a connection on a socket returns a new socket itself. 
> At the point the system call returns, this new socket is found in 
> /proc/PID/fd/ and has the offending context.
> 
> Now I don't know much about these sockets. Process A listens on 
> socket S0 and accepts the connection of process B. A new socket 
> S1 appears. Who, in terms of policy, is the creating process for 
> socket S1? How does the kernel determine the context of such a 
> socket?

I have written my own little socket test program. Process P1 with 
context TYPE1:RANGE1 creates a socket and listens on it. P2 with 
context TYPE2:RANGE2 connects to this socket.

Process P1 accepts the connection. The socket created throught 
accept() in P1 has actually the context TYPE1:RANGE2.

Is this expected behavior? 

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

Re: Strange context on unix_stream_socket

[Stephen Smalley]

On 01/26/2014 05:46 PM, Ole Kliemann wrote:
> On Sun, Jan 26, 2014 at 01:29:22PM +0100, Ole Kliemann wrote:
>> On Sat, Jan 25, 2014 at 09:59:44PM +0100, Ole Kliemann wrote:
>>> I'm having an odd problem:
>>>
>>> I am running my own MCS constrainted policy on Ubuntu 12.04. At 
>>> some point I have a process with context 
>>>
>>>     sub_t:s0:c20-s0:c20.c29
>>>
>>> From this process I try to access a jack daemon with mplayer. For 
>>> this purpose unix stream sockets are being used. I then get an 
>>> avc denial saying that
>>>
>>>     process sub_t:s0:c20-s0:c20.c29
>>>
>>> tried to access 
>>>
>>>     unix_stream_socket sub_t:s0
>>>
>>> which is prohibited by mcs constrain. The socket is on sockfs and 
>>> has no file associated with it.
>>>
>>> The problem is that under no circumstances the policy allows the 
>>> creation of anything with 'sub_t:s0'. 
>>>
>>> Using an auditallow rule like
>>>
>>>     auditallow any_type sub_t:unix_stream_socket { create relabelto relabelfrom };
>>>
>>> clearly shows that indeed no socket with a context like that is 
>>> created nor relabel to.  And yet it exists.
>>
>> With strace and GDB I managed to find out this much:
>>
>> mplayer open several sockets and listens on at least one of them. 
>> All these sockets have correct context. I determined the context 
>> using
>>
>>     'stat -L /proc/PID/fd/FD'
>>
>> I hope that is a valid method.
>>
>> It then accept a connection on a listening socket, probably 
>> coming from the jack daemon. As we know, the system call 
>> accepting a connection on a socket returns a new socket itself. 
>> At the point the system call returns, this new socket is found in 
>> /proc/PID/fd/ and has the offending context.
>>
>> Now I don't know much about these sockets. Process A listens on 
>> socket S0 and accepts the connection of process B. A new socket 
>> S1 appears. Who, in terms of policy, is the creating process for 
>> socket S1? How does the kernel determine the context of such a 
>> socket?
> 
> I have written my own little socket test program. Process P1 with 
> context TYPE1:RANGE1 creates a socket and listens on it. P2 with 
> context TYPE2:RANGE2 connects to this socket.
> 
> Process P1 accepts the connection. The socket created throught 
> accept() in P1 has actually the context TYPE1:RANGE2.
> 
> Is this expected behavior? 

Yes.  That was the behavior desired by the MLS/LSPP community, as they
want the socket to mirror the client level for multi-level servers, and
in the single-level server case, you are only allowed to connect at the
same level.

Re: Strange context on unix_stream_socket

[Ole Kliemann]

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

On Mon, Jan 27, 2014 at 11:20:23AM -0500, Stephen Smalley wrote:
> On 01/26/2014 05:46 PM, Ole Kliemann wrote:
> > I have written my own little socket test program. Process P1 with 
> > context TYPE1:RANGE1 creates a socket and listens on it. P2 with 
> > context TYPE2:RANGE2 connects to this socket.
> > 
> > Process P1 accepts the connection. The socket created throught 
> > accept() in P1 has actually the context TYPE1:RANGE2.
> > 
> > Is this expected behavior? 
> 
> Yes.  That was the behavior desired by the MLS/LSPP community, as they
> want the socket to mirror the client level for multi-level servers, and
> in the single-level server case, you are only allowed to connect at the
> same level.

Thank you for the clarification.

Is there no way to control this? To state more precisly: I can 
very well _connect_ to everything the policy allows me to, I then 
just cannot use this connection. That's a bit weird.

Although I admit, the problems arise from my specific situation 
where I have one realm the consist of only one type but is 
separated by MLS and another realm that is MLS-ignorant and uses 
TE. All vectors running between the two realms are also only 
controll by TE. When I now use sockets between the MLS and 
non-MLS realm these connections should only be controlled by TE,
but as a result of above mentioned labeling behavior, MLS 
suddenly gets in the way.

I can imagine, in an MLS-only environment this behavior makes 
more sense; specificly in the case of multi-level servers. All 
the more desirable it would be if the policy was to make such 
labeling decisions at the discretion of the policy writer.

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

Re: Strange context on unix_stream_socket

[Stephen Smalley]

On 01/28/2014 12:12 PM, Ole Kliemann wrote:
> On Mon, Jan 27, 2014 at 11:20:23AM -0500, Stephen Smalley wrote:
>> On 01/26/2014 05:46 PM, Ole Kliemann wrote:
>>> I have written my own little socket test program. Process P1 with 
>>> context TYPE1:RANGE1 creates a socket and listens on it. P2 with 
>>> context TYPE2:RANGE2 connects to this socket.
>>>
>>> Process P1 accepts the connection. The socket created throught 
>>> accept() in P1 has actually the context TYPE1:RANGE2.
>>>
>>> Is this expected behavior? 
>>
>> Yes.  That was the behavior desired by the MLS/LSPP community, as they
>> want the socket to mirror the client level for multi-level servers, and
>> in the single-level server case, you are only allowed to connect at the
>> same level.
> 
> Thank you for the clarification.
> 
> Is there no way to control this? To state more precisly: I can 
> very well _connect_ to everything the policy allows me to, I then 
> just cannot use this connection. That's a bit weird.
> 
> Although I admit, the problems arise from my specific situation 
> where I have one realm the consist of only one type but is 
> separated by MLS and another realm that is MLS-ignorant and uses 
> TE. All vectors running between the two realms are also only 
> controll by TE. When I now use sockets between the MLS and 
> non-MLS realm these connections should only be controlled by TE,
> but as a result of above mentioned labeling behavior, MLS 
> suddenly gets in the way.
> 
> I can imagine, in an MLS-only environment this behavior makes 
> more sense; specificly in the case of multi-level servers. All 
> the more desirable it would be if the policy was to make such 
> labeling decisions at the discretion of the policy writer.

Yes, in prior implementations we allowed it to be configurable as a
transition on the listening socket security context and the incoming
packet security context.  That would be preferable IMHO, but is not
possible today without kernel code changes.

Re: Strange context on unix_stream_socket

[Richard Haines]

Out of idle curiosity would a range_transition rule resolve this problem ?

range_transition source target : unix_stream_socket s0;



----- Original Message -----
> From: Stephen Smalley <sds@tycho.nsa.gov>
> To: Ole Kliemann <ole@plastictree.net>
> Cc: selinux@tycho.nsa.gov
> Sent: Tuesday, 28 January 2014, 17:22
> Subject: Re: Strange context on unix_stream_socket
> 
> On 01/28/2014 12:12 PM, Ole Kliemann wrote:
>>  On Mon, Jan 27, 2014 at 11:20:23AM -0500, Stephen Smalley wrote:
>>>  On 01/26/2014 05:46 PM, Ole Kliemann wrote:
>>>>  I have written my own little socket test program. Process P1 with 
>>>>  context TYPE1:RANGE1 creates a socket and listens on it. P2 with 
>>>>  context TYPE2:RANGE2 connects to this socket.
>>>> 
>>>>  Process P1 accepts the connection. The socket created throught 
>>>>  accept() in P1 has actually the context TYPE1:RANGE2.
>>>> 
>>>>  Is this expected behavior? 
>>> 
>>>  Yes.  That was the behavior desired by the MLS/LSPP community, as they
>>>  want the socket to mirror the client level for multi-level servers, and
>>>  in the single-level server case, you are only allowed to connect at the
>>>  same level.
>> 
>>  Thank you for the clarification.
>> 
>>  Is there no way to control this? To state more precisly: I can 
>>  very well _connect_ to everything the policy allows me to, I then 
>>  just cannot use this connection. That's a bit weird.
>> 
>>  Although I admit, the problems arise from my specific situation 
>>  where I have one realm the consist of only one type but is 
>>  separated by MLS and another realm that is MLS-ignorant and uses 
>>  TE. All vectors running between the two realms are also only 
>>  controll by TE. When I now use sockets between the MLS and 
>>  non-MLS realm these connections should only be controlled by TE,
>>  but as a result of above mentioned labeling behavior, MLS 
>>  suddenly gets in the way.
>> 
>>  I can imagine, in an MLS-only environment this behavior makes 
>>  more sense; specificly in the case of multi-level servers. All 
>>  the more desirable it would be if the policy was to make such 
>>  labeling decisions at the discretion of the policy writer.
> 
> Yes, in prior implementations we allowed it to be configurable as a
> transition on the listening socket security context and the incoming
> packet security context.  That would be preferable IMHO, but is not
> possible today without kernel code changes.
> 
> 
> _______________________________________________
> 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: Strange context on unix_stream_socket

[Stephen Smalley]

On 01/30/2014 10:10 AM, Richard Haines wrote:
> Out of idle curiosity would a range_transition rule resolve this problem ?
> 
> range_transition source target : unix_stream_socket s0;

It would if the kernel code actually called security_transition_sid() to
determine the new connection socket SID, but it doesn't.  That's what I
meant.

> 
> 
> 
> ----- Original Message -----
>> From: Stephen Smalley <sds@tycho.nsa.gov>
>> To: Ole Kliemann <ole@plastictree.net>
>> Cc: selinux@tycho.nsa.gov
>> Sent: Tuesday, 28 January 2014, 17:22
>> Subject: Re: Strange context on unix_stream_socket
>>
>> On 01/28/2014 12:12 PM, Ole Kliemann wrote:
>>>  On Mon, Jan 27, 2014 at 11:20:23AM -0500, Stephen Smalley wrote:
>>>>  On 01/26/2014 05:46 PM, Ole Kliemann wrote:
>>>>>  I have written my own little socket test program. Process P1 with 
>>>>>  context TYPE1:RANGE1 creates a socket and listens on it. P2 with 
>>>>>  context TYPE2:RANGE2 connects to this socket.
>>>>>
>>>>>  Process P1 accepts the connection. The socket created throught 
>>>>>  accept() in P1 has actually the context TYPE1:RANGE2.
>>>>>
>>>>>  Is this expected behavior? 
>>>>
>>>>  Yes.  That was the behavior desired by the MLS/LSPP community, as they
>>>>  want the socket to mirror the client level for multi-level servers, and
>>>>  in the single-level server case, you are only allowed to connect at the
>>>>  same level.
>>>
>>>  Thank you for the clarification.
>>>
>>>  Is there no way to control this? To state more precisly: I can 
>>>  very well _connect_ to everything the policy allows me to, I then 
>>>  just cannot use this connection. That's a bit weird.
>>>
>>>  Although I admit, the problems arise from my specific situation 
>>>  where I have one realm the consist of only one type but is 
>>>  separated by MLS and another realm that is MLS-ignorant and uses 
>>>  TE. All vectors running between the two realms are also only 
>>>  controll by TE. When I now use sockets between the MLS and 
>>>  non-MLS realm these connections should only be controlled by TE,
>>>  but as a result of above mentioned labeling behavior, MLS 
>>>  suddenly gets in the way.
>>>
>>>  I can imagine, in an MLS-only environment this behavior makes 
>>>  more sense; specificly in the case of multi-level servers. All 
>>>  the more desirable it would be if the policy was to make such 
>>>  labeling decisions at the discretion of the policy writer.
>>
>> Yes, in prior implementations we allowed it to be configurable as a
>> transition on the listening socket security context and the incoming
>> packet security context.  That would be preferable IMHO, but is not
>> possible today without kernel code changes.
>>
>>
>> _______________________________________________
>> 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: Strange context on unix_stream_socket

[Ole Kliemann]

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

On Thu, Jan 30, 2014 at 03:10:21PM +0000, Richard Haines wrote:
> Out of idle curiosity would a range_transition rule resolve this problem ?
> 
> range_transition source target : unix_stream_socket s0;

It wouldn't help as the current labeling behavior is a function 
of types _and ranges_ while range_transition is merely a function 
of types. As far as I can see the current behavior cannot be 
expressed with current policy language.

> 
> 
> 
> ----- Original Message -----
> > From: Stephen Smalley <sds@tycho.nsa.gov>
> > To: Ole Kliemann <ole@plastictree.net>
> > Cc: selinux@tycho.nsa.gov
> > Sent: Tuesday, 28 January 2014, 17:22
> > Subject: Re: Strange context on unix_stream_socket
> > 
> > On 01/28/2014 12:12 PM, Ole Kliemann wrote:
> >>  On Mon, Jan 27, 2014 at 11:20:23AM -0500, Stephen Smalley wrote:
> >>>  On 01/26/2014 05:46 PM, Ole Kliemann wrote:
> >>>>  I have written my own little socket test program. Process P1 with 
> >>>>  context TYPE1:RANGE1 creates a socket and listens on it. P2 with 
> >>>>  context TYPE2:RANGE2 connects to this socket.
> >>>> 
> >>>>  Process P1 accepts the connection. The socket created throught 
> >>>>  accept() in P1 has actually the context TYPE1:RANGE2.
> >>>> 
> >>>>  Is this expected behavior? 
> >>> 
> >>>  Yes.  That was the behavior desired by the MLS/LSPP community, as they
> >>>  want the socket to mirror the client level for multi-level servers, and
> >>>  in the single-level server case, you are only allowed to connect at the
> >>>  same level.
> >> 
> >>  Thank you for the clarification.
> >> 
> >>  Is there no way to control this? To state more precisly: I can 
> >>  very well _connect_ to everything the policy allows me to, I then 
> >>  just cannot use this connection. That's a bit weird.
> >> 
> >>  Although I admit, the problems arise from my specific situation 
> >>  where I have one realm the consist of only one type but is 
> >>  separated by MLS and another realm that is MLS-ignorant and uses 
> >>  TE. All vectors running between the two realms are also only 
> >>  controll by TE. When I now use sockets between the MLS and 
> >>  non-MLS realm these connections should only be controlled by TE,
> >>  but as a result of above mentioned labeling behavior, MLS 
> >>  suddenly gets in the way.
> >> 
> >>  I can imagine, in an MLS-only environment this behavior makes 
> >>  more sense; specificly in the case of multi-level servers. All 
> >>  the more desirable it would be if the policy was to make such 
> >>  labeling decisions at the discretion of the policy writer.
> > 
> > Yes, in prior implementations we allowed it to be configurable as a
> > transition on the listening socket security context and the incoming
> > packet security context.  That would be preferable IMHO, but is not
> > possible today without kernel code changes.
> > 
> > 
> > _______________________________________________
> > 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.
> >

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

Re: Strange context on unix_stream_socket

[ole]

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

On Sun, Jan 26, 2014 at 06:01:51AM +0800, Frank C wrote:
> So does this mean that we have sockets that are left open for discussion
> that are not being used?  They all have to come out if they are not being
> used.  Unused sockets shouldn't pass a static analysis.

Thank you for your input. Unfortunately I cannot quite follow. 
Could you please elaborate what your question is?

My problem is that a socket created by the accept system call 
(see my follow-up posting) has not only a wrong context that 
prevents access to it, but also a context that following the 
policy it should not be able to acquire.


> 
> 
> On Sun, Jan 26, 2014 at 4:59 AM, Ole Kliemann <ole@plastictree.net> wrote:
> 
> > I'm having an odd problem:
> >
> > I am running my own MCS constrainted policy on Ubuntu 12.04. At
> > some point I have a process with context
> >
> >     sub_t:s0:c20-s0:c20.c29
> >
> > From this process I try to access a jack daemon with mplayer. For
> > this purpose unix stream sockets are being used. I then get an
> > avc denial saying that
> >
> >     process sub_t:s0:c20-s0:c20.c29
> >
> > tried to access
> >
> >     unix_stream_socket sub_t:s0
> >
> > which is prohibited by mcs constrain. The socket is on sockfs and
> > has no file associated with it.
> >
> > The problem is that under no circumstances the policy allows the
> > creation of anything with 'sub_t:s0'.
> >
> > Using an auditallow rule like
> >
> >     auditallow any_type sub_t:unix_stream_socket { create relabelto
> > relabelfrom };
> >
> > clearly shows that indeed no socket with a context like that is
> > created nor relabel to.  And yet it exists.
> >
> >
> > I'd highly appreciate any hint on this matter. Including how to
> > debug further. How can I display the security context of a socket
> > on sockfs?
> >
> > Best regards
> > Ole
> >
> > _______________________________________________
> > 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.
> >
> >
> 
> 
> -- 
> 
> *Francis X. Cunnane III*
> frankc@networkcrypt.com
> 
> 
> This email and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity to whom they are addressed.
> If you have received this email in error please notify the system manager.
> This message contains confidential information and is intended only for the
> individual named. If you are not the named addressee you should not
> disseminate, distribute or copy this e-mail. Please notify the sender
> immediately by e-mail if you have received this e-mail by mistake and
> delete this e-mail from your system. If you are not the intended recipient
> you are notified that disclosing, copying, distributing or taking any
> action in reliance on the contents of this information is strictly
> prohibited.

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