On Fri, 2006-09-29 at 10:00 -0400, Joshua Brindle wrote:
> On Fri, 2006-09-29 at 08:59 -0400, Stephen Smalley wrote:
> > On Thu, 2006-09-28 at 23:52 -0400, Joshua Brindle wrote:
> > > Venkat Yekkirala wrote:
> > > > <snip>
> > > > +
> > > > + err = avc_has_perm(xfrm_sid, skb->secmark, SECCLASS_PACKET,
> > > > + PACKET__FLOW_IN, NULL);
> > > > + if (err)
> > > > + goto out;
> > > > +
> > > > + if (xfrm_sid) {
> > > > + err = security_transition_sid(xfrm_sid, skb->secmark,
> > > > + SECCLASS_PACKET,
> > > > &trans_sid);
> > > > + if (err)
> > > > + goto out;
> > > > +
> > > >
> > > I thought we weren't doing transitions to label packets anymore per the
> > > conference call?
> >
> > No, transitions are still part of the reconciliation process. By
> > default, this just means that we end up with the xfrm_sid (which is what
> > you want). But it allows us the freedom to define transitions on the
> > secmark label if desired, and those transitions can still yield subject
> > labels.
> >
>
> This is not consistent with my perception of the decision made in the
> conference call. I thought that the secid was either going to be 1) the
> secmark label if no external labeling is present or 2) the external
> label if it is present. The flow_in permission would be checked between
> the external label and the secmark label in either case (unlabeled in
> the case of #1)
The behavior you describe is precisely what will happen in the absence
of any type_transition rules on packet class in the policy, given the
way in which he has defined security_transition_sid on packet class.
The only question is whether there is any value in allowing a transition
to be configured in policy (and if such a transition is configured,
whether the resulting SID requires its own separate permission check,
which is what is usually done - the transition doesn't implicitly
authorize anything). I don't recall a particular decision on the
transition issue during the call nor do I see it in the posted notes.
However, since the transition was removed in the flow_out case, it would
be logical to remove it from the flow_in case as well, and that would
have the side benefit of less overhead.
--
Stephen Smalley
National Security Agency
-
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
