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:
signature.asc
Description: Digital 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.
