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. 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. -- Chris PeBenito Tresys Technology, LLC www.tresys.com | oss.tresys.com -- 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.
