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