FYI- the below explains the policy needed for the mlsxfrm controls. In the
case where "unlabeled" ipsec is being used, the policy rules as well as the
static SAs will be deemed to have the "unlabeled_t" type.
> -----Original Message-----
> From: Venkat Yekkirala
> Sent: Tuesday, June 27, 2006 9:03 AM
> To: 'Steve Grubb'; lspp-list
> Subject: RE: [redhat-lspp] lspp 39 kernel released
>
>
> Joy was going to post a detailed howto. For the new/modified controls
> this patch introduces, the following would be what the policy would
> boild down to for a given domain.
>
> ---------------------------------------------
> Let's take an example.
>
> Given that you have the following in the IPSec policy:
>
> Policy rule for ftpd defined with the context: ftpd_xfrm_t
>
> Security Association defined with the context: 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 an IPSec policy rule and a
> flow/socket, whereas in the input case the SAs are already
> tied to the flow. This assymetry is thus inherent.
> --------------------------------------------
>
--
redhat-lspp mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/redhat-lspp
