From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from jazzhorn.ncsc.mil (mummy.ncsc.mil [144.51.88.129]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with SMTP id l2JEvng5028574 for ; Mon, 19 Mar 2007 10:57:49 -0400 Received: from mail1.sea5.speakeasy.net (jazzhorn.ncsc.mil [144.51.5.9]) by jazzhorn.ncsc.mil (8.12.10/8.12.10) with ESMTP id l2JEvk3K007324 for ; Mon, 19 Mar 2007 14:57:47 GMT Received: from dsl092-066-197.bos1.dsl.speakeasy.net (HELO d.namei) ([66.92.66.197]) (envelope-sender ) by mail1.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 19 Mar 2007 14:57:45 -0000 Date: Mon, 19 Mar 2007 10:57:44 -0400 (EDT) From: James Morris To: selinux@tycho.nsa.gov cc: Joshua Brindle , Daniel J Walsh Subject: secmark integration Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov 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. 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. 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. - 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. 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. 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. 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. Comments? What other issues need to be resolved for this ? - James -- James Morris -- 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.