-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/15/2012 10:47 AM, Christopher J. PeBenito wrote: > On 05/15/12 10:13, Paul Moore wrote: >> On Tuesday, May 15, 2012 09:24:20 AM Christopher J. PeBenito wrote: >>> On 05/14/12 17:15, Paul Moore wrote: >>>> On Monday, May 14, 2012 01:17:30 PM Stephen Smalley wrote: >>>>> Didn't the old behavior lead to the undesirable result that >>>>> refpolicy allows every domain (or at least every domain that does >>>>> networking) to send/recv unlabeled packets, such that you cannot >>>>> effectively employ SECMARK unless you first modify and rebuild your >>>>> entire policy to take away the unlabeled packet access? Whereas >>>>> with the new behavior one could drop those rules and then when >>>>> someone does enable SECMARK, they get to fully define the allowable >>>>> network traffic? >>>> >>>> Yep. >>> >>> Not any worse than with the old networking checks. >> >> I believe that was Stephen's point. > > I'm still standing by my point which you deleted: the people who would > care, who would likely modify their base policy anyway. Plus, you would > have to modify your base policy anyway to turn on the policy capability > which would toggle this behavior (I'm assuming no distro would have this > policycap on by default). So I acknowledge the point as valid for the old > behaviors, but I think the circumstances of this change make it > non-applicable. > >>>>> I'm not adverse to making it optional/configurable, but I think a >>>>> policy capability is how you should do it. That is what they are >>>>> for, and they are supposed to provide a more explicit mechanism >>>>> than either the handle_unknown logic or the old compat_net logic >>>>> ... >>>> >>>> *If* we decide to go this route, I agree, policy capabilities seem to >>>> be the best fit. >>>> >>>> However, as I said earlier in my emails to Chris, I'm still not >>>> certain this actually accomplishes anything useful. >>> >>> I don't understand how you can say this doesn't accomplish anything >>> useful. >> >> See my earlier comments in this thread about being able to verify the >> correctness of the secmark labels. This has always been my core concern >> with your argument: you are concerned about the ability for policy to >> control network traffic labeled via secmark, but you seem to ignore the >> issue that there is no mechanism to verify the correctness of the secmark >> labels. Making strong guarantees about the ability to enforce a given >> policy without any assurance that the labels are correct seems a bit >> silly to me. > > Believe me, as a policy person, I'd never ignore labeling correctness. I > don't think SECMARK rule correctness has anything to do with this discussion, as this is about the mechanism/enforcement itself. > > What do you want to do with correctness? The filesystem labeling can be checked contexts can be checked against file_contexts, but mismatches don't necessarily mean that the labeling is wrong. In my opinion, file_contexts should only be used to initialize the labeling, and thats it. Afterwards, the labeling is ruled by the relabeling rules. As long as the policy is correct and *being* *enforced* at all times, the labels should not get into an inconsistent state. That seems slightly optimistic... And if you really want to be pedantic, an security admin/officer should be verifying the labeling of objects after the system is installed, but before it goes into production. The same applies to SECMARK rules. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+zDmwACgkQrlYvE4MpobMM5wCeO+2XlPJJjvSMhuPWa280W+7K vWoAoJQt6fe88sJZCRJ9Zz7fChOjsdze =H6Xd -----END PGP SIGNATURE----- -- 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.
