netfilter integration

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.

--- "Christopher J. PeBenito" <[email protected]>

Quoted 11 lines · 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.

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)

Quoted 5 lines

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)

Quoted 16 lines · Casey Schaufler

--- "Christopher J. PeBenito" <[email protected]>

Quoted 11 lines · 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.

Quoted 8 lines

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)

Quoted 5 lines

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 [email protected] with the words "unsubscribe selinux" without quotes as the message.

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.

--- "Christopher J. PeBenito" <[email protected]>

Quoted 11 lines · 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.

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.

Quoted 2 lines

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.

--- "Christopher J. PeBenito" <[email protected]>

Quoted 3 lines · wrote:

Quoted 3 lines

Now, as far as inter-module priorities go,
numbers just don't make sense.

Quoted 4 lines

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.

Quoted 4 lines

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.

Quoted 7 lines

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

Quoted 9 lines

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.

Casey Schaufler
[email protected]