Specifically:
- polmatch need no longer make an exception for unlabeled_t
since a flow will now always match SPD rules with no contexts (per
the IPSec leak fix patch upstreamed a few weeks back), as
opposed to needing polmatch access to unlabeled_t.
Signed-off-by: Venkat Yekkirala <vyekkirala@TrustedCS.com>
> We could add another 'or' on the above constraint:
>
> or ( (t2 == mlsfilewrite_in_range) and (l1 dom l2) and (h1 domby h2) )
>
> I believe that would be the constraint you were looking for. I don't
> like the name of that attribute, but I couldn't come up with a better
> one off the top of my head. :)
>
Attached is a patch which I've tested against selinux-policy-2.4.2-1
that implements this additional constraint. The name is still a bit
forced, but it works.
-matt <mra at hp dot com>
* fix userdom_search_all_users_home_content() to use search_dir_perms;
* change ssh daemon macro to use userdom_search_all_users_home_dirs() instead of _home_content()
a xfrm policy. It also defines MLS policy for association { sendto,
recvfrom, polmatch }.
NOTE: When an inbound packet is not using an IPSec SA, a check is performed
between the socket label and the unlabeled sid (SYSTEM_HIGH MLS label). For
MLS purposes however, the target of the check should be the MLS label taken
from the node sid (or secmark in the new secmark world). This would present
a severe performance overhead (to make a new sid based on the unlabeled sid
with the MLS taken from the node sid or secmark and then using this sid as
the target). Pending reconciliation of the netlabel, ipsec and iptables contexts,
I have chosen to currently make an exception for unlabeled_t SAs if TE policy
allowed it. A similar problem exists for the outbound case and it has been similarly
handled in the policy below (by making an exception for unlabeled_t).
I am submitting the below limited patch pending a comprehensive patch from
Joy Latten at IBM (latten@austin.ibm.com).
I am not sure if I needed to manually do a "make tolib" in the flask subdir
and submit the results as well. Please let me know if I needed to.
Signed-off-by: Venkat Yekkirala <vyekkirala@TrustedCS.com>
