On Tuesday, May 15, 2012 10:47:25 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 ... I didn't "delete" it - it's a public mailing list that is well archived after all - I just didn't feel the need to reply to that point so I left it out of my email. > >>>> 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. Perhaps I'm reading the two sentences above wrong, perhaps I'm thinking about it wrong, or perhaps you didn't write them as intended; but the two sentences above seem to contradict each other in my mind. I just don't see how you can have enforcement via labels without correct application of the labels themselves. > What do you want to do with correctness? While it is a bit simplistic, the quickest example I can think of is a restorecon mechanism for secmark labels. -- paul moore www.paul-moore.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.
