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@xxxxxxxxxxxxx> >> To: Ole Kliemann <ole@xxxxxxxxxxxxxxx> >> Cc: selinux@xxxxxxxxxxxxx >> 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@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.
