Re: Strange context on unix_stream_socket

[Ole Kliemann <ole@plastictree.net>]

[-- 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 --]