[refpolicy] [RFC] Removal of unlabeled_t packet rules

[refpolicy] [RFC] Removal of unlabeled_t packet rules

[Christopher J. PeBenito]

Back when the SECMARK implementation was new, the packet class was always checked.  Because of that, unlabeled_t packet rules proliferated refpolicy since the common case was to have no SECMARK rules.  Since then, the kernel has been modified to only enforce the packet class if there are SECMARK rules.  I believe the unlabeled_t packet rules should be removed, since users of SECMARK will likely want no unlabeled_t packet rules, and the common case users will have no impact since the packet class isn't enforced on their systems.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

[refpolicy] [RFC] Removal of unlabeled_t packet rules

[Sven Vermeulen]

On Fri, May 03, 2013 at 09:23:53AM -0400, Christopher J. PeBenito wrote:
> Back when the SECMARK implementation was new, the packet class was always checked.  Because of that, unlabeled_t packet rules proliferated refpolicy since the common case was to have no SECMARK rules.  Since then, the kernel has been modified to only enforce the packet class if there are SECMARK rules.  I believe the unlabeled_t packet rules should be removed, since users of SECMARK will likely want no unlabeled_t packet rules, and the common case users will have no impact since the packet class isn't enforced on their systems.

Does that mean that, once an admin marks a particular rule with a security
context (even if it is just a single rule) that the administrator has to
(1.) explicitly mark all network traffic, and (2.) grant all network facing
domains access to that marked traffic?

Wkr,
	Sven Vermeulen

[refpolicy] [RFC] Removal of unlabeled_t packet rules

[Christopher J. PeBenito]

On 05/03/13 14:08, Sven Vermeulen wrote:
> On Fri, May 03, 2013 at 09:23:53AM -0400, Christopher J. PeBenito wrote:
>> Back when the SECMARK implementation was new, the packet class was always checked.  Because of that, unlabeled_t packet rules proliferated refpolicy since the common case was to have no SECMARK rules.  Since then, the kernel has been modified to only enforce the packet class if there are SECMARK rules.  I believe the unlabeled_t packet rules should be removed, since users of SECMARK will likely want no unlabeled_t packet rules, and the common case users will have no impact since the packet class isn't enforced on their systems.
> 
> Does that mean that, once an admin marks a particular rule with a security
> context (even if it is just a single rule) that the administrator has to
> (1.) explicitly mark all network traffic, and (2.) grant all network facing
> domains access to that marked traffic?

Yes.  But you can just as easily do this:

allow { domain -type_i_want_to_constrain_t } unlabeled_t:packet { send recv };

if you only want one domain to be constrained by SECMARK.  This would be equivalent to no SECMARK rules for everything else.  It seems like over-allowing, but if you have no SECMARK rules, it's the equivalent of:

allow * unlabeled_t:packet { send recv };

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

[refpolicy] [RFC] Removal of unlabeled_t packet rules

[Christopher J. PeBenito]

On 05/03/13 09:23, Christopher J. PeBenito wrote:
> Back when the SECMARK implementation was new, the packet class was always checked.  Because of that, unlabeled_t packet rules proliferated refpolicy since the common case was to have no SECMARK rules.  Since then, the kernel has been modified to only enforce the packet class if there are SECMARK rules.  I believe the unlabeled_t packet rules should be removed, since users of SECMARK will likely want no unlabeled_t packet rules, and the common case users will have no impact since the packet class isn't enforced on their systems.
 
Since there have been no objections, the rules have been removed.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com