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

[Trent Jaeger]

On Jun 21, 2006, at 10:56 AM, Venkat Yekkirala wrote:

>>>> It seems like semantics of the flow sid is different between output
>>>> and input.  On output, it's based on the socket and on input it's
>>>> based on the sa.  The flow/sa analogy makes sense to me, but the
>>>> socket less so (multiple sockets can use the same flow).
>>>
>>> Different flows (as opposed to sockets) may use the same
>> flow cache
>>> entry.
>>> Is that what you meant here?
>>
>> No.  I meant that the flow's sid is computed from the socket on
>> output and the sa on input.  These would seem to have different
>> authorization requirements to me (socket requires permission to send
>> on output and sa should match policy on input).  Does that
>> make sense
>> or should I try to be more specific?
>>
>> The cache uses these sid's subsequently of course, but we authorize
>> socket to sa on input and flow (which is derived from socket) to sa
>> on output.
>>
>
> Let's take an example.
>
> Given that you have the following in the xfrm policy:
>
> xfrm_policy ftpd_xfrm_t
>
> xfrm_state  ftpd_sa_t (optionally can be negotiated via IKE, in  
> which case
> it would use ftpd_xfrm_t as the type for the negotiated SA).
>
> This is how SELinux policy would look like:
>
> For output:
>
> allow ftpd_t ftpd_xfrm_t:association { polmatch };
> allow ftpd_t ftpd_sa_t:association { sendto };
>
> allow ftpd_sa_t ftpd_xfrm_t:association { polmatch };

So, the socket's type need not match the policy's type or the sa's  
type (nor does the sa's type have to match the policy's type) as long  
as the subjects in this have 'polmatch' access.

So, the answer to the question below is 'yes, if polmatch permission  
from sock type to policy'

	Question: if the sock type does not match the policy type  
(xfrm_lookup hook on output
	step (2)), can we send the packet?

This was my concern, so this resolves the problem although the  
operation polmatch is a bit non-intuitive.

Should we use another term? ('use' 'apply' -- poluse doesn't sound so  
good)  Is there a precedent for this type of operation in SELinux?

> For input:
>
> allow ftpd_sa_t ftpd_xfrm_t:association { polmatch }; (ALREADY  
> ALLOWED PER
> OUTPUT POLICY)
>
> allow ftpd_t ftpd_sa_t:association { recvfrom };

This makes sense.

> If you are wondering about the asymmetry in the number of access  
> checks, it
> is because in the output case there's the extra step of selecting  
> SAs given
> a xfrm policy rule and a flow/socket, whereas in the input case the  
> SAs are
> already tied to the flow. This assymetry is thus inherent.

Yes, I understand this, and agree with this approach.

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