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.