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

[Venkat Yekkirala]

-----Original Message-----
From: Venkat Yekkirala 
Sent: Friday, June 16, 2006 10:04 AM
To: 'Trent Jaeger'
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
SELinux LSM


> I am not sure that this semantics works right for the TE case 
> where a  
> server may receive requests from clients of different types.

The server may receive requests from clients of different types
(as taken from the SAs the requests used) as long as the server type
has the association { recvfrom } access to the client (SA) type per
SELinux policy.

> 
> In that case, a server may be authorized to receive packets from  
> several different typed clients, so the challenge is to ensure that  
> the server is authorized for a policy consistent with the flow on  
> which the packet was received.

It has always been the case that the attributes of the incoming packet
determined the policy to use (and rightfully so since you don't have a
socket
in the forward case for example). It is only necessary to check that "a"
xfrm policy
is "completely" satisfied by the packet (in terms of the SAs it used). The
later
check in sock_rcv_skb() will ensure that the socket can receive the packet
from
the SA used only if allowed by the SELinux policy.

One exception is the case where there's a xfrm policy specifically applied
on
a socket and we do continue to honor that (again subject to the SELinux
policy).

> 
> The patch will result in checking whether the type of the flow has  
> access to the policy's type.   Typically, these will be the same in  
> the case that should work (i.e., the flow's type should match the  
> policy's type, so the right SAs will be used).  However, there may  

The Types need not literally be the same; the flow Type should just
"polmatch" the xfrm_policy Type per the SELinux policy.
> not be any subjects of this type in the system (or its policy) since  
> these are the client's subject type probably.
> 
> In general, it seems reasonable that a subject of a particular type  
> should be able to use SA's of that same type, but this is not  
> guaranteed to be the policy (since the server has a different type)  
> and this could be a bit tricky to debug.
> 
> I was envisioning that the server socket type be used to authorize  
> access to policies of the flow's type only, but this presents two  

This isn't necessary since selinux_xfrm_sock_rcv_skb() will arbitrate
socket access to the SA.

If the above don't address your concerns please let me know (an example
will be of huge help here). Thanks.