All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ole Kliemann <ole@plastictree.net>
To: Stephen Smalley <sds@tycho.nsa.gov>
Cc: selinux@tycho.nsa.gov
Subject: Re: Strange context on unix_stream_socket
Date: Tue, 28 Jan 2014 18:12:59 +0100	[thread overview]
Message-ID: <20140128171259.GC2501@telmora.telvanni> (raw)
In-Reply-To: <52E68747.5020006@tycho.nsa.gov>

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

  reply	other threads:[~2014-01-28 17:13 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-25 20:59 Strange context on unix_stream_socket Ole Kliemann
2014-01-26 12:29 ` Ole Kliemann
2014-01-26 22:46   ` Ole Kliemann
2014-01-27 16:20     ` Stephen Smalley
2014-01-28 17:12       ` Ole Kliemann [this message]
2014-01-28 17:22         ` Stephen Smalley
2014-01-30 15:10           ` Richard Haines
2014-01-30 15:15             ` Stephen Smalley
2014-01-30 18:33             ` Ole Kliemann
     [not found] ` <CAPJdAQCZ0W4Bbm5JGa+R4QQkkeddoZFdUn5icJyo07xAB7BvNw@mail.gmail.com>
2014-01-26 12:33   ` ole

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140128171259.GC2501@telmora.telvanni \
    --to=ole@plastictree.net \
    --cc=sds@tycho.nsa.gov \
    --cc=selinux@tycho.nsa.gov \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.