Re: Firewall rules using SELinux context (Was Re: RFE: FireKit)
On Mon, 27 Jul 2009, Daniel J Walsh wrote: > This is all fascinating conversation. But the question still arises, > why can't anyone use SECMARK/IPTABLES rules on a Targeted policy system. > My opinion is that it is still too difficult. Well, it's taken years to get all the basic technology into place (including CIPSO and Labeled IPSec), and no work at all has gone into usability as yet. I envisage providing high-level abstractions in one of two ways: a) Building network labeling into a project as a standard configurable aspect of that (e.g. virtualized secure networking for VM to VM communication), which is integrated into and managed by the existing management tool, like we have with sVirt. No policy knowledge is required, just how to use e.g. virt-manager to configure sharing via the network. b) Network design tools which let you visually design and manage protected communications paths between processes on different machines, e.g. for managing your DMZ. This would generate policy and distribute it to systems on the network & really be something for advanced users, but domain-specific i.e. thinking in terms of network security vs. SELinux policy. Note that there was never any intention for people to have to know the low-level SELinux policy (as far as I recall). The high-level abstractions we're building with kiosk mode, svirt, sandbox etc. are some glimpses into where things are headed now that we have most of the base technology in place. - James -- James Morris -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Firewall rules using SELinux context (Was Re: RFE: FireKit)
On 07/27/2009 04:23 AM, Glen Turner wrote: > On 25/07/09 07:14, Simo Sorce wrote: > >> What's the value of labeling packets based on source/destination ports ? >> Doesn't seem to add any new information. > > Indeed. > > Security marking can add an additional IP header, so that a multilevel > operating system on one machine can pass those multiple levels of data > across an intervening network. > This is all fascinating conversation. But the question still arises, why can't anyone use SECMARK/IPTABLES rules on a Targeted policy system. My opinion is that it is still too difficult. The rules for name_connect, name_bind, prevent SELinux domains from connecting or listening on random ports, and that seems to work fairly well. But if you want to configure SELinux to only allow httpd_t to listen on eth0 or only to connect to host mysql.redhat.com you had better invest in some SELinux courses. I would have no idea how to get that right. This is the problem. Maybe the tools are all present but you need a masters in SELinux policy to write these rules, which most admin can state fairly easily with iptables rules, using the -Z Currently SELinux policy has to allow all domains to listen to the unlabeled_t packets, so changing apache_t to listen to only apache_packet_t is a major change in policy. How does an admin do this, Not a policy writer. If the admin needs to write a single TE rule, we fail. And sadly usability of SECMARK/NetworkLabaling has failed Targeted policy. I have said for two years I would like to allow apache to connect on localhost to port 80, but no other connections. httpd also needs to be able to listen on all apache ports on all network devices and send packets back and forth. If the iptables rules get removed the apache has to be removed to allow httpd_t has to become more permissive, it can not break because packets are no longer labeled. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Firewall rules using SELinux context (Was Re: RFE: FireKit)
On 07/24/2009 04:55 PM, Steve Grubb 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? > > -Steve That would be a bad rule. The Apache example I posted only makes sense because Apache can be listening on pretty much any port anyway (every http deployment I see is stranger than the last). For cups it is a lot rarer for an admin to configure a strange port, so we'd want to combine -Z with further rules like port and host restrictions. --CJD -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Firewall rules using SELinux context (Was Re: RFE: FireKit)
On 25/07/09 07:14, Simo Sorce wrote: What's the value of labeling packets based on source/destination ports ? Doesn't seem to add any new information. Indeed. Security marking can add an additional IP header, so that a multilevel operating system on one machine can pass those multiple levels of data across an intervening network. -- Glen Turner -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Firewall rules using SELinux context (Was Re: RFE: FireKit)
On Fri, Jul 24, 2009 at 14:49:08 -0700, Roland McGrath wrote: > SECMARK. I sure didn't. I think I might now, sort of. The SELinux policy > just says contexts, and it doesn't say anything about the port numbers. If you really just want to use local ports, that is available in selinux policy. I don't know if it only applies to listen, but there are port restrictions for some apps. The SEMARK stuff is supposed to allow you to have more complicated (maybe stateful) rules for labelling packets. Besides that there is also a way to have labels in the packets themselves so that you can use labelling accross a network. I don't know if Fedora supports any of that, but at least some of the needed infrastructure is already in the upstream kernel. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Firewall rules using SELinux context (Was Re: RFE: FireKit)
Le vendredi 24 juillet 2009 à 19:22 -0400, Gregory Maxwell a écrit : > Not just port numbers. Well iptables already allows stuff like -A OUTPUT -m owner ! --gid-owner apache -p tcp --dport http -j REDIRECT --to-port tproxy so you don't have to open ports for every process -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Firewall rules using SELinux context (Was Re: RFE: FireKit)
On Fri, Jul 24, 2009 at 18:08:55 -0400, Simo Sorce wrote: > On Fri, 2009-07-24 at 17:44 -0400, Simo Sorce wrote: > > > > now if you allow to apply application labels to packets then you could > > say that packets directed to 8080 are labeled squid_t and not apache_t > > and that would make quite a difference. > > > > It would prevent a rogue apache that gets to listen to 8080 to get any > > packet as they would be labeled squid_t which is not apache_t. > > Sorry Bruno, > after re-readying what you said I think we meant basically the same > thing. The above is how I think the feature is supposed to work. I haven't actually tried it though. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Firewall rules using SELinux context (Was Re: RFE: FireKit)
On Fri, Jul 24, 2009 at 5:49 PM, Roland McGrath wrote: > So I think most of us in this discussion probably don't actually understand > SECMARK. I sure didn't. I think I might now, sort of. The SELinux policy > just says contexts, and it doesn't say anything about the port numbers. > The point of SECMARK is that you write port-matching rules that are what > sets the context on those packets. You have to write those rules by hand > (or somehow) or else there just aren't ever any packets anywhere that are > marked with the right context so they match the SELinux policy for what the > given daemon is allowed to see. > > So I think what one really wants is just a better level of admin/packaging > coordination. That is, you would really like to write in one place both > the SELinux policy and the port numbers (i.e. iptables matching rules) you [snip] Not just port numbers. For example. I might want to confine CUPS to only speak to localhost and 192.168.1.1/32; 192.168.10.1/32; 192.168.15.3/32, so that if something running as cups_t is compromised it can only talk to my print servers and not phone home or get messages from an external botnet controller. I think SECMARK can do this, but I think that it would require me to change the SE linux policy to only allow cups_t to touch cups marked packets. I think this would be much easier to administer as pure firewall rules, i.e. -S 192.168.1.1/32 --dctx cups_t -j ACCEPT ... --dctx cups_t -j REJECT --sctx cups_t -D 192.168.1.1/32 -j ACCEPT --sctx cups_t -j REJECT As far as I can tell the only way to get the same general behavior from SECMARK is it to make the SELINUX policy require the marking then have a bunch of marking rules. Then your apps break if the firewall is not activated. I consider this a bootstrapping problem. I'm also not sure how you could achieve multiple contexts being permitted to access a particular set of traffic using secmark nor can I figure out how you could accomplish the output side. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Firewall rules using SELinux context (Was Re: RFE: FireKit)
On Fri, 2009-07-24 at 17:44 -0400, Simo Sorce wrote: > On Fri, 2009-07-24 at 16:21 -0500, Bruno Wolff III wrote: > > I thought the idea was to label packets based on source and > > destination > > (including ports) not application. Applications would get access to > > the > > packets based on their context and the context (labels) of the > > packets. > > I may have misunderstood though. > > What's the value of labeling packets based on source/destination ports ? > Doesn't seem to add any new information. > > If I get a packet for port 8080 it's always going to whatever > application is listen on port 8080, unless you label the packet with an > application context SElinux does not have any more information. > > now if you allow to apply application labels to packets then you could > say that packets directed to 8080 are labeled squid_t and not apache_t > and that would make quite a difference. > > It would prevent a rogue apache that gets to listen to 8080 to get any > packet as they would be labeled squid_t which is not apache_t. Sorry Bruno, after re-readying what you said I think we meant basically the same thing. Simo. -- Simo Sorce * Red Hat, Inc * New York -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Firewall rules using SELinux context (Was Re: RFE: FireKit)
So I think most of us in this discussion probably don't actually understand SECMARK. I sure didn't. I think I might now, sort of. The SELinux policy just says contexts, and it doesn't say anything about the port numbers. The point of SECMARK is that you write port-matching rules that are what sets the context on those packets. You have to write those rules by hand (or somehow) or else there just aren't ever any packets anywhere that are marked with the right context so they match the SELinux policy for what the given daemon is allowed to see. So I think what one really wants is just a better level of admin/packaging coordination. That is, you would really like to write in one place both the SELinux policy and the port numbers (i.e. iptables matching rules) you want to associate with contexts. Then you want that to generate iptables rules that both allow packets and mark them, and you want those sets of rules to come along the daemon's installation or something like that such that it is easy to say "enable this daemon" and get correct iptables rules configured on your system. All that said, I probably still missed some major point about how SECMARK actually works. I have no idea. Thanks, Roland -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Firewall rules using SELinux context (Was Re: RFE: FireKit)
On Fri, 2009-07-24 at 16:21 -0500, Bruno Wolff III wrote: > I thought the idea was to label packets based on source and > destination > (including ports) not application. Applications would get access to > the > packets based on their context and the context (labels) of the > packets. > I may have misunderstood though. What's the value of labeling packets based on source/destination ports ? Doesn't seem to add any new information. If I get a packet for port 8080 it's always going to whatever application is listen on port 8080, unless you label the packet with an application context SElinux does not have any more information. now if you allow to apply application labels to packets then you could say that packets directed to 8080 are labeled squid_t and not apache_t and that would make quite a difference. It would prevent a rogue apache that gets to listen to 8080 to get any packet as they would be labeled squid_t which is not apache_t. Simo. -- Simo Sorce * Red Hat, Inc * New York -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
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 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Firewall rules using SELinux context (Was Re: RFE: FireKit)
On Fri, Jul 24, 2009 at 16:55:23 -0400, Steve Grubb 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 thought the idea was to label packets based on source and destination (including ports) not application. Applications would get access to the packets based on their context and the context (labels) of the packets. I may have misunderstood though. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Firewall rules using SELinux context (Was Re: RFE: FireKit)
> 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. ;-) Thanks, Roland -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Firewall rules using SELinux context (Was Re: RFE: FireKit)
On Friday 24 July 2009 04:56:51 pm Casey Dahlin wrote: > > Just because selinux has policy doesn't mean the app is installed. > > If the app is not installed nothing is running in its context, so none of > the rules will ever trigger. If the attacker can work out the chain of allowed transitions, they can enter that context. > >> 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. > > Only if cups were running in the apache_t context. 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? -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Firewall rules using SELinux context (Was Re: RFE: FireKit)
On 07/24/2009 04:44 PM, Steve Grubb wrote: > 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. > If the app is not installed nothing is running in its context, so none of the rules will ever trigger. > >> 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. > Only if cups were running in the apache_t context. You seem to not quite be getting what I'm saying. What is it you expect that rule /does/ accomplish if not prevent the situation you describe? --CJD -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Firewall rules using SELinux context (Was Re: RFE: FireKit)
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@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Firewall rules using SELinux context (Was Re: RFE: FireKit)
It sounds like something that looks at an SELinux policy's rules for SECMARK and generates corresponding iptables rules would amount to the same thing you have in mind. Since you load new SELinux policy in a big static-switch sort of way, it doesn't seem much different in a way you could discern whether you actually have the firewall driven off the AVC stuff "dynamically" or if you just "statically" generate a set of firewall rules based on SELinux policy. I suppose you could just integrate this into iptables userland so that the "-Z" syntax you suggested would just look up current SELinux policy for everything with that label and generate corresponding rules, though you might want those rules marked somehow so that that a policy reload automagically regenerated them. OTOH, it seems fine enough to me to just leave that in scriptland, so "service iptables reload" recomputes from the current SELinux policy, and maybe the normal ways to install a policy change do that automatically. Perhaps the difference is that you have the firewall ports open even when nothing running has those ports bound. Actually, I'm not sure if that wouldn't have been true with what you suggested anyway. A lax SELinux policy might be allowing anyone to bind to the SECMARK labels for those ports, not just the daemon you have in mind. (i.e. the targeted policy uses SECMARK to constrain that daemon to binding only those particular ports, but doesn't prevent random unconstrained_t processes from binding them.) Thanks, Roland -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Firewall rules using SELinux context (Was Re: RFE: FireKit)
'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 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Firewall rules using SELinux context (Was Re: RFE: FireKit)
On 07/24/2009 03:53 PM, Stephen Smalley wrote: > On Fri, 2009-07-24 at 15:47 -0400, 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. >> >> 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). >> >> Thoughts? > > SECMARK already allows you to label packets using iptables and then use > SELinux policy to control sending or receiving them. > > http://paulmoore.livejournal.com/4281.html > > There are also the name_connect and name_bind controls that regulate the > ability to connect or bind to specific ports via policy. > This is a very different mechanism. The idea behind my proposal is it allows a packet to be routed based on who is going to receive it. SECMARK, it seems, is designed to control who receives a packet based on how it is being routed. I don't know if you get the same effect this way. --CJD -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Firewall rules using SELinux context (Was Re: RFE: FireKit)
On Fri, 2009-07-24 at 15:47 -0400, 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. > > 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). > > Thoughts? SECMARK already allows you to label packets using iptables and then use SELinux policy to control sending or receiving them. http://paulmoore.livejournal.com/4281.html There are also the name_connect and name_bind controls that regulate the ability to connect or bind to specific ports via policy. -- Stephen Smalley National Security Agency -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Firewall rules using SELinux context (Was Re: RFE: FireKit)
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. 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). Thoughts? --CJD -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
