[redhat-lspp] Re: [RFC] [MLSXFRM 02/04] Add enforcement to SE Linux LSM

[Venkat Yekkirala]

The key concept here is the flow. The flow attributes (derived from the
socket
in the locally generated case, derived from the packet in the forwarding
case, etc.)
determine the xfrm policy to use on the outbound. On the inbound,
it's again the flow attributes (derived from the packet) that need to
satisfy
a xfrm policy rule (the first matching one) completely.

> -----Original Message-----
> From: Venkat Yekkirala 
> Sent: Monday, June 19, 2006 10:34 AM
> To: Trent Jaeger; Venkat Yekkirala
> Cc: redhat-lspp at redhat.com; sds at tycho.nsa.gov; latten at austin.ibm.com;
> jmorris at redhat.com
> Subject: RE: [redhat-lspp] Re: [RFC] [MLSXFRM 02/04] Add 
> enforcement to
> SE Linux LSM
> 
> 
> > I guess that what I envisioned is that we would deduce a type 
> > for the  
> > socket (even if there isn't a specific one, we could infer 
> for some  
> > such as an ICMP reply), use the flow sid to limit the choice of  
> > appropriate xfrm_policy types (we hadn't added this, but now you  
> > have), and then determine access of the socket type to the policy  
> > type (as limited by choices relevant to the flow).
> > 
> > My understanding of the basis for the current  
> > selinux_xfrm_policy_lookup is that you do not believe that we can  
> > deduce the socket's type effectively for several cases 
> (particularly  
> > on input), so we need to check for the socket's access in 
> > rcv_skb and  
> > use the flow sid in lookup.  I am not 100% convinced that the  
> > deduction is not possible (although I only looked had 
> > problems on the  
> > output). Is there a convincing argument?
> 
> It's more a matter of necessity (specifically the lack of) 
> than whether such a
> deduction is possible.
> 
> On the outbound the socket happens to play a (a somewhat 
> indirect) role in policy
> selection because the flow derives the relevant attributes 
> from the socket. In an
> incremental patch I was going to post later, the policy would 
> actually be selected
> based on an openreq, when a return syn is generated, for 
> example. Also, in the
> forwarding case there's no socket involved, so the outbound 
> policy is again selected
> based on the flow.
> 
> But on the inbound, the packet already has all the attributes 
> needed to make
> the policy selection. All that is demanded by the xfrm policy 
> on the inbound
> is that "some" policy rule defined on the system be "fully" 
> satisfied which is
> what we have in xfrm_policy_check(). The only role for the 
> socket in there is
> when "socket-specific" policy needs to be used, in which case 
> we do see a socket
> passed in, and we do handle it taking the security context 
> into account. So, 
> in general, the socket plays no role in policy selection on 
> the inbound.
>