I think I found a solution, inspired by reading two very good articles by James Morris (article here - http://james-morris.livejournal.com/11010.html) and Paul Moore (article here - http://paulmoore.livejournal.com/4281.html). Both are members of this list, so if they read this thread I welcome their comments. Both articles refer to an elegant solution for my problems by using SECMARK (which is supported by both the new kernels and SELinux) - using iptables to mark the packets I am interested in with a specific security context (using the --selctx iptables option), and then using my SELinux policy to control/manipulate access to this context by using the (new) 'packet' class permissions. With this approach I will have more fine-grained control over what goes where and that will also allow me to use more than one net interface to enforce control within the same policy - exactly what I wanted. As the articles were about 4 years old I am not sure whether there is something better out there, but this will do for the time being. I've had a little snag, however! As an experiment, I tried to mark packets using iptables, but my attempt failed - miserably so! I executed this: iptables -t mangle -A INPUT -p tcp --dst 127.0.0.1 --dport 3306 -j SECMARK --selctx system_u:object_r:mysqld_t:s0 Error message received: "iptables: Invalid argument. Run `dmesg' for more information.". dmesg reveals: "SECMARK: unable to obtain relabeling permission" (note the wrong speLLing!), which then led me to my avc: type=AVC msg=audit(1283619145.372:45): avc: denied { relabelto } for pid=1846 comm="iptables" scontext=unconfined_u:unconfined_r:iptables_t:s0-s0:c0.c1023 tcontext=system_u:object_r:mysqld_t:s0 tclass=packet type=SYSCALL msg=audit(1283619145.372:45): arch=40000003 syscall=102 success=no exit=-22 a0=e a1=bfb86510 a2=cf392c a3=cf15e4 items=0 ppid=1512 pid=1846 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="iptables" exe="/sbin/iptables-multi" subj=unconfined_u:unconfined_r:iptables_t:s0-s0:c0.c1023 key=(null) I quickly examined iptables.te and there is a macro 'relabelto_all_packets(iptables_t)', which, in essence, translates to 'allow iptables_t packet_type:packet relabelto;' On the face of it, I can't see why I should get the above avc as the domain in both cases is 'iptables_t'?! Any suggestions? One additional inconvenience is that I am using Shorewall, which, from what I can gather, does not support SECMARK and CONSECMARK and I have to execute iptables directly to do what I want - not very nice and that would be a matter for the Shorewall support forum. -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
