[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Firewall rules using SELinux context (Was Re: RFE: FireKit)



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]