Re: secmark integration

[Karl MacMillan <kmacmillan@mentalrootkit.com>]

On Mon, 2007-03-19 at 10:57 -0400, James Morris wrote:
> Following some discussion of secmark integration at the developer summit, 
> one of the ideas proposed by Joshua (IIRC) was that it would be desirable 
> to have a separate table for managing the secmark rules.
> 
> This is technically possible (and we could also look at adding hooks for 
> the load_policy permission to be called for manipulating rules in this 
> table), but probably difficult to justify upstream: you should only do 
> something in the kernel if it can't be done in userspace.
> 
> I think we can make a good argument, though, based on it being for MAC 
> rules rather than DAC, in that the _type_ of security being managed is 
> fundamentally different, and that the table is likely being managed in 
> conjunction with SELinux policy.
> 
> Is there a consensus, particularly from distro folk, that having a 
> separate table would be of great benefit ?  I can post a rudimentary patch 
> soon, if needed.
> 

Is this really needed as long as the distro provides a way to customize
the iptables rules?

> Further issues that I heard mentioned:
> 
> a) Flush behavior is inverted: flush the iptables rules, and networking 
>    stops, as the packets are not labeled anymore.
>     - This can be managed if the security table is managed via some tool,
>       e.g. flip compat_net on with no compat rules, or implement a single 
>       rule to label all packets with some special bypass label.
> 

I think that updating the iptables scripts to flip a boolean that allows
unlabeled network traffic would work here.

> b) Confusing interactions with manual table management and various 3rd 
>    party tools.
>     - Firstly, we either use obvious chain names (e.g. 
>       '__SELINUX_AUTOGENERATED') to indicate to the admin that they 
>       shouldn't mess with them manually, or as suggested, use an entirely
>       separate table.
>     - How many distros have standard or blessed tools for managing the 
>       firewall?  Can we get secmark support integrated into these 
>       upstream?  I think if we architect this so that the heavy lifting is 
>       done via a library, the firewall tools can just call the 
>       appropriate API hooks as needed.

None?

>     - I think we need SELinux callouts in the iptables init script, as
>       save/restore/start/stop actions are now manipulating MAC security.  
>       Perhaps we completely separate SELinux control of tables so that the 
>       standard script doesn't touch them ?
> 
> c) User-customization of policy.
>     - I think we need to abstract this with a high level tool, starting 
>       with a common default, some common recipes and then increasingly 
>       low-level means to maintain modifications.
> 

At least initially, I think that it is fine for users to use whatever
means they would normally use to modify the secmark rules. Essentially
the workflow would be:

1) Disable default unlabeled_t network traffic for the daemon or in
general (presumably through a boolean).

2) Create a module with the types and rules that you need. Assuming a
global boolean, something like (Dan / Chris - comments about this are
needed):

type http_packet_t;

# Allow all daemons except apache to use unlabeled packets. We
# need a networkdaemon attribute or some type interface here.
allow { daemon -httpd_t } unlabeled_t : packet { send recv };

allow httpd_t http_packet_t : packet { send recv };

3) Create some secmark rules to mark http packets as http_packet_t.

With some documentation, I really don't think this is that hard. After
we experiment with this higher-level tools can be created.

> d) Some users do not want the iptables module loaded ?  (for how many 
>    people is this an issue ?) I wonder if they know that SELinux is 
>    already hooked into the netfilter framework.  We could try and convince 
>    them to allow it, and as a worst case, provide a switch to enable 
>    compat_net with no rules.
> 

Or presumably if they don't use iptables they won't care about secmark
either.

> e) Management and bundling of secmark rules with policy.
>     - Well, we already have separate policy with file_contexts, and
>       separate filesystem labeling and management mechanisms, integrated
>       widely into the system.
> 

Which is now turned off. I think that for many people the port binding
controls are enough. For the rest I think we should start with custom
secmark rules. The generated rules from policy are too restrictive and
too hard to customize. The whole goal was to allow people to use
iptables to classify their network traffic - forcing that labeling into
the policy destroys that flexibility. So keeping them separate is, I
think, the right answer.

> As far as management of the rules goes, the vast majority of packets will 
> be 'related' to an existing connection, and this should be the first rule, 
> which causes an immediate jump out of the table.  The next most common 
> will be SYN packets for the most common services on the system (e.g. to 
> port 80), and rules for these services should be ordered appropriately to 
> minimize the amount of table traversal.  This could even be monitored by 
> the admin tool and allow the admin to order the rules based on how often 
> they're hit.
> 
> We can also follow the targeted policy model, where only targeted domains 
> have rules requiring packets with specific labels.
> 

See above - I think that custom rules are sufficient.

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.