Question on networking accesses

Question on networking accesses

[Casey Schaufler]

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?

Yes, I have read the code, and fine code it is, too.
Thank you.


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.

Re: Question on networking accesses

[Paul Moore]

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?

-- 
paul moore
linux security @ hp


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

Re: Question on networking accesses

[Casey Schaufler]

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

Re: Question on networking accesses

[Paul Moore]

On Monday, May 21 2007 12:07:21 pm Casey Schaufler wrote:
> --- 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.

The example wasn't quite what I was hoping for as I'm still a little confused 
as to exactly what you are looking for.  However, it's Monday and writing 
email is looking more attractive than real work so let me take a stab at 
explaining the network access controls from both a sender and receiver point 
of view.  I'm certain I'll make a mistake or two, but hopefully somebody will 
point those out.

 A - sender without any form of labeled networking:
   1. The process must have write/send access to the socket
   2. The socket must have write/send access for the compat_net/SECMARK
      controls

 B - receiver without any form of labeled networking
   1. The packet's receiving socket must have read/recv access for the
      incoming packet based on the compat_net/SECMARK label
   2. The process must have read/recv access for the socket

 C - sender with labeled networking using NetLabel
   (same as without any labeled networking, see "A")

 D - receiver with labeled networking using NetLabel
   1. The packet's receiving socket must have read/recv access for the
      incoming packet based on the compat_net/SECMARK label
   2. The packet's receiving socket must have read/recv access for the
      incoming packet based on the NetLabel security attributes
   3. The process must have read/recv access for the socket

It is a bit more complicated with labeled IPsec as you have to deal with 
labeled matching of the socket and SPD/SA but I'll leave that as an exercise 
for the reader.

-- 
paul moore
linux security @ hp

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

Re: Question on networking accesses

[Casey Schaufler]

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

> On Monday, May 21 2007 12:07:21 pm Casey Schaufler wrote:
> > --- 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.
> 
> The example wasn't quite what I was hoping for as I'm still a little confused
> 
> as to exactly what you are looking for.  However, it's Monday and writing 
> email is looking more attractive than real work so let me take a stab at 
> explaining the network access controls from both a sender and receiver point 
> of view.  I'm certain I'll make a mistake or two, but hopefully somebody will
> 
> point those out.
> 
>  A - sender without any form of labeled networking:
>    1. The process must have write/send access to the socket
>    2. The socket must have write/send access for the compat_net/SECMARK
>       controls
> 
>  B - receiver without any form of labeled networking
>    1. The packet's receiving socket must have read/recv access for the
>       incoming packet based on the compat_net/SECMARK label
>    2. The process must have read/recv access for the socket

If I read this correctly you're saying that within each process
there are controls on using sockets (A1, A2, B2) and that in
addition to those the receiver requires read access (B1) to the
packet, based on the label attached to it. The label attached to
the packet is an object label, not a subject label, and is determined
by the attributes of the sender.

>  C - sender with labeled networking using NetLabel
>    (same as without any labeled networking, see "A")
> 
>  D - receiver with labeled networking using NetLabel
>    1. The packet's receiving socket must have read/recv access for the
>       incoming packet based on the compat_net/SECMARK label
>    2. The packet's receiving socket must have read/recv access for the
>       incoming packet based on the NetLabel security attributes
>    3. The process must have read/recv access for the socket
> 
> It is a bit more complicated with labeled IPsec as you have to deal with 
> labeled matching of the socket and SPD/SA but I'll leave that as an exercise 
> for the reader.

It appears that you're treating the packet as a labeled object,
with creation by the sender and deletion by either the receiver
on successful delivery or the system on failure. This model has
has had a tough row to hoe in prior evaluations, as a network
packet does not fit the traditional object model well. I'm curious
how the evaluation questions are being addressed.


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.

Re: Question on networking accesses

[Paul Moore]

On Monday, May 21 2007 4:18:48 pm Casey Schaufler wrote:
> --- Paul Moore <paul.moore@hp.com> wrote:
> > On Monday, May 21 2007 12:07:21 pm Casey Schaufler wrote:
> > > --- 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.
> >
> > The example wasn't quite what I was hoping for as I'm still a little
> > confused
> >
> > as to exactly what you are looking for.  However, it's Monday and writing
> > email is looking more attractive than real work so let me take a stab at
> > explaining the network access controls from both a sender and receiver
> > point of view.  I'm certain I'll make a mistake or two, but hopefully
> > somebody will
> >
> > point those out.
> >
> >  A - sender without any form of labeled networking:
> >    1. The process must have write/send access to the socket
> >    2. The socket must have write/send access for the compat_net/SECMARK
> >       controls
> >
> >  B - receiver without any form of labeled networking
> >    1. The packet's receiving socket must have read/recv access for the
> >       incoming packet based on the compat_net/SECMARK label
> >    2. The process must have read/recv access for the socket
>
> If I read this correctly you're saying that within each process
> there are controls on using sockets (A1, A2, B2) and that in
> addition to those the receiver requires read access (B1) to the
> packet, based on the label attached to it.

Actually it's receiver's socket which requires read access to the packet, this 
is important as the socket's label is not always the same as the process 
which created it.  Not sure if it matters for our discussion here, but I 
didn't want that detail lost. 

> The label attached to the packet is an object label, not a subject label,

Yes.

> and is determined by the attributes of the sender.

Whoa there, not always.  Under SELinux packets can have two labels, 
an "internal" or generated label which is determined locally by the 
compat_net/SECMARK mechanisms and an "external" label which is assigned by 
the sender either though NetLabel or labeled IPsec.

> >  C - sender with labeled networking using NetLabel
> >    (same as without any labeled networking, see "A")
> >
> >  D - receiver with labeled networking using NetLabel
> >    1. The packet's receiving socket must have read/recv access for the
> >       incoming packet based on the compat_net/SECMARK label
> >    2. The packet's receiving socket must have read/recv access for the
> >       incoming packet based on the NetLabel security attributes
> >    3. The process must have read/recv access for the socket
> >
> > It is a bit more complicated with labeled IPsec as you have to deal with
> > labeled matching of the socket and SPD/SA but I'll leave that as an
> > exercise for the reader.
>
> It appears that you're treating the packet as a labeled object,
> with creation by the sender and deletion by either the receiver
> on successful delivery or the system on failure. This model has
> has had a tough row to hoe in prior evaluations, as a network
> packet does not fit the traditional object model well.

Okay, I'll bite - why not, and what did prior systems do?

-- 
paul moore
linux security @ hp

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

Re: Question on networking accesses

[Casey Schaufler]

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

> On Monday, May 21 2007 4:18:48 pm Casey Schaufler wrote:
> > --- Paul Moore <paul.moore@hp.com> wrote:
> > > On Monday, May 21 2007 12:07:21 pm Casey Schaufler wrote:
> > > > --- 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.
> > >
> > > The example wasn't quite what I was hoping for as I'm still a little
> > > confused
> > >
> > > as to exactly what you are looking for.  However, it's Monday and writing
> > > email is looking more attractive than real work so let me take a stab at
> > > explaining the network access controls from both a sender and receiver
> > > point of view.  I'm certain I'll make a mistake or two, but hopefully
> > > somebody will
> > >
> > > point those out.
> > >
> > >  A - sender without any form of labeled networking:
> > >    1. The process must have write/send access to the socket
> > >    2. The socket must have write/send access for the compat_net/SECMARK
> > >       controls
> > >
> > >  B - receiver without any form of labeled networking
> > >    1. The packet's receiving socket must have read/recv access for the
> > >       incoming packet based on the compat_net/SECMARK label
> > >    2. The process must have read/recv access for the socket
> >
> > If I read this correctly you're saying that within each process
> > there are controls on using sockets (A1, A2, B2) and that in
> > addition to those the receiver requires read access (B1) to the
> > packet, based on the label attached to it.
> 
> Actually it's receiver's socket which requires read access to the packet,
> this 
> is important as the socket's label is not always the same as the process 
> which created it.  Not sure if it matters for our discussion here, but I 
> didn't want that detail lost. 

What is a socket in this model? If a socket requires read access
to the packet it would seem that the socket is an active entity.
If the socket does not have the same accesses as the process it is
attached to, it starts to sound as if the socket is a seperate
entity from the process. It almost sounds like the socket is a
subject in its own right. I don't think that's what you intend,
but I could be wrong.

> > The label attached to the packet is an object label, not a subject label,
> 
> Yes.
> 
> > and is determined by the attributes of the sender.
> 
> Whoa there, not always.

Gulp.

> Under SELinux packets can have two labels, 
> an "internal" or generated label which is determined locally by the 
> compat_net/SECMARK mechanisms and an "external" label which is assigned by 
> the sender either though NetLabel or labeled IPsec.

The packet can get a label-of-convinience for cases where the
attributes of the sender are unavailable and must be infered.
Ok by me.

> > >  C - sender with labeled networking using NetLabel
> > >    (same as without any labeled networking, see "A")
> > >
> > >  D - receiver with labeled networking using NetLabel
> > >    1. The packet's receiving socket must have read/recv access for the
> > >       incoming packet based on the compat_net/SECMARK label
> > >    2. The packet's receiving socket must have read/recv access for the
> > >       incoming packet based on the NetLabel security attributes
> > >    3. The process must have read/recv access for the socket
> > >
> > > It is a bit more complicated with labeled IPsec as you have to deal with
> > > labeled matching of the socket and SPD/SA but I'll leave that as an
> > > exercise for the reader.
> >
> > It appears that you're treating the packet as a labeled object,
> > with creation by the sender and deletion by either the receiver
> > on successful delivery or the system on failure. This model has
> > has had a tough row to hoe in prior evaluations, as a network
> > packet does not fit the traditional object model well.
> 
> Okay, I'll bite - why not, and what did prior systems do?

The question always comes down to what are the subjects, and
what are the objects. For a packet to be an object on it's own
it needs a name by which a subject can access it, and packets
don't have names. Further, processes don't go out of their way
to access packets, the data packets contain shows up in a socket
as if by magic.

The systems that I worked on treated it as the sender writing to
the receiver, with sender and receiver attributes contained in the
respective sockets. The sender is the subject doing the write,
and the receiver is the object being written to, with sockets and
various other kernel data containers being used to ensure that
the information required to make access checks is available where
required.

The primary difference is that in the 20th century scheme the
subject (sender) and object (receiver) are clearly identified
whereas in the SELinux scheme a subject (sender) creates something
that doesn't quite look like an object (packet) that is read by
something that sort of resembles a subject (socket) but that does
not actually have a life of its own, being a data component of a
of the receiver.


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.

Re: Question on networking accesses

[Paul Moore]

On Monday 21 May 2007 5:06:36 pm Casey Schaufler wrote:
> --- Paul Moore <paul.moore@hp.com> wrote:
> > On Monday, May 21 2007 4:18:48 pm Casey Schaufler wrote:
> > Under SELinux packets can have two labels,
> > an "internal" or generated label which is determined locally by the
> > compat_net/SECMARK mechanisms and an "external" label which is assigned
> > by the sender either though NetLabel or labeled IPsec.
>
> The packet can get a label-of-convinience for cases where the
> attributes of the sender are unavailable and must be infered.
> Ok by me.

Just to be clear, the internal label is not quite the same as the external 
label.  Both can be used to control access between a packet and it's sending 
or receiving socket but that is where the similarities end; for example you 
can't do a getpeercon() call on a connection that does not have an external 
label.

I mention this because it is my understanding the other trusted OSs had a 
facility to assign "external" labels to packets that were not labeled, i.e. 
the "label-of-convenience".  For example, all traffic on interface X is 
labeled "SuperSecret" while traffic on interface Y is 
labeled "SuperDoubleSecret".  At some point I would like implement something 
like this, as I see this as a nice feature, but we currently do not support 
this use case.

> > > It appears that you're treating the packet as a labeled object,
> > > with creation by the sender and deletion by either the receiver
> > > on successful delivery or the system on failure. This model has
> > > has had a tough row to hoe in prior evaluations, as a network
> > > packet does not fit the traditional object model well.
> >
> > Okay, I'll bite - why not, and what did prior systems do?
>
> The question always comes down to what are the subjects, and
> what are the objects. For a packet to be an object on it's own
> it needs a name by which a subject can access it, and packets
> don't have names.

Perhaps not a name in a conventional sense, but I think you could consider 
them as having a name based on the src/port-dst/port tuple.  After all, if 
there was no way to identify packets how would networking work and what is a 
name if not a way to identify an object?

> Further, processes don't go out of their way 
> to access packets, the data packets contain shows up in a socket
> as if by magic.

I see your point, but the process does have to explicitly perform an action to 
receive data.  In the case of stream connections an accept() is required 
whereas datagram connections require a recvfrom/msg/etc call.  As far as 
the "magic", how does data get into a file to be consumed by a process :)

> The systems that I worked on treated it as the sender writing to
> the receiver, with sender and receiver attributes contained in the
> respective sockets. The sender is the subject doing the write,
> and the receiver is the object being written to, with sockets and
> various other kernel data containers being used to ensure that
> the information required to make access checks is available where
> required.
>
> The primary difference is that in the 20th century scheme the
> subject (sender) and object (receiver) are clearly identified
> whereas in the SELinux scheme a subject (sender) creates something
> that doesn't quite look like an object (packet) that is read by
> something that sort of resembles a subject (socket) but that does
> not actually have a life of its own, being a data component of a
> of the receiver.

I guess with SELinux you could think of it as the following:

 - process A (subject) writes to socket A1 (object)
 - socket A1 (subject) sends packet to compat_net/SECMARK (object)

    packet traverses the ether (real magic)

 - socket B1 (subject) receives the packet via int/ext labels (object)
 - process B (subject) receives the data via socket B1 (object)

While it's different from what you may be used to I don't think it's _that_ 
different, especially if you tilt your head ever so slightly and squint.

-- 
paul moore
linux security @ hp

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

Re: Question on networking accesses

[Casey Schaufler]

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

> On Monday 21 May 2007 5:06:36 pm Casey Schaufler wrote:
> > --- Paul Moore <paul.moore@hp.com> wrote:
> > > On Monday, May 21 2007 4:18:48 pm Casey Schaufler wrote:
> > > Under SELinux packets can have two labels,
> > > an "internal" or generated label which is determined locally by the
> > > compat_net/SECMARK mechanisms and an "external" label which is assigned
> > > by the sender either though NetLabel or labeled IPsec.
> >
> > The packet can get a label-of-convinience for cases where the
> > attributes of the sender are unavailable and must be infered.
> > Ok by me.
> 
> Just to be clear, the internal label is not quite the same as the external 
> label.  Both can be used to control access between a packet and it's sending 
> or receiving socket but that is where the similarities end; for example you 
> can't do a getpeercon() call on a connection that does not have an external 
> label.

Ok.

> I mention this because it is my understanding the other trusted OSs had a 
> facility to assign "external" labels to packets that were not labeled, i.e. 
> the "label-of-convenience".  For example, all traffic on interface X is 
> labeled "SuperSecret" while traffic on interface Y is 
> labeled "SuperDoubleSecret".  At some point I would like implement something 
> like this, as I see this as a nice feature, but we currently do not support 
> this use case.

Yes, it's very handy, although I can see how it might be especially
difficult in the DTE (a "came off this wire" domain?) environment.

> > > > It appears that you're treating the packet as a labeled object,
> > > > with creation by the sender and deletion by either the receiver
> > > > on successful delivery or the system on failure. This model has
> > > > has had a tough row to hoe in prior evaluations, as a network
> > > > packet does not fit the traditional object model well.
> > >
> > > Okay, I'll bite - why not, and what did prior systems do?
> >
> > The question always comes down to what are the subjects, and
> > what are the objects. For a packet to be an object on it's own
> > it needs a name by which a subject can access it, and packets
> > don't have names.
> 
> Perhaps not a name in a conventional sense, but I think you could consider 
> them as having a name based on the src/port-dst/port tuple.  After all, if 
> there was no way to identify packets how would networking work and what is a 
> name if not a way to identify an object?

Hum. Except that you can have multiple packets with that tuple at the
same time, and no way to discriminate. One of the characteristics of
IP is that it does not identify packets. That's why we have to deal
with so many security issues. Since there's no way to pick a particular
packet (since they're all named Bruce) I don't think you've got a name.

> 
> > Further, processes don't go out of their way 
> > to access packets, the data packets contain shows up in a socket
> > as if by magic.
> 
> I see your point, but the process does have to explicitly perform an action
> to 
> receive data. In the case of stream connections an accept() is required 
> whereas datagram connections require a recvfrom/msg/etc call.  As far as 
> the "magic", how does data get into a file to be consumed by a process :)

In the case of a file, a subject writes it. In the case of a socket,
a packet appears (from where?) and the "socket reads it", then the
process can read the socket.


> > The systems that I worked on treated it as the sender writing to
> > the receiver, with sender and receiver attributes contained in the
> > respective sockets. The sender is the subject doing the write,
> > and the receiver is the object being written to, with sockets and
> > various other kernel data containers being used to ensure that
> > the information required to make access checks is available where
> > required.
> >
> > The primary difference is that in the 20th century scheme the
> > subject (sender) and object (receiver) are clearly identified
> > whereas in the SELinux scheme a subject (sender) creates something
> > that doesn't quite look like an object (packet) that is read by
> > something that sort of resembles a subject (socket) but that does
> > not actually have a life of its own, being a data component of a
> > of the receiver.
> 
> I guess with SELinux you could think of it as the following:
> 
>  - process A (subject) writes to socket A1 (object)
>  - socket A1 (subject) sends packet to compat_net/SECMARK (object)
> 
>     packet traverses the ether (real magic)
> 
>  - socket B1 (subject) receives the packet via int/ext labels (object)
>  - process B (subject) receives the data via socket B1 (object)
> 
> While it's different from what you may be used to I don't think it's _that_ 
> different, especially if you tilt your head ever so slightly and squint.

You're getting very close to our 1993 paper (S. Romero, C. Schaufler,
and N. Bolyard, "BSD IPC model and policy," in Proc. 16th National
Computer Security Conference, (Baltimore, MD), pp. 97-- 106, 1993.)
in your thinking. That paper sent the NSA evaluators off for months,
after which they redefined what qualifies as an object explicitly
to prevent etherial objects.

Well, you've answered my question. Thank you.


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.

Re: Question on networking accesses

[Steve G]

>I guess with SELinux you could think of it as the following:
>
> - process A (subject) writes to socket A1 (object)
> - socket A1 (subject) sends packet to compat_net/SECMARK (object)
>
>    packet traverses the ether (real magic)
>
> - socket B1 (subject) receives the packet via int/ext labels (object)
> - process B (subject) receives the data via socket B1 (object)

I think this is missing the access control decisions. First, the sender has to be
in a domain that allows a connect/sendto, the connection between domains must be
allowed by policy, and the receiver has to be in a domain that allows
listen/recvfrom. This is omitting any DAC restrictions, capability requirements,
and IPTables rules which have first vote on denying the activity. The access
control is mostly at the entry points to the transaction and not on a packet by
packet basis (except perhaps udp where every packet is an entry point to the
transaction).

-Steve


      ____________________________________________________________________________________Shape Yahoo! in your own image.  Join our Network Research Panel today!   http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 



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

Re: Question on networking accesses

[Paul Moore]

On Tuesday, May 22 2007 8:39:56 am Steve G wrote:
> The access
> control is mostly at the entry points to the transaction and not on a
> packet by packet basis (except perhaps udp where every packet is an entry
> point to the transaction).

Access control checks are performed on a packet by packet basis as it is 
received by the socket, see selinux_socket_sock_rcv_skb().

-- 
paul moore
linux security @ hp

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

Re: Question on networking accesses

[Casey Schaufler]

--- Steve G <linux_4ever@yahoo.com> wrote:

> 
> >I guess with SELinux you could think of it as the following:
> >
> > - process A (subject) writes to socket A1 (object)
> > - socket A1 (subject) sends packet to compat_net/SECMARK (object)
> >
> >    packet traverses the ether (real magic)
> >
> > - socket B1 (subject) receives the packet via int/ext labels (object)
> > - process B (subject) receives the data via socket B1 (object)
> 
> I think this is missing the access control decisions. First, the sender has
> to be
> in a domain that allows a connect/sendto, the connection between domains must
> be
> allowed by policy, and the receiver has to be in a domain that allows
> listen/recvfrom. This is omitting any DAC restrictions, capability
> requirements,
> and IPTables rules which have first vote on denying the activity. The access
> control is mostly at the entry points to the transaction and not on a packet
> by
> packet basis (except perhaps udp where every packet is an entry point to the
> transaction).

The nut of my question, which I think Paul has answered, is about
the subtle distintion between A writing to B and B reading from A.
There sure is a lot of sophistication involved in the process, and
it looks as if A thinks it is writing and B thinks it is reading.
That implies an intermediate object for A to write and B to read.
As I noted before, models with insubstantial objects have been frowned
upon in the past. Y'all may be better positioned to argue in their
favor than I was back in '95 an '02.


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.