RFC: packet checks always on option

RFC: packet checks always on option

[Christopher J. PeBenito]

I recently became aware that the packet checks are now disabled when there are no SECMARK rules.  I missed the threads discussing this change (I realize its been some time), and the non-enforcement of a check isn't obvious.  Refpolicy's support of unlabeled packet usage also obscured the change.

My understanding on the rationale for this change was:

* when flushing iptables, it would lead to all networking being denied, which is opposite of the expected behavior of iptables (i.e. doesn't follow "least surprise")
* if you have no SECMARK rules, you probably don't care about the checks anyway

I completely understand these arguments, as they are reasonable functional arguments.  However, this behavior is "allow by default": the opposite of what SELinux stands for.  SELinux doesn't stop file checks if you mount an xattr filesystem that has no labels.  High assurance systems would actually want the old behavior so that networking would be denied if:

* iptables rules fail to load
* iptables rules maliciously flushed, e.g. by compromised domain that has net_admin
* during boot and shutdown you can guarantee no network access

I think this behavior should be restored, but in a pragmatic way.  I think we should have an option to toggle between packet checks always being on and packet checks on only if there are SECMARK rules.  Then distros can ship with the latter setting.  For the systems that care about it, they can use the former setting.  Then everyone wins.

Options for implementing this are:

* a policy capability
* a policy option similar to unknown permissions checking
* a SELinux option similar to how compat_net was

I think the policy capability is not the best choice, since it doesn't exactly follow the concept of a policy capability.  A policy capability would imply that there are no packet checks under any circumstance if the policy capability is off, which wouldn't be the case.  I don't know which of the latter two options are better, other than the latter wouldn't require toolchain changes.

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: RFC: packet checks always on option

[Paul Moore]

On Tuesday, May 08, 2012 12:58:00 PM Christopher J. PeBenito wrote:
> I recently became aware that the packet checks are now disabled when there
> are no SECMARK rules ...
>
> ... this behavior is "allow by default": the opposite of what SELinux stands
> for.  SELinux doesn't stop file checks if you mount an xattr filesystem that
> has no labels.  High assurance systems would actually want the old behavior
> so that networking would be denied if:
> 
> * iptables rules fail to load
> * iptables rules maliciously flushed, e.g. by compromised domain that has
> net_admin

Ever since secmark was introduced it has required users/admins to ensure, via 
a secondary mechanism not contained within the SELinux policy, that the 
netfilter/iptables configuration was both correctly matched to the policy and 
that is was not tampered with, either maliciously or accidentally.  Failure to 
do this verification and correctly configure netfilter/iptables could result 
in the mis-labeling of network traffic via the secmark label.

This applies to both the current behavior and the "old" behavior.

Simply going back to always applying the per-packet secmark access controls 
does nothing to solve the problem of ensuring correctness.  This is my main 
problem with your argument.

> * during boot and shutdown you can guarantee no network access

You can do this through a variety of other mechanisms that have nothing to do 
with secmark labels.
 
> I think this behavior should be restored ...

I disagree.

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: RFC: packet checks always on option

[Christopher J. PeBenito]

On 05/10/12 16:02, Paul Moore wrote:
> On Tuesday, May 08, 2012 12:58:00 PM Christopher J. PeBenito wrote:
>> I recently became aware that the packet checks are now disabled when there
>> are no SECMARK rules ...
>>
>> ... this behavior is "allow by default": the opposite of what SELinux stands
>> for.  SELinux doesn't stop file checks if you mount an xattr filesystem that
>> has no labels.  High assurance systems would actually want the old behavior
>> so that networking would be denied if:
>>
>> * iptables rules fail to load
>> * iptables rules maliciously flushed, e.g. by compromised domain that has
>> net_admin
> 
> Ever since secmark was introduced it has required users/admins to ensure, via 
> a secondary mechanism not contained within the SELinux policy, that the 
> netfilter/iptables configuration was both correctly matched to the policy and 
> that is was not tampered with, either maliciously or accidentally.  Failure to 
> do this verification and correctly configure netfilter/iptables could result 
> in the mis-labeling of network traffic via the secmark label.
>
> This applies to both the current behavior and the "old" behavior.
> 
> Simply going back to always applying the per-packet secmark access controls 
> does nothing to solve the problem of ensuring correctness.  This is my main 
> problem with your argument.

I don't understand what correctness you're referring to.  Labeling correctness?  You always need that; thats the crux of having a proper running system.  But we don't stop enforcing policy if its not correct.  It sounds like you'd argue that if a filesystem with no labels is loaded that it should not have any enforcement.  That relies on the VFS as a secondary mechanism.
 
>> * during boot and shutdown you can guarantee no network access
> 
> You can do this through a variety of other mechanisms that have nothing to do 
> with secmark labels.

No, you can't.  None of them are enforceable as soon as the policy is loaded.  Otherwise you have gaps in enforcement, which is not desired for some systems.  The whole point of MAC systems is to reduce the trust in userspace code, and the above suggestion puts more trust in userspace code.

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: RFC: packet checks always on option

[Paul Moore]

On Monday, May 14, 2012 08:52:29 AM Christopher J. PeBenito wrote:
> On 05/10/12 16:02, Paul Moore wrote:
> > Ever since secmark was introduced it has required users/admins to ensure,
> > via a secondary mechanism not contained within the SELinux policy, that
> > the netfilter/iptables configuration was both correctly matched to the
> > policy and that is was not tampered with, either maliciously or
> > accidentally.  Failure to do this verification and correctly configure
> > netfilter/iptables could result in the mis-labeling of network traffic
> > via the secmark label.
> > 
> > This applies to both the current behavior and the "old" behavior.
> > 
> > Simply going back to always applying the per-packet secmark access
> > controls does nothing to solve the problem of ensuring correctness.  This
> > is my main problem with your argument.
> 
> I don't understand what correctness you're referring to.  Labeling
> correctness?  You always need that; thats the crux of having a proper
> running system.  But we don't stop enforcing policy if its not correct.

That last sentence is particularly interesting, but I'll avoid commentary on 
it for right now ...

My concern is that for every aspect of the system that I can think of, and 
feel free to correct me if I'm missing something (as I know you will), the 
system's policy can enforce the (re)labeling of the subjects and objects on 
the system so it has _some_ control over the assigned labels.  There are also 
tools, e.g. restorecon, which can be used to verify/reset/correct the labels 
on persistent filesystem objects.  With those two things you should be able to 
verify the correctness of a filesystem's labels and then ensure it stays 
correct.

With secmark labels we still have the ability to enforce the (re)labeling via 
the system's policy, but we are missing the ability to verify/reset/correct 
the label assignment.

> >> * during boot and shutdown you can guarantee no network access
> > 
> > You can do this through a variety of other mechanisms that have nothing to
> > do with secmark labels.
> 
> No, you can't.

Yes, you can. See "netif:{ ingress egress }".

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: RFC: packet checks always on option

[Chad Hanson]

> > >> * during boot and shutdown you can guarantee no network access
> > > 
> > > You can do this through a variety of other mechanisms that have 
> > > nothing to do with secmark labels.
> > 
> > No, you can't.
> 
> Yes, you can. See "netif:{ ingress egress }".
> 

This assumes you have netlabel rules enabled. I would like to see the configuration option noted as a possibility in netlbl_enabled() to be 1 without a kernel patch. This then would assure that there are always netif checks are active in the absence of secmark rules is this is desired.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: RFC: packet checks always on option

[Paul Moore]

On Monday, May 14, 2012 04:42:06 PM Chad Hanson wrote:
> > > >> * during boot and shutdown you can guarantee no network access
> > > > 
> > > > You can do this through a variety of other mechanisms that have
> > > > nothing to do with secmark labels.
> > > 
> > > No, you can't.
> > 
> > Yes, you can. See "netif:{ ingress egress }".
> 
> This assumes you have netlabel rules enabled.

Look at the code a bit closer; it works with both labeled IPsec and NetLabel.

Regardless, I see your point.

> I would like to see the configuration option noted as a possibility in
> netlbl_enabled() to be 1 without a kernel patch. This then would assure that
> there are always netif checks are active in the absence of secmark rules is
> this is desired.

*If* we were to do something to enable the per-packet access checks regardless 
of configuration I agree, we should enable the secmark checks and the peer 
label checks.

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: RFC: packet checks always on option

[Stephen Smalley]

On Tue, 2012-05-08 at 12:58 -0400, Christopher J. PeBenito wrote:
> I recently became aware that the packet checks are now disabled when there are no SECMARK rules.  I missed the threads discussing this change (I realize its been some time), and the non-enforcement of a check isn't obvious.  Refpolicy's support of unlabeled packet usage also obscured the change.
> 
> My understanding on the rationale for this change was:
> 
> * when flushing iptables, it would lead to all networking being denied, which is opposite of the expected behavior of iptables (i.e. doesn't follow "least surprise")
> * if you have no SECMARK rules, you probably don't care about the checks anyway
> 
> I completely understand these arguments, as they are reasonable functional arguments.  However, this behavior is "allow by default": the opposite of what SELinux stands for.  SELinux doesn't stop file checks if you mount an xattr filesystem that has no labels.  High assurance systems would actually want the old behavior so that networking would be denied if:
> 
> * iptables rules fail to load
> * iptables rules maliciously flushed, e.g. by compromised domain that has net_admin
> * during boot and shutdown you can guarantee no network access
> 
> I think this behavior should be restored, but in a pragmatic way.  I think we should have an option to toggle between packet checks always being on and packet checks on only if there are SECMARK rules.  Then distros can ship with the latter setting.  For the systems that care about it, they can use the former setting.  Then everyone wins.
> 
> Options for implementing this are:
> 
> * a policy capability
> * a policy option similar to unknown permissions checking
> * a SELinux option similar to how compat_net was
> 
> I think the policy capability is not the best choice, since it doesn't exactly follow the concept of a policy capability.  A policy capability would imply that there are no packet checks under any circumstance if the policy capability is off, which wouldn't be the case.  I don't know which of the latter two options are better, other than the latter wouldn't require toolchain changes.

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?

I think another factor in the change had to do with ensuring that new
kernel + old policy continued to work in the face of various changes to
the packet and peer permission checking logic without needing to define
new policy capabilities.

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.  Maybe you just need a
clear name for the policy capability, like deny_unlabeled_packets.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: RFC: packet checks always on option

[Stephen Smalley]

On Mon, 2012-05-14 at 13:17 -0400, Stephen Smalley wrote:
> On Tue, 2012-05-08 at 12:58 -0400, Christopher J. PeBenito wrote:
> > I recently became aware that the packet checks are now disabled when there are no SECMARK rules.  I missed the threads discussing this change (I realize its been some time), and the non-enforcement of a check isn't obvious.  Refpolicy's support of unlabeled packet usage also obscured the change.
> > 
> > My understanding on the rationale for this change was:
> > 
> > * when flushing iptables, it would lead to all networking being denied, which is opposite of the expected behavior of iptables (i.e. doesn't follow "least surprise")
> > * if you have no SECMARK rules, you probably don't care about the checks anyway
> > 
> > I completely understand these arguments, as they are reasonable functional arguments.  However, this behavior is "allow by default": the opposite of what SELinux stands for.  SELinux doesn't stop file checks if you mount an xattr filesystem that has no labels.  High assurance systems would actually want the old behavior so that networking would be denied if:
> > 
> > * iptables rules fail to load
> > * iptables rules maliciously flushed, e.g. by compromised domain that has net_admin
> > * during boot and shutdown you can guarantee no network access
> > 
> > I think this behavior should be restored, but in a pragmatic way.  I think we should have an option to toggle between packet checks always being on and packet checks on only if there are SECMARK rules.  Then distros can ship with the latter setting.  For the systems that care about it, they can use the former setting.  Then everyone wins.
> > 
> > Options for implementing this are:
> > 
> > * a policy capability
> > * a policy option similar to unknown permissions checking
> > * a SELinux option similar to how compat_net was
> > 
> > I think the policy capability is not the best choice, since it doesn't exactly follow the concept of a policy capability.  A policy capability would imply that there are no packet checks under any circumstance if the policy capability is off, which wouldn't be the case.  I don't know which of the latter two options are better, other than the latter wouldn't require toolchain changes.
> 
> 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?
> 
> I think another factor in the change had to do with ensuring that new
> kernel + old policy continued to work in the face of various changes to
> the packet and peer permission checking logic without needing to define
> new policy capabilities.
> 
> 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.  Maybe you just need a
> clear name for the policy capability, like deny_unlabeled_packets.

I guess that isn't quite right - maybe "always_check_packets".

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: RFC: packet checks always on option

[Paul Moore]

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.
 
> 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.

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: RFC: packet checks always on option

[Christopher J. PeBenito]

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.  Refpolicy has netif_t and node_t access for every networking domain too.  If you fully define your SECMARK rules, then there wouldn't be any unlabeled_t packets.  Similarly, if you fully described everything with netifcons and nodecons, you wouldn't get checks on netif_t and node_t.  My argument is for the people that care about this and would likely be modifying their policy to strip out the unlabeled packet access anyway.
  
>> 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.  You don't want an *option* for changing the behavior of an enabled mechanism (SECMARK), and then in another email you're suggesting adding an additional mechanism (labeled ipsec/netlabel), which would otherwise be unused (assuming you're turning it on just to handle the situations I'm mentioning).

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: RFC: packet checks always on option

[Paul Moore]

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 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.

> You don't want an *option* for changing the behavior of an enabled
> mechanism (SECMARK), and then in another email you're suggesting adding an
> additional mechanism (labeled ipsec/netlabel), which would otherwise be
> unused (assuming you're turning it on just to handle the situations I'm
> mentioning).

I'm not suggesting adding anything, what I've suggested already exists.  
However, as Chad pointed out, this approach has its own drawbacks.

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: RFC: packet checks always on option

[Christopher J. PeBenito]

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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: RFC: packet checks always on option

[Paul Moore]

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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: RFC: packet checks always on option

[Christopher J. PeBenito]

On 05/15/12 11:04, Paul Moore wrote:
> 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:
>>>>>> 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.

Of course for a system to work right you need correct enforcement, correct policy, and correct labeling.  My whole argument is about the enforcement.  If you have correct labeling and correct policy but wrong enforcement, its still incorrect.  I'm only trying to argue on the enforcement; label correctness is important, just not for this discussion.

I can see if you're saying that a system a SECMARK ruleset that fails to load would have incorrect labels for packets.  I agree with that.  But this is a similar situation to /dev labeling being initialized by udev.  The enforcement on files in /dev starts as soon as the filesystem is mounted, rather than when the labeling is initialized by udev.  If udev fails, then the enforcement still goes on with the initial labels, which is why we have restrictive initial labels, rather than disabled.

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: RFC: packet checks always on option

[Paul Moore]

On Tuesday, May 15, 2012 11:46:27 AM Christopher J. PeBenito wrote:
> On 05/15/12 11:04, Paul Moore wrote:
> > On Tuesday, May 15, 2012 10:47:25 AM Christopher J. PeBenito wrote:
> >> On 05/15/12 10:13, Paul Moore wrote:
> >>> 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.
> 
> Of course for a system to work right you need correct enforcement, correct
> policy, and correct labeling.  My whole argument is about the enforcement. 
> If you have correct labeling and correct policy but wrong enforcement, its
> still incorrect. I'm only trying to argue on the enforcement; label
> correctness is important, just not for this discussion.

My argument is that worrying about enforcement without demonstrating you've 
solved the labeling issue is pointless.  It is my opinion that the labels have 
to be correct before you can perform any worthwhile enforcement.

If you want to move forward with a policy capability to enable the per-packet 
access checks, please provide a mechanism to manage/verify/etc. the secmark 
label configuration within the greater scope of the policy.  I think someone 
made some effort at this a while back, but I believe it died out fairly 
quickly; I can't recall what the approach was exactly (I think it basically 
encapsulated the iptables rules somehow) but at least it was a start.

> I can see if you're saying that a system a SECMARK ruleset that fails to
> load would have incorrect labels for packets.  I agree with that.

There is also the even more sinister danger of mis-labeling, e.g. "coke" being 
labeled as "pepsi".

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: RFC: packet checks always on option

[david caplan]

On 5/15/2012 2:45 PM, Paul Moore wrote:
> On Tuesday, May 15, 2012 11:46:27 AM Christopher J. PeBenito wrote:
>> On 05/15/12 11:04, Paul Moore wrote:
>>> On Tuesday, May 15, 2012 10:47:25 AM Christopher J. PeBenito wrote:
>>>> On 05/15/12 10:13, Paul Moore wrote:
>>>>> 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.
>>
>> Of course for a system to work right you need correct enforcement, correct
>> policy, and correct labeling.  My whole argument is about the enforcement. 
>> If you have correct labeling and correct policy but wrong enforcement, its
>> still incorrect. I'm only trying to argue on the enforcement; label
>> correctness is important, just not for this discussion.
> 
> My argument is that worrying about enforcement without demonstrating you've 
> solved the labeling issue is pointless.  It is my opinion that the labels have 
> to be correct before you can perform any worthwhile enforcement.

I agree that worthwhile enforcement requires correct labels but I'm not
following how that relates to having a complete non-bypassable
mechanism. If I understand correctly, when there are no SECMARK rules
then the related security checks on packets are not performed - i.e. the
default behavior is to allow any domain access to any packet. Isn't that
contrary to the behavior of how every other SELinux enforcement point works?

> 
> If you want to move forward with a policy capability to enable the per-packet 
> access checks, please provide a mechanism to manage/verify/etc. the secmark 
> label configuration within the greater scope of the policy.  I think someone 
> made some effort at this a while back, but I believe it died out fairly 
> quickly; I can't recall what the approach was exactly (I think it basically 
> encapsulated the iptables rules somehow) but at least it was a start.
> 
>> I can see if you're saying that a system a SECMARK ruleset that fails to
>> load would have incorrect labels for packets.  I agree with that.
> 
> There is also the even more sinister danger of mis-labeling, e.g. "coke" being 
> labeled as "pepsi".
> 

I'm not sure how the potential danger of mislabeling supports the
argument that the default behavior - with *no* specific labeling - is to
allow all access.

David




--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: RFC: packet checks always on option

[Paul Moore]

On Thu, May 17, 2012 at 10:06 AM, david caplan <dac@tresys.com> wrote:
> On 5/15/2012 2:45 PM, Paul Moore wrote:
>> On Tuesday, May 15, 2012 11:46:27 AM Christopher J. PeBenito wrote:
>>> On 05/15/12 11:04, Paul Moore wrote:
>>>> On Tuesday, May 15, 2012 10:47:25 AM Christopher J. PeBenito wrote:
>>>>> On 05/15/12 10:13, Paul Moore wrote:
>>>>>> 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.
>>>
>>> Of course for a system to work right you need correct enforcement, correct
>>> policy, and correct labeling.  My whole argument is about the enforcement.
>>> If you have correct labeling and correct policy but wrong enforcement, its
>>> still incorrect. I'm only trying to argue on the enforcement; label
>>> correctness is important, just not for this discussion.
>>
>> My argument is that worrying about enforcement without demonstrating you've
>> solved the labeling issue is pointless.  It is my opinion that the labels have
>> to be correct before you can perform any worthwhile enforcement.
>
> I agree that worthwhile enforcement requires correct labels but I'm not
> following how that relates to having a complete non-bypassable
> mechanism.

Either way the security policy isn't enforced correctly.

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: RFC: packet checks always on option

[david caplan]

On 5/17/2012 10:42 AM, Paul Moore wrote:
> On Thu, May 17, 2012 at 10:06 AM, david caplan <dac@tresys.com> wrote:
>> On 5/15/2012 2:45 PM, Paul Moore wrote:
>>> On Tuesday, May 15, 2012 11:46:27 AM Christopher J. PeBenito wrote:
>>>> On 05/15/12 11:04, Paul Moore wrote:
>>>>> On Tuesday, May 15, 2012 10:47:25 AM Christopher J. PeBenito wrote:
>>>>>> On 05/15/12 10:13, Paul Moore wrote:
>>>>>>> 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.
>>>>
>>>> Of course for a system to work right you need correct enforcement, correct
>>>> policy, and correct labeling.  My whole argument is about the enforcement.
>>>> If you have correct labeling and correct policy but wrong enforcement, its
>>>> still incorrect. I'm only trying to argue on the enforcement; label
>>>> correctness is important, just not for this discussion.
>>>
>>> My argument is that worrying about enforcement without demonstrating you've
>>> solved the labeling issue is pointless.  It is my opinion that the labels have
>>> to be correct before you can perform any worthwhile enforcement.
>>
>> I agree that worthwhile enforcement requires correct labels but I'm not
>> following how that relates to having a complete non-bypassable
>> mechanism.
> 
> Either way the security policy isn't enforced correctly.
> 

No, if there is no enforcement mechanism then the policy is 100% not
enforced. If there is an enforcement mechanism then there is some chance
that it is enforced correctly.

If you're running an SELinux system you have some faith that your
policy, including labeling, is correct and you (should) have an
expectation that access to any object defined in that policy is mediated.



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: RFC: packet checks always on option

[Paul Moore]

On Thu, May 17, 2012 at 11:31 AM, david caplan <dac@tresys.com> wrote:
> On 5/17/2012 10:42 AM, Paul Moore wrote:
>> On Thu, May 17, 2012 at 10:06 AM, david caplan <dac@tresys.com> wrote:
>>> On 5/15/2012 2:45 PM, Paul Moore wrote:
>>>> On Tuesday, May 15, 2012 11:46:27 AM Christopher J. PeBenito wrote:
>>>>> On 05/15/12 11:04, Paul Moore wrote:
>>>>>> On Tuesday, May 15, 2012 10:47:25 AM Christopher J. PeBenito wrote:
>>>>>>> On 05/15/12 10:13, Paul Moore wrote:
>>>>>>>> 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.
>>>>>
>>>>> Of course for a system to work right you need correct enforcement, correct
>>>>> policy, and correct labeling.  My whole argument is about the enforcement.
>>>>> If you have correct labeling and correct policy but wrong enforcement, its
>>>>> still incorrect. I'm only trying to argue on the enforcement; label
>>>>> correctness is important, just not for this discussion.
>>>>
>>>> My argument is that worrying about enforcement without demonstrating you've
>>>> solved the labeling issue is pointless.  It is my opinion that the labels have
>>>> to be correct before you can perform any worthwhile enforcement.
>>>
>>> I agree that worthwhile enforcement requires correct labels but I'm not
>>> following how that relates to having a complete non-bypassable
>>> mechanism.
>>
>> Either way the security policy isn't enforced correctly.
>
> No, if there is no enforcement mechanism then the policy is 100% not
> enforced. If there is an enforcement mechanism then there is some chance
> that it is enforced correctly.

Either way you have no guarantee that the policy is enforced correctly.

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: RFC: packet checks always on option

[Daniel J Walsh]

-----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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.