[PATCH 0/6] netfilter integration

[PATCH 0/6] netfilter integration

[Christopher J. PeBenito]

This patchset adds support for netfilter secmark rules in all policy
packages.  Each line of the file has a priority (1-9) at the beginning
of the line, and the remainder is treated as the rule.  Sorting is by
priority (1-9), and is stable within a module.  The current design is
for the resultant netfilter_contexts file be suitable for use with
iptables-restore.

This example would be the netfilter_contexts of the base module since it
has the extra portions required for iptables-restore use:

1 *mangle
1 :PREROUTING ACCEPT [0:0]
1 :INPUT ACCEPT [0:0]
1 :FORWARD ACCEPT [0:0]
1 :OUTPUT ACCEPT [0:0]
1 :POSTROUTING ACCEPT [0:0]
1 :selinux_input - [0:0]
1 :selinux_output - [0:0]
1 :selinux_new_input - [0:0]
1 :selinux_new_output - [0:0]
1 -A INPUT -j selinux_input
1 -A OUTPUT -j selinux_output
1 -A selinux_input -m state --state NEW -j selinux_new_input
1 -A selinux_input -m state --state RELATED,ESTABLISHED -j CONNSECMARK --restore
1 -A selinux_output -m state --state NEW -j selinux_new_output
1 -A selinux_output -m state --state RELATED,ESTABLISHED -j CONNSECMARK --restore
1 -A selinux_new_input -j SECMARK --selctx system_u:object_r:server_packet_t
5 -A selinux_new_input -p tcp --dport 80 -j SECMARK --selctx system_u:object_r:http_server_packet_t
9 -A selinux_new_input -j CONNSECMARK --save
9 -A selinux_new_input -j RETURN
1 -A selinux_new_output -j SECMARK --selctx system_u:object_r:client_packet_t
5 -A selinux_new_output -p tcp --dport 80 -j SECMARK --selctx system_u:object_r:http_client_packet_t
9 -A selinux_new_output -j CONNSECMARK --save
9 -A selinux_new_output -j RETURN
9 COMMIT

While individual loadable modules's netfilter_contexts would look like:

5 -A selinux_new_input -p tcp --dport 443 -j SECMARK --selctx system_u:object_r:http_server_packet_t
5 -A selinux_new_output -p tcp --dport 443 -j SECMARK --selctx system_u:object_r:http_client_packet_t

The below patch to refpolicy will create a file appropriate for testing.
The resultant linked and sorted file will be written out
to /etc/selinux/NAME/contexts/netfilter_contexts.

Index: Rules.modular
===================================================================
--- Rules.modular	(revision 1919)
+++ Rules.modular	(working copy)
@@ -89,10 +89,10 @@
 #
 # Create a base module package
 #
-$(BASE_PKG): $(BASE_MOD) $(BASE_FC) $(USERS_EXTRA) $(SEUSERS)
+$(BASE_PKG): $(BASE_MOD) $(BASE_FC) $(USERS_EXTRA) $(SEUSERS) $(net_contexts)
 	@echo "Creating $(NAME) base module package"
 	@test -d $(BUILDDIR) || mkdir -p $(BUILDDIR)
-	$(verbose) $(SEMOD_PKG) -o $@ -m $(BASE_MOD) -f $(BASE_FC) -u $(USERS_EXTRA) -s $(SEUSERS)
+	$(verbose) $(SEMOD_PKG) -o $@ -m $(BASE_MOD) -f $(BASE_FC) -u $(USERS_EXTRA) -s $(SEUSERS) -n $(net_contexts)
 
 $(BASE_MOD): $(BASE_CONF)
 	@echo "Compiling $(NAME) base module"
Index: support/gennetfilter.py
===================================================================
--- support/gennetfilter.py	(revision 1919)
+++ support/gennetfilter.py	(working copy)
@@ -43,7 +43,7 @@
 		self.ports = ports
 
 def print_input_rules(packets,mls,mcs):
-	line = "-A selinux_new_input -j SECMARK --selctx system_u:object_r:"+DEFAULT_INPUT_PACKET
+	line = "1 -A selinux_new_input -j SECMARK --selctx system_u:object_r:"+DEFAULT_INPUT_PACKET
 	if mls:
 		line += ":"+DEFAULT_MLS
 	elif mcs:
@@ -53,18 +53,18 @@
 
 	for i in packets:
 		for j in i.ports:
-			line="-A selinux_new_input -p "+j.proto+" --dport "+j.num+" -j SECMARK --selctx system_u:object_r:"+i.prefix+PACKET_INPUT
+			line="5 -A selinux_new_input -p "+j.proto+" --dport "+j.num+" -j SECMARK --selctx system_u:object_r:"+i.prefix+PACKET_INPUT
 			if mls:
 				line += ":"+j.mls_sens
 			elif mcs:
 				line += ":"+j.mcs_cats
 			print line
 
-	print "-A selinux_new_input -j CONNSECMARK --save"
-	print "-A selinux_new_input -j RETURN"
+	print "9 -A selinux_new_input -j CONNSECMARK --save"
+	print "9 -A selinux_new_input -j RETURN"
 
 def print_output_rules(packets,mls,mcs):
-	line = "-A selinux_new_output -j SECMARK --selctx system_u:object_r:"+DEFAULT_OUTPUT_PACKET
+	line = "1 -A selinux_new_output -j SECMARK --selctx system_u:object_r:"+DEFAULT_OUTPUT_PACKET
 	if mls:
 		line += ":"+DEFAULT_MLS
 	elif mcs:
@@ -73,15 +73,15 @@
 
 	for i in packets:
 		for j in i.ports:
-			line = "-A selinux_new_output -p "+j.proto+" --dport "+j.num+" -j SECMARK --selctx system_u:object_r:"+i.prefix+PACKET_OUTPUT
+			line = "5 -A selinux_new_output -p "+j.proto+" --dport "+j.num+" -j SECMARK --selctx system_u:object_r:"+i.prefix+PACKET_OUTPUT
 			if mls:
 				line += ":"+j.mls_sens
 			elif mcs:
 				line += ":"+j.mcs_cats
 			print line
 
-	print "-A selinux_new_output -j CONNSECMARK --save"
-	print "-A selinux_new_output -j RETURN"
+	print "9 -A selinux_new_output -j CONNSECMARK --save"
+	print "9 -A selinux_new_output -j RETURN"
 
 def parse_corenet(file_name):
 	packets = []
@@ -118,25 +118,25 @@
 	return packets
 
 def print_netfilter_config(packets,mls,mcs):
-	print "*mangle"
-	print ":PREROUTING ACCEPT [0:0]"
-	print ":INPUT ACCEPT [0:0]"
-	print ":FORWARD ACCEPT [0:0]"
-	print ":OUTPUT ACCEPT [0:0]"
-	print ":POSTROUTING ACCEPT [0:0]"
-	print ":selinux_input - [0:0]"
-	print ":selinux_output - [0:0]"
-	print ":selinux_new_input - [0:0]"
-	print ":selinux_new_output - [0:0]"
-	print "-A INPUT -j selinux_input"
-	print "-A OUTPUT -j selinux_output"
-	print "-A selinux_input -m state --state NEW -j selinux_new_input"
-	print "-A selinux_input -m state --state RELATED,ESTABLISHED -j CONNSECMARK --restore"
-	print "-A selinux_output -m state --state NEW -j selinux_new_output"
-	print "-A selinux_output -m state --state RELATED,ESTABLISHED -j CONNSECMARK --restore"
+	print "1 *mangle"
+	print "1 :PREROUTING ACCEPT [0:0]"
+	print "1 :INPUT ACCEPT [0:0]"
+	print "1 :FORWARD ACCEPT [0:0]"
+	print "1 :OUTPUT ACCEPT [0:0]"
+	print "1 :POSTROUTING ACCEPT [0:0]"
+	print "1 :selinux_input - [0:0]"
+	print "1 :selinux_output - [0:0]"
+	print "1 :selinux_new_input - [0:0]"
+	print "1 :selinux_new_output - [0:0]"
+	print "1 -A INPUT -j selinux_input"
+	print "1 -A OUTPUT -j selinux_output"
+	print "1 -A selinux_input -m state --state NEW -j selinux_new_input"
+	print "1 -A selinux_input -m state --state RELATED,ESTABLISHED -j CONNSECMARK --restore"
+	print "1 -A selinux_output -m state --state NEW -j selinux_new_output"
+	print "1 -A selinux_output -m state --state RELATED,ESTABLISHED -j CONNSECMARK --restore"
 	print_input_rules(packets,mls,mcs)
 	print_output_rules(packets,mls,mcs)
-	print "COMMIT"
+	print "9 COMMIT"
 
 mls = False
 mcs = False


-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
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: [PATCH 0/6] netfilter integration

[Casey Schaufler]

--- "Christopher J. PeBenito" <cpebenito@tresys.com>
wrote:

> This patchset adds support for netfilter secmark
> rules in all policy
> packages.  Each line of the file has a priority
> (1-9) at the beginning
> of the line, and the remainder is treated as the
> rule.  Sorting is by
> priority (1-9), and is stable within a module.  The
> current design is
> for the resultant netfilter_contexts file be
> suitable for use with
> iptables-restore.

How confident are you that 9 priorities
will be sufficient? I can easily imaging
dependency scenarios that would exceed
this limitation. I would also expect that
explict ordering within a priority is 
going to be requested as soon as this
goes into production.

Speaking of dependencies, wouldn't a
mechanism to declare dependencies a'la
make be more precise? Just a thought.



Casey Schaufler
casey@schaufler-ca.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: [PATCH 0/6] netfilter integration

[Joshua Brindle]

Casey Schaufler wrote:
> 
> --- "Christopher J. PeBenito" <cpebenito@tresys.com>
> wrote:
> 
>> This patchset adds support for netfilter secmark
>> rules in all policy
>> packages.  Each line of the file has a priority
>> (1-9) at the beginning
>> of the line, and the remainder is treated as the
>> rule.  Sorting is by
>> priority (1-9), and is stable within a module.  The
>> current design is
>> for the resultant netfilter_contexts file be
>> suitable for use with
>> iptables-restore.
> 
> How confident are you that 9 priorities
> will be sufficient? I can easily imaging
> dependency scenarios that would exceed
> this limitation. I would also expect that
> explict ordering within a priority is 
> going to be requested as soon as this
> goes into production.
> 
in reality probably 3 priorities would be sufficient. Specific port, 
port range and fallback. Its very doubtful that anything else would be 
necessary, especially in modules where the priority is much more 
important than in base. A module will very rarely have something more 
specific than ports, and since ports are non-overlapping it doesn't 
matter what order they are in (within a single priority)

> Speaking of dependencies, wouldn't a
> mechanism to declare dependencies a'la
> make be more precise? Just a thought.
> 
> 
eh? Policy modules already declare symbol dependencies explicitly (eg., 
which types, roles, etc this module uses)

--
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: [PATCH 0/6] netfilter integration

[Casey Schaufler]

--- Joshua Brindle <jbrindle@tresys.com> wrote:

> in reality probably 3 priorities would be
> sufficient. Specific port, 
> port range and fallback. Its very doubtful that
> anything else would be 
> necessary, especially in modules where the priority
> is much more 
> important than in base. A module will very rarely
> have something more 
> specific than ports, and since ports are
> non-overlapping it doesn't 
> matter what order they are in (within a single
> priority)

OKay.

> > Speaking of dependencies, wouldn't a
> > mechanism to declare dependencies a'la
> > make be more precise? Just a thought.
> > 
> > 
> eh? Policy modules already declare symbol
> dependencies explicitly (eg., 
> which types, roles, etc this module uses)

I was thinking it terms of explict ordering
of priorities rather than definition, but
it seems you have it well in hand.


Casey Schaufler
casey@schaufler-ca.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: [PATCH 0/6] netfilter integration

[Karl MacMillan]

On Mon, 2006-07-17 at 20:18 -0400, Joshua Brindle wrote:
> Casey Schaufler wrote:
> > 
> > --- "Christopher J. PeBenito" <cpebenito@tresys.com>
> > wrote:
> > 
> >> This patchset adds support for netfilter secmark
> >> rules in all policy
> >> packages.  Each line of the file has a priority
> >> (1-9) at the beginning
> >> of the line, and the remainder is treated as the
> >> rule.  Sorting is by
> >> priority (1-9), and is stable within a module.  The
> >> current design is
> >> for the resultant netfilter_contexts file be
> >> suitable for use with
> >> iptables-restore.
> > 
> > How confident are you that 9 priorities
> > will be sufficient? I can easily imaging
> > dependency scenarios that would exceed
> > this limitation. I would also expect that
> > explict ordering within a priority is 
> > going to be requested as soon as this
> > goes into production.
> > 
> in reality probably 3 priorities would be sufficient. Specific port, 
> port range and fallback. Its very doubtful that anything else would be 
> necessary, especially in modules where the priority is much more 
> important than in base. A module will very rarely have something more 
> specific than ports, and since ports are non-overlapping it doesn't 
> matter what order they are in (within a single priority)
> 

Then the 9 nine numbered port ranges are implying generality where there
isn't actually any. Why not just create those 3 priorities with _names_
to make the intent clear?

Karl

> > Speaking of dependencies, wouldn't a
> > mechanism to declare dependencies a'la
> > make be more precise? Just a thought.
> > 
> > 
> eh? Policy modules already declare symbol dependencies explicitly (eg., 
> which types, roles, etc this module uses)
> 
> --
> 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.
> 

--
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: [PATCH 0/6] netfilter integration

[Christopher J. PeBenito]

--
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: [PATCH 0/6] netfilter integration

[Casey Schaufler]

--- "Christopher J. PeBenito" <cpebenito@tresys.com>
wrote:


> I don't feel this is sufficient since you may want
> your module's rule to
> override a rules in the other modules, so you want a
> higher priority
> than what those have.  If, for example, you throw
> specific port ranges
> into a big bucket, then there's no way to do this. 
> In addition, you can
> create netfilter rules far more complicated than
> just a specific port or
> ranges.

That's the argument for generality and I
suggest that 9 ain't general. How many rules
are there in the policy now? You can go
with a small fixed number of priorities to
address the problem you have today, in
which case names make more sense, or you
can provide a general scheme in which case
9 is way too small.

Now, as far as inter-module priorities go,
numbers just don't make sense. What you
want is symbolic names and a way to say that
"HIGH" in module foo has a higher priority
than "HIGH" in module bar. You will never
get a rational numeric priority ranking
with multiple free thinking developers of
otherwise independent policy modules,
regardless of the granularity.


Casey Schaufler
casey@schaufler-ca.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: [PATCH 0/6] netfilter integration

[Christopher J. PeBenito]

On Tue, 2006-07-25 at 12:02 -0700, Casey Schaufler wrote:
> 
> --- "Christopher J. PeBenito" <cpebenito@tresys.com>
> wrote:
> 
> 
> > I don't feel this is sufficient since you may want
> > your module's rule to
> > override a rules in the other modules, so you want a
> > higher priority
> > than what those have.  If, for example, you throw
> > specific port ranges
> > into a big bucket, then there's no way to do this. 
> > In addition, you can
> > create netfilter rules far more complicated than
> > just a specific port or
> > ranges.
> 
> That's the argument for generality and I
> suggest that 9 ain't general. How many rules
> are there in the policy now?

432

> You can go
> with a small fixed number of priorities to
> address the problem you have today, in
> which case names make more sense, or you
> can provide a general scheme in which case
> 9 is way too small.
> 
> Now, as far as inter-module priorities go,
> numbers just don't make sense.

So after further discussion internally, we were thinking that there
likely not going to be intermodule dependencies.  Oracle netfilter
contexts aren't going to conflict with apache's.  Modules are going to
want to override the contexts in the base module.  

So we were thinking that we should do something similar to how other
parts of the policy are manged, with having base rules, module rules,
local rules, pre, and post rules.  The pre and post rules would be
special rules that have to come at the beginning or end of the
netfilter_contexts file (see the 1's and 9's in my original 0/6 email).
Then base would be low priority, module would be middle priority, and
local would be high priority.  Modules that are packaged with an app
should have the module priority.  The local priority would allow users
to use the infrastructure to create packages for their own use, for
example, for applying the rules to a network of machines (manually or
policy server in the future), which would be more convenient then
applying rules to iptables by hand on all the machines.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
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: [PATCH 0/6] netfilter integration

[Karl MacMillan]

On Wednesday 26 July 2006 10:23, Christopher J. PeBenito wrote:

<snip>

> So after further discussion internally, we were thinking that there
> likely not going to be intermodule dependencies.  Oracle netfilter
> contexts aren't going to conflict with apache's.  Modules are going to
> want to override the contexts in the base module.
>
> So we were thinking that we should do something similar to how other
> parts of the policy are manged, with having base rules, module rules,
> local rules, pre, and post rules.  The pre and post rules would be
> special rules that have to come at the beginning or end of the
> netfilter_contexts file (see the 1's and 9's in my original 0/6 email).
> Then base would be low priority, module would be middle priority, and
> local would be high priority.  Modules that are packaged with an app
> should have the module priority.  The local priority would allow users
> to use the infrastructure to create packages for their own use, for
> example, for applying the rules to a network of machines (manually or
> policy server in the future), which would be more convenient then
> applying rules to iptables by hand on all the machines.

This sounds much better to me.

Karl


--
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: [PATCH 0/6] netfilter integration

[Casey Schaufler]

--- "Christopher J. PeBenito" <cpebenito@tresys.com>
wrote:


> > Now, as far as inter-module priorities go,
> > numbers just don't make sense.
> 
> So after further discussion internally, we were
> thinking that there
> likely not going to be intermodule dependencies.

I don't believe that for a minute.
 
> Oracle netfilter
> contexts aren't going to conflict with apache's. 
> Modules are going to
> want to override the contexts in the base module.

Oracle may not conflict with apache, but what
about MySQL or, heaven forbid, earlier versions
of Oracle? You can bet on independent developers
in the same problem space developing conflicting
protection schemes.
  
> So we were thinking that we should do something
> similar to how other
> parts of the policy are manged, with having base
> rules, module rules,
> local rules, pre, and post rules.  The pre and post
> rules would be
> special rules that have to come at the beginning or
> end of the
> netfilter_contexts file (see the 1's and 9's in my
> original 0/6 email).
> Then base would be low priority, module would be
> middle priority, and
> local would be high priority.  Modules that are
> packaged with an app
> should have the module priority.

There will be conflicts. You need a scheme
for dealing with two modules at the same
"priority" with different rules.

> The local priority
> would allow users
> to use the infrastructure to create packages for
> their own use, for
> example, for applying the rules to a network of
> machines (manually or
> policy server in the future), which would be more
> convenient then
> applying rules to iptables by hand on all the
> machines.



Casey Schaufler
casey@schaufler-ca.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: [PATCH 0/6] netfilter integration

[Karl MacMillan]

Casey Schaufler wrote:
> --- "Christopher J. PeBenito" <cpebenito@tresys.com>
> wrote:
>
>
>   
>>> Now, as far as inter-module priorities go,
>>> numbers just don't make sense.
>>>       
>> So after further discussion internally, we were
>> thinking that there
>> likely not going to be intermodule dependencies.
>>     
>
> I don't believe that for a minute.
>  
>   

The current policies suggest otherwise - use the new semodule_deps tool 
if you don't believe me.

>> Oracle netfilter
>> contexts aren't going to conflict with apache's. 
>> Modules are going to
>> want to override the contexts in the base module.
>>     
>
> Oracle may not conflict with apache, but what
> about MySQL or, heaven forbid, earlier versions
> of Oracle? You can bet on independent developers
> in the same problem space developing conflicting
> protection schemes.
>   
>   

Local overrides allow an administrator choose when there are conflicts. 
What's the alternative?

>> So we were thinking that we should do something
>> similar to how other
>> parts of the policy are manged, with having base
>> rules, module rules,
>> local rules, pre, and post rules.  The pre and post
>> rules would be
>> special rules that have to come at the beginning or
>> end of the
>> netfilter_contexts file (see the 1's and 9's in my
>> original 0/6 email).
>> Then base would be low priority, module would be
>> middle priority, and
>> local would be high priority.  Modules that are
>> packaged with an app
>> should have the module priority.
>>     
>
> There will be conflicts. You need a scheme
> for dealing with two modules at the same
> "priority" with different rules.
>
>   

One set of rules will win based on ordering. Unfortunately there is no 
good way for the toolchain to make a choice here and allowing the 
administrator to override both modules seems like the best alternative 
to me.

Karl

>
>
> Casey Schaufler
> casey@schaufler-ca.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.