On Wed, 2006-10-04 at 10:33 -0400, Paul Moore wrote:
> Venkat Yekkirala wrote:
> > The following replaces unlabeled_t with network_t for
> > better characterization of the flow out/in checks in
> > SELinux, as well as to allow for mls packets to
> > flow out/in from the network since network_t would allow
> > the full range of MLS labels, as opposed to the unlabeled init sid
> > that only allows system-hi.
> > 
> > Signed-off-by: Venkat Yekkirala <[EMAIL PROTECTED]>
> > ---
> > This is an incremental patch the secid-reconcilation v4 patchset.
> > 
> > --- net-2.6.sid3/security/selinux/hooks.c   2006-10-01 15:43:12.000000000 
> > -0500
> > +++ net-2.6/security/selinux/hooks.c        2006-10-03 16:43:21.000000000 
> > -0500
> > @@ -3703,7 +3703,8 @@ static int selinux_skb_flow_in(struct sk
> >     err = selinux_xfrm_decode_session(skb, &xfrm_sid, 0);
> >     BUG_ON(err);
> >  
> > -   err = avc_has_perm(xfrm_sid, skb->secmark, SECCLASS_PACKET,
> > +   err = avc_has_perm(xfrm_sid, skb->secmark? : SECINITSID_NETMSG,
> > +                                   SECCLASS_PACKET,
> >                                     PACKET__FLOW_IN, NULL);
> >     if (err)
> >             goto out;
> > @@ -3900,7 +3901,7 @@ static unsigned int selinux_ip_postroute
> >                             skb->secmark = sksec->sid;
> >                     }
> >             }
> > -           err = avc_has_perm(skb->secmark, SECINITSID_UNLABELED,
> > +           err = avc_has_perm(skb->secmark, SECINITSID_NETMSG,
> >                                SECCLASS_PACKET, PACKET__FLOW_OUT, &ad);
> >     }
> >  out:
> 
> Considering the above change, I wonder if it would also make sense to
> update the secmark to SECINITSID_UNLABELED in the abscence of any
> external labeling (labeled IPsec or NetLabel)?

Wouldn't that make secmark useless in the non labeled networking case?

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

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to