* James Morris <[EMAIL PROTECTED]> [2006-05-14 08:03]: > Included below is an incremental patch against the initial secmark posting > last week: http://thread.gmane.org/gmane.linux.network/34927/focus=34927 > > This posting to gather feedback on changes made since then primarily to > address concerns raised by Karl MacMillan on providing fine-grained > assurances for network applications which pass connections (e.g. xinetd). > > If all looks ok, I'll rebase the entire patchset (also merging elements > from the patch below back into other patches), and submit it for inclusion > in 2.6.18. As it touches a bunch of networking code, it may be best to > aim for Dave's tree, although it could also go into -mm. > > Anyway, the way the issue has been addressed is to implement something > similar to CONNMARK, but specific to this useage scenario and dealing with > security markings instead of network markings. > > In a nutshell: > > 1. A --track option was added to the SECMARK target, which causes the > security mark being applied to the packet to also be applied to a new > secmark field on the conntrack (only if it is unmarked). > > 2. A new CONNSECMARK target was added which copies the secmark value to > packets. > > This allows all packets on a connection (or related to it) to be marked > with the same security label, so that they can be explicitly > differentiated. > > This also turns out to simplify the SELinux policy, while the xtables > implementation has been designed to remain as simple as possible (e.g. it > only copies lables to packets, and has no options). > > So, here's an example of per-packet network policy for vsftpd with the new > code: > > allow ftpd_t ftpd_packet_t:packet { recv send }; > > Assuming it doesn't do DNS lookups, that's it in terms of access control > rules for packets. This covers all established and related packets, > including ICMP and the FTP data connetion. > > (see the full policy at > http://people.redhat.com/jmorris/selinux/secmark/policy/ftpd_tracked/ftpd_tracked.te) > > In terms of iptables rules, the only real change is that we need to add > CONNSECMARK rules for all incoming and outgoing packets (assuming you want > this for all services, otherwise, use iptables selectors to apply > CONNSECMARK on a per-service basis). Here's an example for the above: > > # > # Accept incoming connections, label SYN packets, and copy > # labels to connections. > # > $IPT -A SEL_INPUT -p tcp --dport 21 -m state --state NEW -j SEL_FTPD > $IPT -A SEL_FTPD -j SECMARK --selctx system_u:object_r:ftpd_packet_t:s0 > --track > $IPT -A SEL_FTPD -j ACCEPT
This all looks very nice - Thank You! Just one question: does the code canonicalize the security label? It would be nice if the same rules could be used on MLS and non-MLS systems. Thomas > > # > # Copy connection labels to established and related packets. > # > $IPT -A SEL_INPUT -m state --state ESTABLISHED,RELATED -j CONNSECMARK > $IPT -A SEL_OUTPUT -m state --state ESTABLISHED,RELATED -j CONNSECMARK > > > It should be easy to modularize the iptables rules and distribute them > with policy modules, and I'd recommend always generating them with some > script or macro. > > Everything needed to get this running (including iptables patches) is at: > http://people.redhat.com/jmorris/selinux/secmark/ > > I've also added a patch at the site which adds a kernel boot param to > determine whether to use the old or new packet controls, although I'm > still not sure whether it's justified adding this stuff to the kernel when > it can be set at runtime during early boot. > > Please review and let me know if there any further issues. [Code snipped]
signature.asc
Description: Digital signature
