> -----Original Message----- > From: Joy Latten [mailto:latten@xxxxxxxxxxxxxx] > Sent: Friday, February 15, 2008 4:27 PM > To: Clarkson, Mike R (US SSA) > Cc: selinux@xxxxxxxxxxxxx > Subject: RE: Brindle example of labeled IPSec > > > >I understand why there is no labeling after doing "setkey -FP". That was > >expected. > > > >My question is why does the labeling work in enforcing mode, even though > >my policy does not provide the following rules: > >allow brindle_client_t ipsec_spd_t:association polmatch; > >allow brindle_client_t brindle_server_t:association recvfrom; > > > >With labeled IPSec over the loopback, I did not have to provide any > >rules in my brindle_client module or my brindle_server module with > >respect to the association object class. Without the association rules, > >the policy doesn't have any way of enforcing MLS constraints, or TE on > >the client server connections, which is the reason that I set up labeled > >IPSec over loopback in the first place. > > If I recall correctly, these rules are in Redhat's policy. > The interface ipsec_labeled(domain) allows types with > domain attribute to polmatch to ipsec_spd_t and to also > have recvfrom and sendto permissions. When you did > domain_type(brindle_server_t) and domain_type(brindle_clent_t) > they acquired the domain attribute. > > As long as you use ipsec_spd_t as default ipsec policy type, > things should work without having to add new policy for labeled ipsec. > However, if you create or use a new ipsec policy type other > than ipsec_spd_t, you will need new rules to get labeled ipsec working. I agree with everything that you've mentioned above, the only problem being that my brindle_client and brindle_server modules didn't call the ipsec_labeled interface. That's why I'm confused as to why it is working. It shouldn't be working. > > What I am not sure I understand is why you want to add mls constraints to > these rules. I think mls constraints already exist for "association". > Unless you want to add them for your client and server... I don't want to add MLS constraints to these rules, as you mentioned they already exist. The problem is that because I don't have to add the TE rules for the "association" class in my policy, the policy can not enforce the MLS constraints that already exist. > > regards, > Joy -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
