Re: Network flow controls and subj/obj ordering

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

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

> Hello everybody,
> 
> After a discussion with Venkat last week we decided that it was probably best
> 
> if I took responsibility for the flow control patches and ported/cleaned them
> 
> up for inclusion in the labeled networking patches for 2.6.25.  In the course
> 
> of doing so I ran across the problem of subject/object "ordering" (probably 
> not the best term, but it's all I can think of right now).  In both the "flow
> 
> in" and "flow out" cases I'm tempted to use the packet's peer label as the 
> object just for the sake of consistency and the ability to use the new "peer"
> 
> object class for all network peer label access checks.  However, I wanted to 
> make sure that is what everyone had in mind from a conceptual point of view. 
> 
> See the two simple policy examples below:
> 
>  * Packet "flows" into the system, peer label is the object
> 
>    allow netif_t peerlbl_t:peer flow_in;
> 
>  * Packet "flows" out of the system, peer label is the object
> 
>    allow netif_t peerlbl_t:peer flow_out;
> 
> Thoughts, opinions?

Networking policy is always fun to debate. I've gotten it wrong
so many times I've lost count. Let's see if I can add anything of
value.

A packet appears out of the ether and is attached to a flow. If the
packet is a labeled object and the flow is a labeled object, what
is the subject? If the packet moves on out of the system (it is
being forwarded) and the packet is a labeled object, what is the
subject? Do you even have a subject/object relationship in this case?
I think that if you can identify the subject involved in flow
processing the policy implications ought to be pretty clear. If
you don't, and you have nothing but objects to deal with, it gets
painfully difficult to produce a security model that can be described
using traditional methods.

I will point out that it is pretty difficult to associate a subject
with an action on a packet object in all cases, and that is one reason
the model of a packet as an object never caught on. Perhaps the flow
is your subject, performing read and write operations on the packets.
I don't know that it makes a lot of sense to consider a flow as a
subject, but I've made arguments from shakier premises myself.

Think about the notion that the flow is the object, and that the
subject is whatever created the packet, and the label on the packet
describes the subject. This makes the operation a write from the
packet creator to the flow. It makes the outflow a read from the
flow by whatever active entity (task? kthread? daemon?) sends the
packet along, and a write to the destination with the label on the
packet again describing that subject.

In any case, if you don't bring a subject into the picture you may
have processing to do, but you're not making access control decisions.


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.