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

Trent Jaeger tjaeger at cse.psu.edu
Sat Jun 17 02:00:53 UTC 2006


On Jun 16, 2006, at 4:31 PM, Venkat Yekkirala wrote:

>> In selinux_xfrm_policy_lookup, we check that the fl_sid has
>> access to
>> the xfrm policy's sid before using that policy.
>>
>> On input, I take this to mean that we must have granted the type of
>> the SA access to the policy,
>
> That is correct.
>> and the case of the server receiving a
>> packet from a client these would be the same (client's type).
>
> Probably, but since we have the SA Type delinked from the  
> xfrm_policy Type
> it's all entirely upto the policy.

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?

Regards,
Trent.
----------------------------------------------
Trent Jaeger, Associate Professor
Pennsylvania State University, CSE Dept
346A IST Bldg, University Park, PA 16802
Email: tjaeger at cse.psu.edu
Ph: (814) 865-1042, Fax: (814) 865-3176






More information about the redhat-lspp mailing list