On Friday 24 July 2009 03:47:51 pm 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. Just because selinux has policy doesn't mean the app is installed. > 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. I don't like this. Its not tying to any port. For example, suppose there is a vulnerability in cups and apache is not running, the cups app could start listening on other ports and the rule would allow connections. > This does break in at least one way from traditional SELinux policy: > something external to SELinux is interpreting the meaning of the context. The kernel should always decide. Since this is a security mechanism that would be part of our Common Criteria work it would have to play by the rules. If its doing security enforcement, it will need to log AVCs. I would recommend leaving IPTables as is. Its working great at what its designed to do. -Steve -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list