On 12/06/2010 08:15 PM, Jesse Keating wrote: > On 12/06/2010 11:05 AM, Daniel P. Berrange wrote: >> The other benefit would be if the user only intended the >> service to be accessible to localhost, or a UNIX domain >> socket but for some reason screwed up their service's >> config& opened it to the world. >> > > I could buy this if we actually alerted users to this, when in fact we > /disable/ logging in the default firewall set, so your packets just > magically disappear leaving the user scratching their head as to why > the hell things aren't working. > Thomas Woerner (iptables maintainer) is currently working on a prototype for basically the next generation of firewalling. He'll put up the code later this week with docu and all that shizzle as he just finished the first prototype of it a week ago. It's by far not complete yet, but it'll show enough of what you can do with it with some nice features and useful stuff. Basically it's a statefull firewall daemon now that allows us to support and implement a lot of those features which have been so critically missing in our old way of doing firewalls (aka static crap) and basically impossible to do there. One example is libvirt and how it has to change firewall rules dynamically depending on whether a guest is started or shut down, and those rules should survive a restart of the firewall (which currently they don't and can't). Roughly speaking it's a bit similar with the switch from our static initscripts for network configuration to NetworkManager and how it deals with network interfaces nowadays. A bit more initial info can already be found here: https://fedoraproject.org/wiki/SystemConfig/firewall but he'll send out a much more detailed description of what the new firewalld will be able to do and what problems we can solve with it. One thing is e.g notifications to users when some service/app requests to open a port. First version won't have network zones yet, but he and Dan Williams are working on that for the next generation which will then basically allow it to let the user decide once for each interface/connection what should happen with it and never be bothered with it afterwards. Thanks & regards, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Supervisor Core Services | Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch <pknirsch@xxxxxxxxxx> Hauptstaetterstr. 58 | Web: http://www.redhat.com/ D-70178 Stuttgart, Germany Motd: You're only jealous cos the little penguins are talking to me. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
