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

[Venkat Yekkirala]

> >> 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 };


For input:

allow ftpd_sa_t ftpd_xfrm_t:association { polmatch }; (ALREADY ALLOWED PER
OUTPUT POLICY)

allow ftpd_t ftpd_sa_t:association { recvfrom };



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.