Re: Question on networking accesses

[Casey Schaufler <casey@schaufler-ca.com>]

--- Paul Moore <paul.moore@hp.com> wrote:

> On Monday, May 21 2007 9:48:52 am Casey Schaufler wrote:
> > I have what I hope is a fairly straitforward question on the SELinux
> > networking model. Let's pretend that I have a process A that sends a
> > UDP packet P to a second process B. From the viewpoint of access control
> > is this:
> >
> >     - process A writing to process B
> >     - process B reading from process A
> >     - process A creating packet P, and process B reading packet P
> >
> > some combination of the above, or something else entirely?
> 
> >From 10,000 feet up in the air that sounds roughly about right.  Although if
> 
> you are talking about labeled networking it can be a bit more involved, 
> especially if you are using labeled IPsec.
> 
> Can you be a bit more specific?

How about if I throw out an example. The evaluation team loved this
one back in '92.

I have a tic-tac-toe server that does little but maintain a tic-tac-toe
board. It allows two connections, one for the "X" player and one for the
"O" player. Player X invokes the tictacclient program, which sends a
UDP packet to tictacserver. The client may be local or remote. What
access control decisions are made, where, and using what information?

The decision may be different if it's seen as a write from tictacclient
to tictacserver than if it's seen as a read from tictacclient by
tictacserver. The decision may have another outcome entirely if the
packet is treated as a named object that is created by tictacclient.

So, what should the creator of this tic-tac-toe system expect on an
selinux system? Will the access decision be based on a write from the
client, a read by the server, the attribues associated with a packet
object, or something else entirely?

Historical MLS systems treated the access as a write by the client to
the server (well, the server's socket) but the MLS rules typically
limited the communications to matching labels. SELinux is much more
likely to encounter a situation where the client might be able to write
to the server but the server might not be allowed to read the client
(or the other way around). It may matter if it is a read or a write.


Casey Schaufler
casey@schaufler-ca.com

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.