On Fri, 2009-07-24 at 14:00 -0700, Roland McGrath wrote: > > I don't think I explained it well. I was thinking what if you had this rule: > > > > -A INPUT -Z cups_t -j ACCEPT > > > > and then cups was compromised and started listening on port 80. Since the > > above rule has no port restrictions and cups is allowed to accept connections, > > would cups now be able to start serving web pages? > > I think the idea was that cups_t is a key into policy so that policy > expresses what this iptables rule means, not that the rule says "treat > whatever any cups_t process happens to be doing this way". > > At least, that's the good idea. ;-) from an iptables admin pov it would make more sense IMHO to have one of the following scenarios (not sure any of them would be "right" though): A) A table per context. iptables -A INPUT -Z -j SELINUX_cups_t then SELINUX_cups_t would be a special table that is read only and expresses the selinux policy for cups_t you could do iptables -L -v SELINUX_cups_t and get the list of ports allowed in this table. A.1) You can have a single table that list all input/output rules iptables -A INPUT -Z -j SELINUX_cups_t iptables -A OUTPUT -Z -j SELINUX_cups_t A.2) have 2 different tables: iptables -A INPUT -Z -j SELINUX_INPUT_cups_t iptables -A OUTPUT -Z -j SELINUX_OUTPUT_cups_t This syntax would be easy to use but it could become extremely verbose. B) Another option could be that you have instead only one rule in the main INPUT/OUTPUT tables: iptables -A INPUT -j SELINUX And in the SELINUX table (read only) list all the contexts rules, with -Z cups_t or -Z apache_t in ipatable -L -v -t SELINUX advertizing what context these rules applies to. This table may end up being quite long. Read/Write access to SELinux tables would be equivalent to modification of policy on the fly which would be at odd with the way SELinux is thought out IMO. Simo. -- Simo Sorce * Red Hat, Inc * New York -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list