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

Matthew Woehlke mw_triad at users.sourceforge.net
Fri Jul 24 20:29:34 UTC 2009


'Content-Type: format=flowed' would be really nice, as opposed to the 
'one line per paragraph' you sent...

Casey Dahlin wrote:
> A couple of mentions of SELinux have cropped up in the FireKit 
> thread, which got me thinking about the Firewall and SELinux and ways
> in which they are similar. I had the following thought:
> 
> SELinux already has a lot of policy information from which we might 
> like to determine whether ports should be open to a particular
> program. The simplest mechanism I can see for doing that is to allow
> SELinux context to be referenced in the firewall rules. This prevents
> either system from having to be grotesquely modified.
> 
> An example rule might look like this:
> 
> -A INPUT -Z apache_t -j ACCEPT
> 
> Here we tell the firewall to allow incoming traffic that will be
> intercepted in userspace by a process in the apache_t context.

My question is, can this even work? There is a reason I suggested that 
on the /INPUT/ side, iptables have no more smarts than 'is there a 
socket that will accept this packet'. (Then use SELinux to allow/prevent 
those sockets from being opened in the first place.)

I like the idea for the OUTPUT chain, however.

> This does break in at least one way from traditional SELinux policy: 
> something external to SELinux is interpreting the meaning of the 
> context. The firewall rules can change while the actual SELinux
> policy stays put. I don't know how serious a problem that is (if it
> is one).

I think this makes sense. You may want the rules for $DAEMON to change 
based on network connectivity, or even intangible parameters (e.g. "I 
just called IT and they asked for ssh access, I want to enable it but 
only for the next five minutes"). This seems easier to express in 
iptables than changing the SELinux context to cope with such events. 
Especially since the SELinux context in this case really becomes more of 
a tag than a rule set; the user determines the rules.

That said, I'm not familiar with SECMARK, so it's hard to say if it can 
accomplish the same things. (It does, however, seem to be backwards 
w.r.t. how you want rules to be defined. Can I use SECMARK to e.g. allow 
Konqueror to browse YouTube, but block Firefox?)

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
"unsubscribe me plz!!" -- Newbies




More information about the devel mailing list