[redhat-lspp] Re: Networking policy patch
Christopher J. PeBenito
cpebenito at tresys.com
Thu Oct 5 18:18:07 UTC 2006
On Tue, 2006-10-03 at 21:54 -0500, Venkat Yekkirala wrote:
> FYI- I have posted the following patches separate from this one.
>
> 1. A patch to address the "leask" issue. Once verified, it needs
> to be rolled in with James' patch and sent on after verification.
>
> 2. A fix for flow_in and flow_out where we were using the unlabeled
> init sid. We would now use a new network_t with a range of (s0-s15...)
> to allow for mls traffic to flow out/in, in the absence of explicit secmark
> rules.
>
>
> The following is a sample patch for networking using the new controls
> in conjunction with secmark.
>
> NOTE FOR JOSHUA: This patch also defines the constraints to force context
> equality for association:sendto.
I'm starting a labeled networking branch of refpolicy to work with this.
I'm waiting until the dust settles before adding TE rules, but I have
some questions:
> +mlsconstrain association { recvfrom }
> + ((( l1 dom l2 ) and ( l1 domby h2 )) or
> + (( t1 == mlsnetreadtoclr ) and ( h1 dom l2 )) or
> + ( t1 == mlsnetread ) or
> + ( t2 == unlabeled_t ));
Don't we want network_t instead of unlabeled_t?
> +mlsconstrain association { sendto }
> + (( l1 eq l2 ) and ( h1 eq h2 ));
or (t2 == network_t) ?
> +mlsconstrain association { polmatch }
> + ((( l1 dom l2 ) and ( l1 domby h2 )) or
> + ( t2 == unlabeled_t ));
same thing about network_t
> +constrain association sendto
> + ( u1 == u2 and r1 == r2 and t1 == t2 );
I talked with Joshua and we determined that there is a case were we
don't want this constraint (looking forward to policy management
server's use of labeled networking), so I've dropped it.
--
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150
More information about the redhat-lspp
mailing list