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

[Venkat Yekkirala]

> 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.