2009-02-06 22:15:09

by Paul Moore

[permalink] [raw]
Subject: [refpolicy] [RFC] Network MLS constraints


In the course of looking into a problem with the new network
ingress/egress controls with the MLS policy I realized we were missing
MLS constraints for a lot of the new network controls ... Ooops. Some
of the missing constraints are due to the new ingress/egress and peer
controls but I realized we are also missing the secmark controls. I
just finished putting a patch together (still need to test it) but I'm
not 100% certain about some of these constraints (the inbound controls)
so I wanted to send out this email to try and generate some discussion.

The first set of new constraints we need deal with the secmark and peer
controls. Both controls are applied to packets as they are received by
a socket and in both cases the subject is the socket and the packet is
the object. The constraints below should be fairly obvious:

mlsconstrain { peer packet } { recv }
(( l1 dom l2 ) or
(( t1 == mlsnetreadtoclr ) and ( h1 dom l2 )) or
( t1 == mlsnetread ));

The next set of constraints deal with the egress controls, packets that
are leaving the system. In this case the subject is the packet's peer
which is the originating domain; the object varies from the network
interface (netif/egress), destination (node/sendto) and outbound
secmark (packet/forward_out). Once again, I expect these constraints
to be fairly straightforward:

mlsconstrain { netif } { egress }
(( l1 eq l2 ) or
(( t1 == mlsnetwriteranged ) and ( l1 dom l2 ) and ( l1 domby h2 )) or
(( t1 == mlsnetwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
( t1 == mlsnetwrite));

mlsconstrain { node } { sendto }
(( l1 eq l2 ) or
(( t1 == mlsnetwriteranged ) and ( l1 dom l2 ) and ( l1 domby h2 )) or
(( t1 == mlsnetwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
( t1 == mlsnetwrite));

mlsconstrain { packet } { forward_out }
(( l1 eq l2 ) or
(( t1 == mlsnetwriteranged ) and ( l1 dom l2 ) and ( l1 domby h2 )) or
(( t1 == mlsnetwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
( t1 == mlsnetwrite)
( t1 == unlabeled_t));

The last set of constraints deal with the ingress controls, packets that
are entering the system. Here is where things become a bit less
obvious and while I spent a good deal of time convincing myself they
are "correct", I would appreciate some comments/feedback before I go
much further. The funny part about these constraints is that they look
very similar to the outbound constraints in that they are "write"
constraints. The reason for this is that the subject in each of these
constraints is not a local domain, but rather the remote system's
domain (the packet's peer). Take the netif/ingress constraint as an
example: even though this access control happens when the packet is
received by the local system, the permission/constraint is controlling
the peer's ability to write data to a network interface. While
treating the constraint as a "write" might not be the obvious first
choice I think it makes the most sense. You will note that the special
handling (pass) for unlabeled_t packets is to prevent any problems with
unlabeled traffic.

mlsconstrain { netif } { ingress }
(( l1 eq l2 ) or
(( t1 == mlsnetwriteranged ) and ( l1 dom l2 ) and ( l1 domby h2 )) or
(( t1 == mlsnetwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
( t1 == mlsnetwrite)
( t1 == unlabeled_t));

mlsconstrain { node } { sendto }
(( l1 eq l2 ) or
(( t1 == mlsnetwriteranged ) and ( l1 dom l2 ) and ( l1 domby h2 )) or
(( t1 == mlsnetwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
( t1 == mlsnetwrite));

# identical to the forward_out case
mlsconstrain { packet } { forward_in }
(( l1 eq l2 ) or
(( t1 == mlsnetwriteranged ) and ( l1 dom l2 ) and ( l1 domby h2 )) or
(( t1 == mlsnetwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
( t1 == mlsnetwrite)
( t1 == unlabeled_t));

--
paul moore
linux @ hp


2009-02-10 14:05:03

by cpebenito

[permalink] [raw]
Subject: [refpolicy] [RFC] Network MLS constraints

On Fri, 2009-02-06 at 17:15 -0500, Paul Moore wrote:
> In the course of looking into a problem with the new network
> ingress/egress controls with the MLS policy I realized we were missing
> MLS constraints for a lot of the new network controls ... Ooops. Some
> of the missing constraints are due to the new ingress/egress and peer
> controls but I realized we are also missing the secmark controls. I
> just finished putting a patch together (still need to test it) but I'm
> not 100% certain about some of these constraints (the inbound controls)
> so I wanted to send out this email to try and generate some discussion.

These seem reasonable to me. Perhaps including the SELinux list would
be a good idea to include, in case there are some MLS people on that
list that aren't on this list?

> The first set of new constraints we need deal with the secmark and peer
> controls. Both controls are applied to packets as they are received by
> a socket and in both cases the subject is the socket and the packet is
> the object. The constraints below should be fairly obvious:
>
> mlsconstrain { peer packet } { recv }
> (( l1 dom l2 ) or
> (( t1 == mlsnetreadtoclr ) and ( h1 dom l2 )) or
> ( t1 == mlsnetread ));
>
> The next set of constraints deal with the egress controls, packets that
> are leaving the system. In this case the subject is the packet's peer
> which is the originating domain; the object varies from the network
> interface (netif/egress), destination (node/sendto) and outbound
> secmark (packet/forward_out). Once again, I expect these constraints
> to be fairly straightforward:
>
> mlsconstrain { netif } { egress }
> (( l1 eq l2 ) or
> (( t1 == mlsnetwriteranged ) and ( l1 dom l2 ) and ( l1 domby h2 )) or
> (( t1 == mlsnetwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
> ( t1 == mlsnetwrite));
>
> mlsconstrain { node } { sendto }
> (( l1 eq l2 ) or
> (( t1 == mlsnetwriteranged ) and ( l1 dom l2 ) and ( l1 domby h2 )) or
> (( t1 == mlsnetwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
> ( t1 == mlsnetwrite));
>
> mlsconstrain { packet } { forward_out }
> (( l1 eq l2 ) or
> (( t1 == mlsnetwriteranged ) and ( l1 dom l2 ) and ( l1 domby h2 )) or
> (( t1 == mlsnetwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
> ( t1 == mlsnetwrite)
> ( t1 == unlabeled_t));
>
> The last set of constraints deal with the ingress controls, packets that
> are entering the system. Here is where things become a bit less
> obvious and while I spent a good deal of time convincing myself they
> are "correct", I would appreciate some comments/feedback before I go
> much further. The funny part about these constraints is that they look
> very similar to the outbound constraints in that they are "write"
> constraints. The reason for this is that the subject in each of these
> constraints is not a local domain, but rather the remote system's
> domain (the packet's peer). Take the netif/ingress constraint as an
> example: even though this access control happens when the packet is
> received by the local system, the permission/constraint is controlling
> the peer's ability to write data to a network interface. While
> treating the constraint as a "write" might not be the obvious first
> choice I think it makes the most sense. You will note that the special
> handling (pass) for unlabeled_t packets is to prevent any problems with
> unlabeled traffic.
>
> mlsconstrain { netif } { ingress }
> (( l1 eq l2 ) or
> (( t1 == mlsnetwriteranged ) and ( l1 dom l2 ) and ( l1 domby h2 )) or
> (( t1 == mlsnetwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
> ( t1 == mlsnetwrite)
> ( t1 == unlabeled_t));
>
> mlsconstrain { node } { sendto }
> (( l1 eq l2 ) or
> (( t1 == mlsnetwriteranged ) and ( l1 dom l2 ) and ( l1 domby h2 )) or
> (( t1 == mlsnetwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
> ( t1 == mlsnetwrite));
>
> # identical to the forward_out case
> mlsconstrain { packet } { forward_in }
> (( l1 eq l2 ) or
> (( t1 == mlsnetwriteranged ) and ( l1 dom l2 ) and ( l1 domby h2 )) or
> (( t1 == mlsnetwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
> ( t1 == mlsnetwrite)
> ( t1 == unlabeled_t));



--
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150

2009-02-10 14:39:18

by Paul Moore

[permalink] [raw]
Subject: [refpolicy] [RFC] Network MLS constraints

On Tuesday 10 February 2009 09:05:03 am Christopher J. PeBenito wrote:
> On Fri, 2009-02-06 at 17:15 -0500, Paul Moore wrote:
> > In the course of looking into a problem with the new network
> > ingress/egress controls with the MLS policy I realized we were missing
> > MLS constraints for a lot of the new network controls ... Ooops. Some
> > of the missing constraints are due to the new ingress/egress and peer
> > controls but I realized we are also missing the secmark controls. I
> > just finished putting a patch together (still need to test it) but I'm
> > not 100% certain about some of these constraints (the inbound controls)
> > so I wanted to send out this email to try and generate some discussion.
>
> These seem reasonable to me. Perhaps including the SELinux list would
> be a good idea to include, in case there are some MLS people on that
> list that aren't on this list?

Good idea. I was able to test out a patch with yesterday with the new
constraints and it behaved reasonably; I'll post the patch this week to both
the refpol and selinux lists.

--
paul moore
linux @ hp