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

[Trent Jaeger]

On Jun 13, 2006, at 6:09 PM, Venkat Yekkirala wrote:


> -int selinux_xfrm_policy_lookup(struct xfrm_policy *xp, u32 sk_sid,  
> u8 dir)
> +int selinux_xfrm_policy_lookup(struct xfrm_policy *xp, u32 fl_sid,  
> u8 dir)
> {
> 	int rc = 0;
> 	u32 sel_sid = SECINITSID_UNLABELED;
> @@ -85,24 +85,131 @@ int selinux_xfrm_policy_lookup(struct xf
> 		sel_sid = ctx->ctx_sid;
> 	}
> -	rc = avc_has_perm(sk_sid, sel_sid, SECCLASS_ASSOCIATION,
> -			  ((dir == FLOW_DIR_IN) ? ASSOCIATION__RECVFROM :
> -			   ((dir == FLOW_DIR_OUT) ?  ASSOCIATION__SENDTO :
> -			    (ASSOCIATION__SENDTO | ASSOCIATION__RECVFROM))),
> +	rc = avc_has_perm(fl_sid, sel_sid, SECCLASS_ASSOCIATION,
> +			  ASSOCIATION__POLMATCH,
> 			  NULL);
> 	return rc;
> }

I took a look at the patches, and I am good with them, in general.

I only have one small issue from the code above that I wanted to raise.

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

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.

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  
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  
challenges: (1) input messages w/o an associated socket ( Venkat  
indicated several cases, although I had no experience in that) and  
(2) we would still need to limit lookup only to appropriate types  
(not done in any of the code currently).

Comments?

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