No Xfce LIve iso in RC 1.2
Hello, there is no Xfce live iso in RC-1.2: https://dl.fedoraproject.org/pub/alt/stage/29_RC-1.2/Spins/x86_64/iso/ It has been available in beta-1.5: https://dl.fedoraproject.org/pub/alt/stage/29_Beta-1.5/Spins/x86_64/iso/Fedora-Xfce-Live-x86_64-29_Beta-1.5.iso It is also available in rawhide: https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Spins/x86_64/iso/Fedora-Xfce-Live-x86_64-Rawhide-20181025.n.0.iso The LXQT live iso is also missing in RC-1.2. Regards, Thomas ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
firewalld transaction model
Hello, the transaction model that has been introduced with firewalld-0.4.2 makes it possible to group rules together and to apply them at once and quick. For this the restore commands of iptables, ip6tables and ebtables are used as long as they are available. At the moment the transaction model is only used inside of firewalld. It applies all the generated and provided rules in a small amount of transactions. This speeds up load and reload times of firewalld drastically. There is no external interface to add transaction by services or applications right now. Because of this I'd like to get feedback from the D-Bus interface and command line consumers: Is there interest in using transactions at all? What are the needs and wishes? With this information it should then be possible to get to a good and stable interface. This will most likely an iterative process with some test and proof of concept implementations. Please provide information about your needs and wishes. Regards, Thomas -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: iproute package split
Hello, On 03/22/2016 09:47 PM, Zbigniew Jędrzejewski-Szmek wrote: On Tue, Mar 22, 2016 at 06:01:14PM +0100, Phil Sutter wrote: Hi, I am in the process of splitting the 'tc' utility off from iproute package. The motivation for this comes from two things: 1) Due to it's xt/ipt action, tc depends on iptables. 2) iproute is part of the 'Core' group. These two in combination lead to iptables being pulled into Core as a dependency although not strictly necessary - tc is not necessary for basic system functionality and ip itself works fine without. iptables is also pulled in by systemd (at least), so this is not enough to get it out of core. The reason for this split is not to get iptables out of core, but to have a good way to build new iptables versions with libxtables so bumps. iproute2 is part of the build environment and depends on libxtables. With the split only the tc sub package will depend on iptables. With a libxtables so bump it is either needed to also build iproute2 at the same time as iptables or to have a (temporary) libxtables provide for the old so version. This is also an issue if a customer or user needs to build a newer iptables version on his system. There is no simple upgrade path for the most common case. So far I added a new 'tc' subpackage to iproute.spec which will contain tc, all related binaries and configs and relevant man pages. This package depends on a version of iproute which is greater than the last release before the split, which should prevent conflicts when updating. For user convenience though, I would appreciate if an iproute package update from a pre-split version would automatically pull the tc subpackage as well. Is this possible without adding a dependency from 'iproute' to 'iproute-tc' (which would defeat the purpose, of course)? You can use Obsoletes to achieve this. systemd went through a similar split recently, see http://pkgs.fedoraproject.org/cgit/rpms/systemd.git/commit/?h=f24=34bfceffe6cb26f5b5a9bdc5ab9c071eeb40f1c9 Zbyszek -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org Regards, Thomas -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: [ACTION REQUIRED] FTBFS Packages in rawhide (2015-07-13)
On 07/14/2015 12:40 AM, opensou...@till.name wrote: prelink jakub, mjw60 weeks ago ... twoerner: prelink There seems to be a bug in your script ... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Workstation Product defaults to wide-open firewall
On 12/09/2014 03:57 PM, Christian Schaller wrote: - Original Message - From: Brian Wheeler bdwhe...@indiana.edu To: devel@lists.fedoraproject.org Sent: Tuesday, December 9, 2014 9:18:47 AM Subject: Re: Workstation Product defaults to wide-open firewall On 12/09/2014 08:50 AM, Richard Hughes wrote: On 9 December 2014 at 13:39, Michael Catanzaro mcatanz...@gnome.org wrote: So your challenge is to find an alternative default that supports it. I'd go even further. I don't think the people writing the vast number of lengthy posts on this thread actually want to *use* workstation, with the possible exception of Bastien who's having to defend something he shouldn't have to. Reindl probably should just use the server spin, or be prepared to actually configure his box to do what he wants to be 100% paranoid and unusable for anything less than a technical user. If you don't like what workstation has decided to do, use another target, or a different distro entirely (like CentOS). If you want to change how workstation is designed, join the working group and please actually talk to people there. I think it's misguided to think that hurling insults here is going to achieve change. I think a lot of people also need to remember that workstation isn't built for them, and that's okay. If you know how to configure iptables then that's fine, but I'm happy to admit I don't, and normally just switch off the firewall entirely so I can get stuff done. F21 will be more secure for me, not less. Ok, so what product/spin am I supposed to use? I'm a RHEL sysadmin but I use Fedora on my desktop laptop. I expect the firewall to be on so when I evaluate a new piece of software or do a bit of network development I don't inadvertently increase my exposure. I also expect things to work with the minimum amount of fuss. So it looks like my choices boil down to: * Use the workstation project and spend a bunch of time locking it down to what would be reasonable default for the networks I use -- and hope I don't miss anything. Well I think it is hard for anyone to guess what would be reasonable defaults for you specifically, any default is by its nature just targeting an generic person, which might or might not be a lot like you. But if you are aware and understand the finer details here then it isn't that big a job to change it, you should be able to go into the network manager, choose your connection, choose 'identity' (should probably be moved to be under security?) and change the zone for your network to whatever suits you better. Please change the default zone, otherwise any new connection will get assigned to the weak zone again in the first place. firewall-cmd --set-default-zone=public This will change the default to public. All connections that are not explicitly bound to another zone will be automatically assigned to the default zone. Thomas Christian * Use the server product and manually configure all of the workstation stuff so I get a usable system Neither of those choices seem reasonable to me, especially compared to the status quo: a fully configured workstation where I open new ports as I increase functionality. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Workstation Product defaults to wide-open firewall
On 12/08/2014 12:51 PM, Bastien Nocera wrote: - Original Message - Am 08.12.2014 um 12:34 schrieb Bastien Nocera: Am 08.12.2014 um 11:45 schrieb Bastien Nocera: Well, I'll understand these aspects. But when I think about Linux, especially about Fedora, I'm thinking about the freedom to make decisions. This means to me, to customize and take advantage of my computer and in this case my operating system. You're free to select another firewall zone so why do you not make secure defaults and say You're free to select another (more unsecure) firewall zone? 1) It is secure enough and Eclipse listening to a port by default is a bug (and I have the firewall specialists at Red Hat/Fedora to back me up) I have Eclipse open and it's not listening to a port AFAIKT. I wonder what obscure plugin is installed in Eclipse to make this happen. Thanks for following up Aleksandar. Hopefully Reindl will let us know about that so the bug can be fixed. * first: it is not a Fedora package * second: it does not matter fixing applications to work around harmful firewall settings is the wrong direction - the *purpose* of a firewall is to *protect* against such things and i really don't get why this needs to be explained multiple times Security is about compromises. The net result of the old firewall settings was people disabling the firewall. The new firewall settings were vouched for by the firewalld folks, and provide good defaults for most users. This is wrong and you know about that - the firewalld folks have been urged to use this zone for the Workstation product - it was a Workstation team decision. that's the same as drive a car on the street, facing another driver ignoring his red light and instead try to stop your car just say he is wrong and i am allowed to drive a sensible reaction would be stop, call the others names and live the ignorant reaction would be get killed but be right at it I can't parse that, sorry. Looks like a strawman. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Workstation Product defaults to wide-open firewall
On 12/08/2014 10:50 AM, Bastien Nocera wrote: - Original Message - -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 We don't need open or preconfigured high ports. What we really need is a user notification with options to allow or deny like we do with SELinux. That would be a appropriate solution for a workstation. No it wouldn't be, because users don't like being asked security questions, even less so when they don't have the skills to understand the consequences of their choices. The changes were vouched for by the Fedora and GNOME designers, as well as the firewalld maintainers. This zone was not proposed by firewalld maintainers. We had to accept this zone - it was the Workstation team decision. Additionally there was a request to pin down the zone in Workstation that the user would not be able to change zones. But we denied this request, because it would have been a big code change in firewalld to remove one of its key features. Additionally firewall-applet and firewall-config are not installed by default in Gnome. All this was the decision of the Workstation team. I asked then to leave the firewall UI there, but ... Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Workstation Product defaults to wide-open firewall
On 12/08/2014 03:12 PM, Bastien Nocera wrote: - Original Message - On 12/08/2014 12:51 PM, Bastien Nocera wrote: snip This is wrong and you know about that - the firewalld folks have been urged to use this zone for the Workstation product - it was a Workstation team decision. What?! We discussed it, and it was deemed acceptable by you, and mitr. We went back and forth on this, and you agreed that it was a good cost/benefit decision. We could choose between removing firewalld and accepting this zone ... Feel free to make the discussion public if you feel that I misrepresented your POV. I'm pretty certain that it was deemed a good change, whether you remember it that way or not. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Workstation Product defaults to wide-open firewall
On 12/08/2014 03:45 PM, Bastien Nocera wrote: - Original Message - On 12/08/2014 03:12 PM, Bastien Nocera wrote: - Original Message - On 12/08/2014 12:51 PM, Bastien Nocera wrote: snip This is wrong and you know about that - the firewalld folks have been urged to use this zone for the Workstation product - it was a Workstation team decision. What?! We discussed it, and it was deemed acceptable by you, and mitr. We went back and forth on this, and you agreed that it was a good cost/benefit decision. We could choose between removing firewalld and accepting this zone ... Which you could have refused if you felt that it was an unacceptable compromise. Which you didn't do. Are you still going to argue that this wasn't _vouched_ for by you and the other firewall stakeholders? Yes, exactly in the same way as I could say no to the removal of all firewall UI tools ... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: defining firewalld services
On 07/08/2014 01:20 AM, Ian Pilcher wrote: On 07/07/2014 12:03 PM, Thomas Woerner wrote: On 07/07/2014 02:55 PM, Stephen Gallagher wrote: Thomas, the real question here is this: If a package wants to install (and maintain) its own set of firewalld service definitions, is the approach Stef took the best one? If so, we should submit a Packaging Guidelines edit to the FPC and get this codified where others can find it. Yes, this is the best approach right now. Hmm. If I've made a temporary change to my firewall settings, I might be a bit annoyed if an (apparently unrelated) package installation caused the configuration to revert to the permanent configuration. Is there not a more specific command that adds the service definition to the current environment without a full reload? No, there is no command for this. Changes to (also addition and removal of) services are done in the permanent environment only to have a consistent state in the runtime environment. I have done this because the adoption of changes to zone, services etc. might lead into problems. Please think of these examples: - A service definition has been removed. - A service definition has been changed in an incompatible way: Different port number or range. The adoption of a changed port number for a service should be done in the service and in firewalld at the same time. There is no interface for this. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: defining firewalld services
On 07/07/2014 02:55 PM, Stephen Gallagher wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/04/2014 07:36 AM, Thomas Woerner wrote:
On 07/03/2014 09:32 PM, Stef Walter wrote:
On 03.07.2014 15:39, Rex Dieter wrote:
I'm looking into providing a predefined firewalld service
definition for kde-connect, per
https://bugzilla.redhat.com/show_bug.cgi?id=1115547
Looks like it's as easy as dropping an xml snippet into
/usr/lib/firewalld/services/
I'm also noticing currently that the only package besides
fallwalld itself doing this is cockpit, which includes a %post
scriptlet:
# firewalld only partially picks up changes to its services
files # without this test -f %{_bindir}/firewall-cmd
firewall-cmd --reload --quiet || true
Is this the recommended approach? If so, I'll follow this
lead, and maybe start work on drafting some packaging
guidelines.
Thomas Woerner would be the one to work out those guidelines.
Yes.
But to explain ... apparently there are two firewalld
environments. When you install a service file it only affects
the installed environment (used after a reboot) and not the
current runtime environment.
This means that a user can't immediately use your service
definition in a command like:
$ firewall-cmd --add-service=cockpit
The command:
$ firewall-cmd --reload
... makes newly installed service files available in the runtime
environment. I guess this is sorta analogous to 'systemctl
daemon-reload'.
Newly added services and zones are available in the permanent
environment of firewalld, where they can be used with the UI and
command line tools.
To have a newly added service or zone in the runtime environment it
is needed to reload firewalld: firewall-cmd --reload or systemctl
reload firewalld.service.
Thomas, the real question here is this: If a package wants to install
(and maintain) its own set of firewalld service definitions, is the
approach Stef took the best one? If so, we should submit a Packaging
Guidelines edit to the FPC and get this codified where others can find it.
Yes, this is the best approach right now.
I can write some documentatoin for this. What is the proper way to get
it in the Packaging guidelines?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlO6mLwACgkQeiVVYja6o6MnWgCfT9Nle/gfxrmsBu13mIS03f4J
n+sAn2oMz8nlbBukQ1Y+/R9VkrKV9JO7
=9yrD
-END PGP SIGNATURE-
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: defining firewalld services
On 07/03/2014 09:32 PM, Stef Walter wrote:
On 03.07.2014 15:39, Rex Dieter wrote:
I'm looking into providing a predefined firewalld service definition for
kde-connect, per
https://bugzilla.redhat.com/show_bug.cgi?id=1115547
Looks like it's as easy as dropping an xml snippet into
/usr/lib/firewalld/services/
I'm also noticing currently that the only package besides fallwalld itself
doing this is cockpit, which includes a %post scriptlet:
# firewalld only partially picks up changes to its services files
# without this
test -f %{_bindir}/firewall-cmd firewall-cmd --reload --quiet || true
Is this the recommended approach? If so, I'll follow this lead, and maybe
start work on drafting some packaging guidelines.
Thomas Woerner would be the one to work out those guidelines.
Yes.
But to explain ... apparently there are two firewalld environments.
When you install a service file it only affects the installed
environment (used after a reboot) and not the current runtime environment.
This means that a user can't immediately use your service definition in
a command like:
$ firewall-cmd --add-service=cockpit
The command:
$ firewall-cmd --reload
... makes newly installed service files available in the runtime
environment. I guess this is sorta analogous to 'systemctl daemon-reload'.
Newly added services and zones are available in the permanent
environment of firewalld, where they can be used with the UI and command
line tools.
To have a newly added service or zone in the runtime environment it is
needed to reload firewalld: firewall-cmd --reload or systemctl reload
firewalld.service.
Stef
Thomas
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: an that is why we need a firewall - Re: When a yum update sets up an MTA ...
On 04/28/2014 08:09 PM, Florian Weimer wrote: On 04/28/2014 12:42 PM, David Woodhouse wrote: Actually, I think the best way to fix this is with SELinux, rather than iptables. Why go for an overly complex solution where authorised processes have to prod a firewall dæmon to change the iptables configuration, when the kernel has a perfectly good firewall built in as a fundamental part of the IP stack? Send a TCP SYN to a port which nobody's listening on, and you'll get a TCP RST back. Send a UDP packet to closed port, and you'll get an ICMP 'port unreachable' back. No need for iptables at all. All you need to do, if you really want to control incoming connections, is use SELinux to limit who can bind() and listen() to certain ports. Can we make this stick for the unconfined_t user as well? How can system administrators configure exceptions? What about developers who need to bind to various ports, e.g. while running test suites? Will it be as straightforward as with firewalld? An explicit failure on bind() might actually give us better error reporting (especially if the EPERM details idea is implemented). I like the SELinux idea. To be able to bind only in a trusted environment has advantages, but also disadvantages: + You have the possibility of error reporting if the app is designed in the way to fail gracefully in the unable to open port case. - Only works in a simple network environment that needs to be at best static. - Does not work with more than one active connection where some are trusted and others are not without adding mechanisms in all network services and apps that will take care about this internally with configuration and policies. - Is not working while switching the network environment from trusted to untrusted or vice versa without having network services and apps that will react gracefully on a now closed port or that are able to bind later on to. Rebooting the system, restarting all network services and apps or logging out and back in is not a good solution for this. Ergo: You need to have very smart network services and apps with this. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Workstation: Disable firewall
On 04/22/2014 09:17 PM, Russell Doty wrote: On Tue, 2014-04-22 at 15:04 -0400, Simo Sorce wrote: On Tue, 2014-04-22 at 14:41 -0400, Russell Doty wrote: On Tue, 2014-04-22 at 14:23 -0400, Simo Sorce wrote: On Tue, 2014-04-22 at 13:22 -0400, Russell Doty wrote: On Tue, 2014-04-22 at 19:01 +0200, Miloslav Trmač wrote: 2014-04-22 13:40 GMT+02:00 Stephen Gallagher sgall...@redhat.com: 3) Recovery and auditing are more important than prevention. This is only true for large managed enterprises, where recovery is possible in the first place (how many people don't have good backups?), and prevention is bordering on impossible (with the high number of systems and administrators). For individual users auditing is completely pointless, recovery is either impossible or a huge hassle, and prevention the only option. Well, the presentation was focused on enterprise systems... But there were some underlying themes: * Users will work around anything, including security features, that interfere with them doing their job. * It is impossible to completely secure a system. A prevention only approach doesn't work well. * An effective security model is built around Deter, Detect, Delay, Respond, Remediate. * Security is one of multiple threats to system integrity. All very true, but you do not remove the Deterrent, just because you have the other 4 layers (which we do *not* have very much in Fedora when it is used as a simple workstation). Absolutely true - the foundation of the stack is Deter. The point is that we can't harden a system enough for Deter alone to be fully effective, so we need to have the complete security model. And you are right. We have a real opportunity to look at an overall people centric approach to security in Fedora. Look at the traditional threat models, look at the people issues, and look at an overall approach to maintaining system integrity. I'd like to see us exploring system integrity in greater depth. This is why people say we need to improve the Firewall experience not raise white flag and disable it. Agree. Unfortunately, the easy way out is to punch so many holes in the default firewall that it doesn't offer much protection... not really true, having the default one allow access only from the local lan at most is a huge improvement rather than no firewall. All you need is a button that lets you select between 3 zones when you join a new network and you have a much better system already, nothing fancy, and the 3 zones correspond to the concepts of: open to everyone (effectively disables any protection) open to the local lan only (what you would select at home/work/trusted network) closed (what you would select in a public place on an untrusted network) This sounds a lot like the Network Manager model. Could this basic firewall configuration be integrated with the Network Manager interface? So that a user sets their security profile one place, and all related system settings and configurations are updated? Please have a look at edit connection in the NetworkManager applet. There have been plans to query for the zone that should be used for a connection before activating this connection for the first time. There are even sketches for this. But as I said before, this has been rejected by the desktop team. Because of this I created firewall-applet, which provides a simple UI to switch zones for connections with NetworkManager and for interface and source bindings. It is quite simple to describe even to a non expert user what these means in general terms. Of course it won't be perfect, but much better than nothing, and much, much friendlier than what we have now. A combination of this and having all commonly used applications configure the firewall when installed/uninstalled looks like a good start, especially from a usability perspective. Simo. -- Simo Sorce * Red Hat, Inc * New York Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Workstation: Disable firewall
On 04/21/2014 12:22 AM, drago01 wrote: On Mon, Apr 21, 2014 at 12:02 AM, Reindl Harald h.rei...@thelounge.net wrote: * there are network services enabled by default Again that's a bug and a viloation of the guidelines. Which services are you talking about? Please file bugs. * avahi is one of them You keep listing this as an example but avahi is not only installed and enabled by default but also allowed configured to work in the default firewall setup since F18 [1] ... So the current default firewall won't protect you against avahi flaws. This has been added only because of a FESCo decision: https://fedoraproject.org/wiki/Features/AvahiDefaultOnDesktop * you nor i can say for sure avahi never ever get a critical security update See above. * you nor i can be sure that there is not another network-service is running * even if it is not running by intention it may be running by mistake as default * so after you installed a new system avahi is running and the firewall down See above. * how do you genius install the updates without a network and to *not* have to consider what is safe and what you have to stop after a fresh install before you can plug your machine to the network for install security relevant updates a firewall has to be enabled by default Again you 1) assume that we enable random services by default and the firewall is the only thing that protects freshly installed systems 2) that given the user options that do not work and force him to learn about computer networks to do basic tasks is how things should work both are false. Sure disabling the firewall is not the only way to solve 2) but the silently make things not work i.e the status quo or ask a user questions that he does not understand are no solutions. There have been other suggestions in this thread that are helpful like the network zones thing (but we still have too many zones) or enabling services should make them work i.e just enable the firewall rules. honestly it's good that you are out of this discussion because you seem to not have you clue about security nor understand the implications of who knows hat he is doing and why the one who don't need sane defaults No the reason is simply that talking to you is very annoying .. you resort to baseless attacks (like the this one) and strawmans. 1: http://fedoraproject.org/wiki/Features/AvahiDefaultOnDesktop -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Workstation: Disable firewall
On 04/15/2014 09:14 PM, Michael Cronenworth wrote: Christian Schaller wrote: We already allow that and have for a long while. Any application bothering to support the firewalld dbus interface can open any port they wish to. Good luck getting software to add this. A more sensible option would be to better tie NetworkManager into firewalld. When you make the first connection for any network device the user must be prompted for the firewall zone you wish to tie to the connection. Today, all connections get mapped to the Default zone, but if prompted, and you wanted to make the home zone essentially open then this would solve the OP's Change request. There have been plans about this, but it has been refused ... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Workstation: Disable firewall
On 04/15/2014 10:49 PM, Matthias Clasen wrote: On Tue, 2014-04-15 at 20:41 +0200, Thomas Woerner wrote: What you need is clearly different zones that the user can configure and associate to networks, with the default being that you trust nothing and everything is firewalled when you roam a new network. We have that already with zones in firewalld. Kindof. If I open the network panel and find the 'Firewall zone' combo, I am presented with a choice of: Default block dmz drop external home internal public trusted work This list is far too long, and none of it is translated or even properly capitalized. And there is no indication at all why one would choose any zone over any other, and what consequences it has. So, what you have currently is a raw bit of infrastructure that is directly exposed to the end user, without any design or integration. There have been plans about a firewall layer in gnome. The gnome team decided not to support it and not to work on anything that is firewall or firewalld related. There have been several meetings about this. Now complaining that it is not there and not integrated just makes me sad, especially as there was a tool in gnome 3, that has support for firewalld, but this support has been removed again. The limitations in gnome 3 are: - Applets are not easily visible in the desktop. - An applet is not always visible, even if the state in the applet is to be visible. - Sending out notifications is prohibiting the use of left and right mouse button menus: While the notification is visible, a left and right mouse button click on the applet only shows the notification. - After closing an notification sent out by the applet, the applet is made invisible in the tray with a still visible state in the applet. Not even a hide and show will make it visible anymore. - Left and right mouse button menus are loose in the desktop and are not visibly connected to the applet, it is not visible any more after clicking on it. GNOME doesn't have applets anymore, so complaining that your applet doesn't work great in GNOME is missing the point. So what would your solution then be for such a workflow today when applets aren't supported anymore? And of course one that would work for other desktops, as maintaining N versions for N different desktops doesn't scale. I don't think we want a 'firewall' UI anyway; the firewall is not something most users can or should understand and make decisions of. What I envision is that we will notify the user when we connect to a new network, with a message along the lines of: This has been planned before but has been refused. Coming up with this again is funny also. You have connected to an new network. If this is a public network, you may want to stop sharing your Music and disable Remote Logins. [Turn off sharing] [Continue sharing] [Sharing Preferences...] And we will remember this for when you later reconnect to the same network. This is exactly what zones are for, but you do not have to alter applications or logins. When we have this infrastructure, we can use this information to also set the network zone to Home/Public - I don't think the long list of zones I showed above makes any sense. Either you are at home and comfortable sharing the network, or not. If you're still interested to make this work I'm still willing to work on this together with you and the gnome team to make sure everyone will have the benefit of an out-of-box secure Fedora with an easy to use firewall with a proper UI. I've filed a bug for this: https://bugzilla.gnome.org/show_bug.cgi?id=727580 Matthias Thomas - firewalld maintainer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Workstation: Disable firewall
On 04/16/2014 01:11 AM, William Brown wrote: On Tue, 2014-04-15 at 13:49 -0700, Matthias Clasen wrote: On Tue, 2014-04-15 at 20:41 +0200, Thomas Woerner wrote: What you need is clearly different zones that the user can configure and associate to networks, with the default being that you trust nothing and everything is firewalled when you roam a new network. We have that already with zones in firewalld. Kindof. If I open the network panel and find the 'Firewall zone' combo, I am presented with a choice of: Default block dmz drop external home internal public trusted work This list is far too long, and none of it is translated or even properly capitalized. And there is no indication at all why one would choose any zone over any other, and what consequences it has. Agreed Perhaps shorten to: block public work home The other network zone names really seem targeted at servers. Maybe each zone needs an attr that states if it's a workstation zone or not to determine if it joins this list? So, what you have currently is a raw bit of infrastructure that is directly exposed to the end user, without any design or integration. Additionally, the command line syntax to manage firewalld is obscene. (maybe slightly off topic ...) firewall-cmd --zone=foo --add-port=12345/tcp --permanent It doesn't autocomplete in bash either (zsh at least prefills the -- and gives you some options, but it's not great) There is bash autocompletion support since Fedora 19. But it not able to autocomplete unknown zone names and also not ports. Please try it again. At least for the power user on a workstation, fixing this syntax to at the minimum remove all the -- would be great. Follow that by nm-cli style short hand, and I would be a happy person. You could do: firewalld-cmd z=foo a-p=12345/tcp perm Because this syntax is hard I think that it even excludes power users from wanting to make their firewall work on their system. You are invited to work with us .. I don't think we want a 'firewall' UI anyway; the firewall is not something most users can or should understand and make decisions of. Never take decisions away from users. The OSX style firewall works well when enabled. It blocks all by default, then when an application wants a listening port, the user is prompted to allow or deny it. I think this is a good model. What I envision is that we will notify the user when we connect to a new network, with a message along the lines of: You have connected to an new network. If this is a public network, you may want to stop sharing your Music and disable Remote Logins. [Turn off sharing] [Continue sharing] [Sharing Preferences...] And we will remember this for when you later reconnect to the same network. Why not set the firewall zone when you join the network? And the above prompts alter that currently active zone? I've filed a bug for this: https://bugzilla.gnome.org/show_bug.cgi?id=727580 Matthias -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Workstation: Disable firewall
On 04/16/2014 02:18 AM, Chuck Anderson wrote: On Tue, Apr 15, 2014 at 07:28:35PM -0400, Simo Sorce wrote: On Tue, 2014-04-15 at 13:49 -0700, Matthias Clasen wrote: You have connected to an new network. If this is a public network, you may want to stop sharing your Music and disable Remote Logins. [Turn off sharing] [Continue sharing] [Sharing Preferences...] So if you have 4 different services you gfet flooded with a ton of questions ? Sounds like a bad idea. And we will remember this for when you later reconnect to the same network. If you set a *zone* instead then you have to remember only one association: network - zone, and you know where to go to change that, and to change in which zones an application is allowed to listen, instead of having tens of one offs. When we have this infrastructure, we can use this information to also set the network zone to Home/Public - I don't think the long list of zones I showed above makes any sense. Either you are at home and comfortable sharing the network, or not. A long list does not make sense by default, ideally the default is that you have only 2 zones: trusted/untruuted (you can choose whatever names), if the users wants more flexibility then they would create new zones (like home, work, cafe, library, etc..) perhaps by cloning existing ones and then tweak the list of applications allowed to serve content in those zones. It would be better if the association were per-application rather then nameless ports. Additionally, some zones should be bound to a certain network scope. Today you could say Home or Trusted for your RFC1918-behind-NAT network at home, but tomorrow your ISP could enable IPv6 and all of a sudden your system connected to that subnet is exposed to the whole world... So you really need some concept of scope to attach to the zone so you can only allow connections from within that scope. The hard part is how to define that scope. I believe Windows defaults to local subnet when you choose Home. For this we need a better integration into NetworkManager. Additionally we can not make this work easily with network services. firewalld does not take care about the network configuration. A agree, it would be good to have support for this. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Workstation: Disable firewall
On 04/16/2014 02:28 PM, Josh Boyer wrote: On Wed, Apr 16, 2014 at 7:11 AM, Ian Malone ibmal...@gmail.com wrote: On 16 April 2014 00:11, William Brown will...@firstyear.id.au wrote: On Tue, 2014-04-15 at 13:49 -0700, Matthias Clasen wrote: I don't think we want a 'firewall' UI anyway; the firewall is not something most users can or should understand and make decisions of. Never take decisions away from users. The OSX style firewall works well when enabled. It blocks all by default, then when an application wants a listening port, the user is prompted to allow or deny it. I think this is a good model. Users can't understand a firewall, let's just turn it off (I realise that's not your position, it's the one that seems to be coming up in this thread.) Anyone else astounded this discussion is actually taking place? I'm astounded that everyone on all sides is showing a complete inability to think outside their own box in this thread. Beyond that, nothing else surprises me. For a quick summary: 1) With a firewall enabled, network services don't work without manual intervention. 2) With firewalld active, any privileged application can open a port in the firewall (and most will be privileged because they will be packaged that way.) We are using auth_admin_keep. So the user needs to enter the admin password for all applications that are not running as root to modify the firewall. But an application (and the user) is able to get information about most parts without the admin password. 3) With no firewall enabled and no network services started, there is no security issue because there are no open ports. Mostly all desktop sharing tools are using dynamic ports and some or all of them are started as soon as you are logging in. 4) With no firewall but active network services, you have open ports just as you would in the firewalld or manual intervention firewall case No, see above. You need to authenticate them to be able to modify the firewall. 5) Which ports can safely be opened is completely irrelevant to the presence of a firewall or not. It is entirely dependent upon the trust of the network the machine is connected to. On unsafe networks, you have one of two options: a) turn off those network services, b) use a firewall to block the ports those network services need (which is a strange form of a). If those facts hold true, and I think they do, then I am not surprised at all that there's no consensus here. It isn't as clear cut as everyone seems to want it to be. The zones approach seems fairly reasonable to me. That in and of itself doesn't require a firewall though. Zones could be implemented by simply turning off the network services completely, which would then close the open ports. However, using a firewall to implement zones does allow for protection against unknown/unwanted network services running. A reduced set of zones firewall rules and proper integration in whatever implementation is chosen would seem to be the middle ground here. I like the middle ground. Maybe we could shoot for that? Otherwise, I won't be astounded at all when FESCo rejects the current Change and some users still turn off the firewall as one of the first things they do because things don't work. There has been a plan about this before. It only need to be reworked and implemented. josh Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Workstation: Disable firewall
On 04/16/2014 06:43 PM, Tomasz Torcz wrote: On Wed, Apr 16, 2014 at 12:32:02PM -0400, Simo Sorce wrote: I think what you are describing could be probably realized with SELinux today, just with a special setroubleshoot frontend that catches the AVC when the service tries to listen and ask the user if he wants to allow it. However this would still not be completely sufficient as you completely lack any context about what network you are operating on. The firewall's purpose is to block access to local services on bad networks too, it is not a binary open/close equation when you have machines (laptops) that roam across a variety of networks. Simo. Nothing worse then asking Users Security related questions about opening firewall ports. Users will just answer yes, whether or not they are being hacked. firefox wants to listen on port 9900 in order to see this page, OK? Which is not what I proposed Dan. I in fact said we should *NOT* ask per application. What we should ask is one single question, upon connecting to an unknown network: Is this network trusted ? If yes you open up to the local network. If no you keep ports not accessible on that network. But firewalld currently lacks flexibility to express this fully. Firewalld only classifies ”whole” interfaces, which breaks badly in many situations. Consider following scenario: VM with single network interface. This single interface has RFC1918 IPv4 address AND globally accesible IPv6 address. How it should be described in firewalld? firewalld supports to have rules for IPv4 and/or IPv6. – for any IPv4 incoming connection, this interface is in ”trusted” (”home”? I never know what home/work/dmz/etc really mean) You can full customize all zones. This is the reason there is no simple description for each zone. – for IPv6 incoming connection from 2001:6a0:138:1::/64 subnet, the zone is still ”trusted” – for any other incoming connection the zone is ”public” (I hope this means ”general Internet”). Above is trivial in iptables, but impossible with firewalld's zones. firewalld also has the ability to bind zones to source addresses and address ranges. This might help here. Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Workstation: Disable firewall
On 04/15/2014 04:28 PM, Christian Schaller wrote: - Original Message - From: Reindl Harald h.rei...@thelounge.net To: devel@lists.fedoraproject.org Sent: Tuesday, April 15, 2014 11:40:20 AM Subject: Re: F21 System Wide Change: Workstation: Disable firewall Am 15.04.2014 11:32, schrieb drago01: On Tue, Apr 15, 2014 at 11:18 AM, Reindl Harald h.rei...@thelounge.net wrote: allow any random application to open a unprivlieged port which is reachable from outside is dangerous We already allow that and have for a long while. Any application bothering to support the firewalld dbus interface can open any port they wish to. Are you running your desktop as root or all your applications are authenticated? - I hope not. Only authenticated applications and services can modify the firewall. There was a long thread about this on the desktop mailing list, and I was not in the 'disable the firewall' camp in that discussion, but nobody in that thread or here have articulated how the firewall exactly enhance security in the situation where we at the same time need to allow each user to have any port they desire opened for traffic to make sure things like DLNA or Chromecast works. You can simply use different zones for the different connections you are using. Most likely you do not want to enable DLNA and Chromecast in a public internet cafe, but at home. So simple marking your home Wifi using the trusted zone is the trick to allow everything within this Wifi only. It is also possible to change the zone that is used for a connection. You can bind connections or interfaces to zones in ifcfg files and in NetworkManager - probably not in the gnome 3 UI, but in all other UI versions ... The thread discussing this ended up with mostly being a discussion if the firewall would be a useful way to help users from accidentally oversharing on a public network. Which is important and something we want to work on, but a lot less so than security issues. Christian Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Workstation: Disable firewall
On 04/15/2014 04:42 PM, Reindl Harald wrote: Am 15.04.2014 16:28, schrieb Christian Schaller: - Original Message - From: Reindl Harald h.rei...@thelounge.net To: devel@lists.fedoraproject.org Sent: Tuesday, April 15, 2014 11:40:20 AM Subject: Re: F21 System Wide Change: Workstation: Disable firewall Am 15.04.2014 11:32, schrieb drago01: On Tue, Apr 15, 2014 at 11:18 AM, Reindl Harald h.rei...@thelounge.net wrote: allow any random application to open a unprivlieged port which is reachable from outside is dangerous We already allow that and have for a long while. Any application bothering to support the firewalld dbus interface can open any port they wish to. that is bad enough *but now* we disable any firewall at all? seriously? Only authenticated applications can change firewall settings like for example open ports, ... There was a long thread about this on the desktop mailing list, and I was not in the 'disable the firewall' camp in that discussion, but nobody in that thread or here have articulated how the firewall exactly enhance security in the situation where we at the same time need to allow each user to have any port they desire opened for traffic to make sure things like DLNA or Chromecast works. that is pretty easy - defaults have to be closed anything and the user have to make a choice for, otherwise if there are cirtical security updates after a release you have *exactly* the same as WinXP SP2 try it out on a public reachable IP, you will not survive the time you need to apply the security updates because you are infected long before honestly if these days i would consider switch to linux and unsure which distribution the one proposing disable firewall by default would be the last one on the list -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Workstation: Disable firewall
On 04/15/2014 04:37 PM, Simo Sorce wrote: On Tue, 2014-04-15 at 10:28 -0400, Christian Schaller wrote: - Original Message - From: Reindl Harald h.rei...@thelounge.net To: devel@lists.fedoraproject.org Sent: Tuesday, April 15, 2014 11:40:20 AM Subject: Re: F21 System Wide Change: Workstation: Disable firewall Am 15.04.2014 11:32, schrieb drago01: On Tue, Apr 15, 2014 at 11:18 AM, Reindl Harald h.rei...@thelounge.net wrote: allow any random application to open a unprivlieged port which is reachable from outside is dangerous We already allow that and have for a long while. Any application bothering to support the firewalld dbus interface can open any port they wish to. There was a long thread about this on the desktop mailing list, and I was not in the 'disable the firewall' camp in that discussion, but nobody in that thread or here have articulated how the firewall exactly enhance security in the situation where we at the same time need to allow each user to have any port they desire opened for traffic to make sure things like DLNA or Chromecast works. The thread discussing this ended up with mostly being a discussion if the firewall would be a useful way to help users from accidentally oversharing on a public network. Which is important and something we want to work on, but a lot less so than security issues. There is plenty of prior art here. What you need is clearly different zones that the user can configure and associate to networks, with the default being that you trust nothing and everything is firewalled when you roam a new network. We have that already with zones in firewalld. firewalld should grow a NetworkManager plugin so that configuration can be changed on the fly based on which network NM tells firewalld a specific interface is connected to. We have that already: With NetworkManager and ifcfg files a connection/interface can be bound to a zone, it is then not in the default zone. NetworkManger sends out an request to firewalld to bind the interfaces related to a connection to the defined or the default zone. We also have an applet (firewall-applet) to assign and change zones in an easy way, but because of system tray usability limitations in gnome 3 it is not as usable as it is in other desktop environments. This is an system tray applet, because I can either write an gnome-shell applet, that is only working in gnome 3. Or I can write an applet that is working correctly in all other desktop environments and limited in gnome 3 - I will not write several. The limitations in gnome 3 are: - Applets are not easily visible in the desktop. - An applet is not always visible, even if the state in the applet is to be visible. - Sending out notifications is prohibiting the use of left and right mouse button menus: While the notification is visible, a left and right mouse button click on the applet only shows the notification. - After closing an notification sent out by the applet, the applet is made invisible in the tray with a still visible state in the applet. Not even a hide and show will make it visible anymore. - Left and right mouse button menus are loose in the desktop and are not visibly connected to the applet, it is not visible any more after clicking on it. Applications need to be prevented from being able to arbitrarily open ports, that should be allowed only for a trusted zone. User intervention should be needed to mark a zone as trusted, in all other zones the user will have to select explicitly what applications are allowed. So the big work here is in the UI you need to build to present these configurations to the user. Until then you can present a very simplified UI that just has a big button/switch that turns everything from untrusted to trusted, with the default being untrusted of course. Simo. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21/F22 System Wide Change: Python 3 as the Default Implementation
Hello, On 10/09/2013 02:07 PM, Jaroslav Reznik wrote: = Proposed System Wide Change: Python 3 as the Default Implementation = https://fedoraproject.org/wiki/Changes/Python_3_as_Default Note: Change requested by FESCo in advance for targeted Fedora. firewalld is now fully compatible to python3, but we found this problem: https://bugzilla.redhat.com/show_bug.cgi?id=1023985 It seems there is a problem in the python3 dbus bindings if exceptions are raised. Regards, Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: firewalld rewrite in C - outdated wiki page
On 10/02/2013 10:37 AM, Miroslav Suchý wrote: On 10/02/2013 08:33 AM, Mateusz Marzantowicz wrote: I've found this page [1] with following content: - Targeted release: Fedora 16 - Last updated: 2011-06-27 - Percentage of completion: 10% Is it OK to have feature which is 10% complete and is still targeted at eol release? It has been proposed at some time, but then has been postponed. If you navigate to (the link is located on bottom of your page) https://fedoraproject.org/wiki/Category:FeaturePageIncomplete You will see huge list of Features. Which are incomplete. Which means that it was not accepted by FesCo, or even not submitted and author gave up for some reason. Or it is still on his TODO list, where it can stay for long long time. You can pick it up. Or delete it, if it bothers you. But best approach is always contact original author and ask him, what are his plans with that feature. We are starting a new attempt to have a recode in a C-based language right now. I will delete the contents of the page for now. Thanks, Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: About F19 Firewall
On 09/20/2013 09:05 PM, P J P wrote: Hi, - Original Message - From: Thomas Woerner twoer...@redhat.com Subject: Re: About F19 Firewall 1) Separate zones. NM connections, interfaces and source addresses or ranges can be bound to zones. The initial default zone is public and all connections will be bound to this zone. The user or administrator can bind connections to other zones by either doing this in the NM connection editor or within the ifcfg file. Yeah, Mateusz explained that earlier. I don't use NM either. You can use ZONE=zone in the ifcfg file of the interface to set the zone also if they are not managed by NM. If it is missing or unset, the default zone will be used. 2) Make sure that a newly added rule will have the desired effect. If you are mixing deny and allow rules, you can not say which effect it will have. Either there are unwanted accepts or rejects or drops. A simple and straight forward solution is to have separate chains for deny and allow rules. The same applies also for logging rules. iptables(8) takes action(jumps to target) at the first rule that matches or continues further till it finds a match and falls back to the chain policy if no rule is matched. From the manual: ---TARGETS A firewall rule specifies criteria for a packet and a target. If the packet does not match, the next rule in the chain is the examined; if it does match, then the next rule is specified by the value of the tar‐ get, which can be the name of a user-defined chain or one of the spe‐ cial values ACCEPT, DROP, QUEUE or RETURN. ... If the end of a built-in chain is reached or a rule in a built-in chain with target RETURN is matched, the target specified by the chain policy determines the fate of the packet. --- You have to make sure where you are adding new rules. Here is a simple example where you want to drop everything from 192.168.1.18: If you do it wrong if could end up like this (output of iptables -S): -A INPUT -s 192.168.1.0/24 -j ACCEPT -A INPUT -s 192.168.1.18 -j DROP -A INPUT -j REJECT All from 192.168.1.0/24 is accepted, the following rule does not have any effect. It is not used at all. But it you add the rule to be the first, you will drop packets from 192.168.1.18 and will accept all the others from 192.168.1.0/24. You do not need to change it, but you can if you want to. If for example you are using wifi connections at home, work, .. you can bind these to the (for you) appropriate zone. For example work for your work wifi connection. It will be used only if you are connecting to your work wifi connection (it is bound to the SSID). The default zone (initially public) is used for all connections and interfaces where the zone has not been set to another value. You can customize the zones and services according to your needs. Yes, I understand the functionality, but I doubt if it'll be used at all. It's not desktop background that people would want to change everyday. firewalld is not a desktop firewall in the first place. --- Regards -Prasad http://feedmug.com Regards, Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: About F19 Firewall
On 09/20/2013 10:10 PM, P J P wrote: Hi, - Original Message - From: Thomas Woerner twoer...@redhat.com Subject: Re: About F19 Firewall If a static firewall configuration fits your needs, just disable firewalld and use the ip*tables firewall services: Static? Oh my...! Firewalld allows Applications, daemons and the user can request to enable a firewall feature over D-BUS. It does not seem like a good idea at all. The ip*tales services are handling the rule set as a whole. If you are changing it with iptables calls it is up to you, but the services can only apply or remove the whole rule set. Applications or daemons can only request changes to the firewall if they are authenticated. This is not a change compared to using an ip*tables call. But you are able to limit this further with firewalld. --- Regards -Prasad http://feedmug.com Regards, Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: About F19 Firewall
On 09/24/2013 05:15 PM, P J P wrote: Hello Thomas, - Original Message - From: Thomas Woerner twoer...@redhat.com Subject: Re: About F19 Firewall You have to make sure where you are adding new rules. Here is a simple example where you want to drop everything from 192.168.1.18: If you do it wrong if could end up like this (output of iptables -S): -A INPUT -s 192.168.1.0/24 -j ACCEPT -A INPUT -s 192.168.1.18 -j DROP -A INPUT -j REJECT Yes, I know about the ordering issue. But that is fairly reasonable, intuitive and straightforward to understand. O.k., then please provide a program that places (user supplied) rules at the proper position in an (user supplied) rule set in that way that it will always result in the (user) expected behaviour without further modifications. BTW: This is not limited to source addresses only, but also port ranges and ports, matches, logging, .. I am looking forward to get this solution. --- Regards -Prasad http://feedmug.com Regards, Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: About F19 Firewall
On 09/21/2013 12:08 AM, Mateusz Marzantowicz wrote: On 20.09.2013 22:23, Björn Persson wrote: Anyone can broadcast an SSID. How does FirewallD authenticate the network connection? FirewallD is not responsible for such authentication/AP validation. Firewall as such is not meant to assure you're connecting to where you want. NM tells firewalld where to put the interfaces bound to a connection. firewalld is not doing anything with SSIDs and other connection related information. Mateusz Marzantowicz Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: About F19 Firewall
On 09/21/2013 12:22 AM, Chuck Anderson wrote: On Fri, Sep 20, 2013 at 04:17:21PM +0200, Thomas Woerner wrote: If a static firewall configuration fits your needs, just disable firewalld and use the ip*tables firewall services: https://fedoraproject.org/wiki/FirewallD?rd=FirewallD/#Using_static_firewall_rules_with_the_iptables_and_ip6tables_services BTW: If are not configuring an IPv6 firewall, I would highly recommend to either also add an IPv6 firewall with the ip6tables service or to deactivate IPv6 on your machine. Speaking of which, I have a somewhat strange scenario. I have a global IPv4 address on one interface, so I put that interface into the Public zone. I have a private IPv4 address (RFC1918 on my LAN) on another interface. I want to put that on the Home zone so I can do mDNS, etc. BUT this same private NIC also has a public IPv6 address because the private LAN's router is a Hurricane Electric IPv6 tunnel endpoint...I don't want the ip6tables rules to be in the Home zone, but rather Public. Does firewalld support non-congruent rules between IPv4 and IPv6? How about different zones for different IP addresses on the same interface (mixed IPv4/IPv6 or even multiple IPv4 or multiple IPv6 for that matter)? You can bind IP addresses and address ranges to zones already. With firewall-cmd: firewall-cmd [--permanent] --zone=zone --add-source=source[/mask] Example: firewall-cmd --zone=home --add-source=192.168.0.3 firewall-cmd --permanent --zone=home --add-source=192.168.0.3 This will add it for the current run time environment and also permanently. You can also use IPv6 addresses for this. See man firewall-cmd at Options to Handle Bindings of Sources -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: About F19 Firewall
On 09/24/2013 06:53 PM, Thomas Woerner wrote: On 09/21/2013 12:22 AM, Chuck Anderson wrote: On Fri, Sep 20, 2013 at 04:17:21PM +0200, Thomas Woerner wrote: If a static firewall configuration fits your needs, just disable firewalld and use the ip*tables firewall services: https://fedoraproject.org/wiki/FirewallD?rd=FirewallD/#Using_static_firewall_rules_with_the_iptables_and_ip6tables_services BTW: If are not configuring an IPv6 firewall, I would highly recommend to either also add an IPv6 firewall with the ip6tables service or to deactivate IPv6 on your machine. Speaking of which, I have a somewhat strange scenario. I have a global IPv4 address on one interface, so I put that interface into the Public zone. I have a private IPv4 address (RFC1918 on my LAN) on another interface. I want to put that on the Home zone so I can do mDNS, etc. BUT this same private NIC also has a public IPv6 address because the private LAN's router is a Hurricane Electric IPv6 tunnel endpoint...I don't want the ip6tables rules to be in the Home zone, but rather Public. Does firewalld support non-congruent rules between IPv4 and IPv6? How about different zones for different IP addresses on the same interface (mixed IPv4/IPv6 or even multiple IPv4 or multiple IPv6 for that matter)? You can bind IP addresses and address ranges to zones already. With firewall-cmd: firewall-cmd [--permanent] --zone=zone --add-source=source[/mask] Example: firewall-cmd --zone=home --add-source=192.168.0.3 firewall-cmd --permanent --zone=home --add-source=192.168.0.3 This will add it for the current run time environment and also permanently. You can also use IPv6 addresses for this. See man firewall-cmd at Options to Handle Bindings of Sources You can also use firewall-config. Please have a look at the Sources tab for the zone you want to bind the source to. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: About F19 Firewall
On 09/15/2013 08:52 PM, P J P wrote: Hi, I upgraded to F19 recently. And I happened to look at the output of iptables(8) today. $ iptables -nL It's baffling! It's crazy 4 pages long listing!! Why are there so many chains? Most are empty. Those which have rules, jump from one chain to another and that jumps to yet another. These chains are needed to 1) Separate zones. NM connections, interfaces and source addresses or ranges can be bound to zones. The initial default zone is public and all connections will be bound to this zone. The user or administrator can bind connections to other zones by either doing this in the NM connection editor or within the ifcfg file. 2) Make sure that a newly added rule will have the desired effect. If you are mixing deny and allow rules, you can not say which effect it will have. Either there are unwanted accepts or rejects or drops. A simple and straight forward solution is to have separate chains for deny and allow rules. The same applies also for logging rules. Multicast DNS is allowed in the internal network(chain IN_internal_allow). I guess IN_internal_allow is meant for some closed group internal network, not sure. ACCEPT udp -- 0.0.0.0/0224.0.0.251 udp dpt:5353 ctstate NEW Who uses it? This has been added because of a FESCo decision to enable Multicast DNS (mDNS). Then I looked at the firewall configuration GUI tool. That's even more baffling. On the left hand side, it lists zones: home, internal, public, work etc. without any explanation whatsoever what each one is suppose to do. It also has a default zone which is 'public'. I guess that must be the running firewall configuration. So even if I'm at work or at home, I'm using firewall configuration that is meant for public network, am I? Besides, who is going to switch between these zones everyday from home to work to home again? You do not need to change it, but you can if you want to. If for example you are using wifi connections at home, work, .. you can bind these to the (for you) appropriate zone. For example work for your work wifi connection. It will be used only if you are connecting to your work wifi connection (it is bound to the SSID). The default zone (initially public) is used for all connections and interfaces where the zone has not been set to another value. You can customize the zones and services according to your needs. I think for individual users, which is majority of the users, this is a stupid firewall. It doesn't have to be so complicated that even if one tries to understand it, he/she can not. :( --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: About F19 Firewall
Hello, On 09/16/2013 07:55 AM, P J P wrote: Hello Tomasz, - Original Message - From: Tomasz Torcz to...@pipebreaker.pl Subject: Re: About F19 Firewall You seem to have missed this Fedora *18* feature: https://fedoraproject.org/wiki/Features/firewalld-default firewall-cmd is supposed to isolate user from all this chains. Yep, true. My contention is not with the tool, but with the complexity it adds to the rules with all the zones and sub-chains and user-space tooling around it. - https://fedoraproject.org/wiki/FirewallD As I suspected a zone describes a network one is currently connected in. It could be home, work, public(wifi at a coffee shop) etc. That means one must keep shifting from home to work to home and in between public for coffee-shop. I wonder who's going to do that every day. If they don't they either don't get to use the network services or are not protected enough. Ex. one always has the 'public' zone rules activated. You do not have to do this. If you are binding your home wifi connection to the home zone, this will be handled automatically for you. NM sends a request to firewalld to add the interface(s) related to a connection into a zone. If the zone is not set, then the default zone will be used. If the zone is set and exists, then this zone will be used. Everything that is not set differently is part of the default zone. That's mDNS, widely used in zeroconf discovery (for example, printers). I did not mean why is it used, but who needs it. I think for most users such configurations are fairly static that mDNS avahi can be disabled after their first usage/discovery. Having a service/port open all the time, when you don't need it, isn't a good thing. This was not my decision. You can disable it in the zones if you do not want to have it. --- Regards -Prasad http://feedmug.com Regards, Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: About F19 Firewall
On 09/17/2013 07:21 AM, P J P wrote:
- Original Message -
From: P J P pj.pan...@yahoo.co.in
Subject: About F19 Firewall
It doesn't have to be so complicated that even if one tries to understand it,
he/she can not. :(
This small script seems to work good.
===
#!/bin/sh
#
# fw.sh: a basic drop unless allowed firewall.
FW='iptables -t filter '
# main
{
$FW -A INPUT -i lo -j ACCEPT;
$FW -A INPUT -p icmp -s 10.x.x.x/16 -j ACCEPT;
$FW -A INPUT -p tcp -s 10.x.x.x/16 -m state --state NEW --dport 22 -j
ACCEPT;
$FW -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT;
$FW -A INPUT -j REJECT --reject-with icmp-host-prohibited;
$FW -A OUTPUT -p tcp -m state --state NEW -s 10.x.x.x/16 -d facebook.com \
-j REJECT --reject-with icmp-host-prohibited
$FW -P INPUT DROP;
$FW -P FORWARD DROP;
exit 0;
}
===
If a static firewall configuration fits your needs, just disable
firewalld and use the ip*tables firewall services:
https://fedoraproject.org/wiki/FirewallD?rd=FirewallD/#Using_static_firewall_rules_with_the_iptables_and_ip6tables_services
BTW: If are not configuring an IPv6 firewall, I would highly recommend
to either also add an IPv6 firewall with the ip6tables service or to
deactivate IPv6 on your machine.
---
Regards
-Prasad
http://feedmug.com
Regards,
Thomas
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: About F19 Firewall
On 09/18/2013 08:16 AM, P J P wrote: Hello, - Original Message - From: Mateusz Marzantowicz mmarzantow...@osdf.com.pl Subject: Re: About F19 Firewall Maybe, true but I doubt that simpler set of rules, that never get audited, written by inexperienced users are more secure than complex rules in FirewallD which at last had chance to be checked. It's not that simpler rules are more secure, but they come handy if one is to audit them or modify them for his/her set-up. Such modifications could be merged back as user contributions, which only helps to strengthen the tool or set of rules. The thing with complexity is, it keeps, even the able people, away from fiddling with things which I feel sort of beats the whole purpose. As in, if amongst all the available zones, a user is always going to use just one everywhere, it beats the purpose of other zones and the promise of security too, no? Worse is, people would just turn it(Firewalld) off because they can not understand it or make it work for them. The zones are all created to be able to change into another zone easily and also without the need to created the new zone at that moment. BTW, there is not that much magic in rules applied by FirewallD and other firewall solutions for Linux have similar level of rule complexity (ufw, shorewall, etc.) True. We can not avoid complexity. There are complex set-ups networks, which need complex rules. Firewalld as a tool would be right having features to enable a user who wish to create such complexity and define rules for the same. But providing it by default for individual Fedora users, who don't need it, doesn't feel right. The complexity is needed to make sure that it behaves correctly. I think you already had fun with iptables rule ordering if you have been working with firewall configurations. It is very easy to add a rule at the wrong position to get unexpected behaviour. --- Regards -Prasad http://feedmug.com Regards, Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: About F19 Firewall
On 09/20/2013 04:15 PM, Matthew Miller wrote: On Tue, Sep 17, 2013 at 04:50:06PM +0200, Mateusz Marzantowicz wrote: It's written in Python and so what? Interpreted languages like Perl and Bash are widely used in Linux world to implement many tools. I don't buy argumentation that if something is not implemented in C it sucks. It's not that it sucks, it's that it requires significantly more resources. In a minimal install, firewalld is by far the largest memory consumer out-of-the-box, which is very wasteful in the 99.99% of the time where it isn't doing anything. And, the python stack is a meaningfully-large portion of the minimal install. Right now, that's unavoidable because of yum, but in the not-so-far future dnf may make it possible to remove that. If we're putting in _more_ python-dependent infrastructure code, we'll never get there. We are already working towards a rewrite in C for firewalld and firewall-cmd. firewall-config and firewall-applet will be python also in the future. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Firewall blocking desktop features
On 09/10/2013 10:07 PM, Peter Oliver wrote: Empathy's People Nearby feature doesn't work out of the box because the required ports are blocked by default by the firewall (https://bugzilla.redhat.com/show_bug.cgi?id=844308). It's a similar story with Gnome's Media Sharing feature, and I'm sure there are lots of other examples. With NM connection editor you can bind zones to the connections. For wireless connections you have a connection per ssid. This makes it possible to bind a zone (for example 'home') to your home connection. If you are trusting your home environment completely, you can also use 'trusted'. Then your home network will have full access to your machine. If you are using your machine in an other environment, then it will use another connection and therefore will be bound to another zone. The initial default zone is 'public'. If you are not in a semi or full trusted environment, then there is no simple solution. See further down... Now, if you're running a server and you install, say, Apache, I think you expect to have to go and poke at the firewall config, but these seem to be very desktop-focused features, and the UI provides no clue about the extra steps required. I am not sure if I am getting this right. What is 'these'? Are you are talking about the desktop UI or firewall-config UI here? The FirewallD wiki page talks about a proposed user interaction mode (https://fedoraproject.org/wiki/FirewallD#User_interaction_mode), which sounds like it's intended to address these kinds of issues. I guess that's not going to be with us soon? The user interaction mode is not planned for the short term anymore and it needs to be verified if it could be used with these desktop features at all. The time to ask the user and to get an ok/deny might be too long to establish a connection with the already received packets. A reconnect might be essential to make it work. Meanwhile, are there any quick ways we could simply this for users? It's not much, but should application packages ship /usr/lib/firewalld/services/service.xml files so that users can open the correct ports by ticking a box in firewall-config rather than having to go hunting around to find the ranges? We already have a long list of service configuration files provided by firewalld, most of them are service related. But there is sure room for improvement. To be able to add a service configuration file, the information about ports etc. is needed. Dynamic ports are not good for this. Lots of these desktop features are using some dynamic port(s), which makes the creation of service configuration files hard or impossible. Therefore there are (mostly) no service configuration files for these desktop features. At first there is no documentation about the used ports, addresses and so on and further more there seems to be no interest in firewalls at all. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
iptables 1.4.10 update, libxtables so version bump
Hello, iptables has been updated in Fedora rawhide. The version of libxtables has been bumped to 10. Therefore all packages, that require libxtables need to be rebuilt for the new lib. iproute has been rebuilt already. There are also testing packages for F-18: https://admin.fedoraproject.org/updates/iproute-3.6.0-7.fc18,iptables-1.4.18-1.fc18 Affected Fedora packages: libguestfs perl-IPTables-libiptc Thanks, Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Request for a firewalld secondary DHCP + PXEBOOT HOWTO
On 02/07/2013 05:23 PM, Aaron Gray wrote: Can someone who knows firewalld please do a HOWTO to on setting up a secondary DHCP with DNS and HTTPS access for PXEBOOTing of Fedora18 please to go with the PXEBOOT HOWTO :- http://linux-sxs.org/internet_serving/pxeboot.html Hope someone can help, I put I message on the User List but got no response. Aaron Do you want to provide this for IPv4 or IPv6 or both? The ports that need to be opened are different for DHCPv4 and DHCPv6. Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: firewalld Rich Language
On 02/01/2013 04:43 AM, Scott Schmit wrote: On Wed, Jan 30, 2013 at 12:56:18PM +, Jaroslav Reznik wrote: = Features/FirewalldRichLanguage = https://fedoraproject.org/wiki/Features/FirewalldRichLanguage Feature owner(s): Thomas Woerner twoer...@redhat.com This feature adds a rich (high level) language to firewalld, that allows to easily create complex firewall rules without the knowledge of iptables syntax. Where is this language documented, or is it still to be designed? It is in the design state. If the language is in an advanced state, I will push it to the firewalld and feature page. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
On 11/12/2012 08:53 PM, Matthew Miller wrote: On Sat, Nov 10, 2012 at 09:53:13PM +0100, Kevin Kofler wrote: I really don't understand why a core system component such as firewalld is implemented in Python! Here, I mostly don't see the reason for it to be running all the time. Couldn't it be dbus activated, and then go away when it's not needed? Then, it would matter less what it was written in. It would loose internal state if it would be D-BUS activated. Also each call would take a lot longer, which is bad for example for libvirt. And for reducing space use: I think it might also be nice to break python 2to3 and idle out of the python-libs package. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
On 11/13/2012 03:46 PM, Matthew Miller wrote: On Tue, Nov 13, 2012 at 02:28:17PM +0100, Tomasz Torcz wrote: Here, I mostly don't see the reason for it to be running all the time. Couldn't it be dbus activated, and then go away when it's not needed? Then, it would matter less what it was written in. It would loose internal state if it would be D-BUS activated. Surely it could persist it somewhere? Like in the actual netfilter rules? Yes. It has to be able to save internal state *somehow*, because if restarting the service breaks everything, we're not gaining much over the old way, are we? Plus, for a critical service like this, the service needs to be designed to be as robust as possible in situations where it might crash or get killed arbitrarily. With the old static firewall model every firewall change was a complete firewall recreate with conntrack loss. With firewalld changes to the firewall are done dynamically and conntrack is preserved. If you want to recreate rules, use reload. If you restart the service with systemd, the servce gets stopped and started again, so you will loose internal state. This is how services are working. And for things like the ten-second-temporary rule, it could hang around for a while. It is using glib timeouts for this, it is not hanging around and blocking. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
On 11/13/2012 04:02 PM, Matthew Miller wrote: On Fri, Nov 09, 2012 at 11:57:12AM -0500, Matthew Miller wrote: - no way to run once and exit for cloud guests with *non-dynamic* firewall needs, and it's a non-trivial user of system resources You can use the old firewall environment for static firewall use cases. Everything is still there. Can I use them *both together*? If so, okay. If not, we should keep entirely with the old one until this is really ready to take over. This is still unclear to me. Anaconda is pulling in firewalld for post-install configuration. Do we still _really_ have the option of the old firewall? You can not use both at the same time, as they are doing things completely different. The static firewall stuff is not active by default, but everything is available. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
On 11/13/2012 05:36 PM, Matthew Miller wrote: On Tue, Nov 13, 2012 at 05:28:42PM +0100, Thomas Woerner wrote: If you want to recreate rules, use reload. If you restart the service with systemd, the servce gets stopped and started again, so you will loose internal state. This is how services are working. I understand that some services work that way. However, I don't think that this is the best design for a firewall service. Is there some way to force the internal state to be recorded? Let's say there is a security fix for the firewall service which needs to be applied. The daemon will need to be reloaded. Is this now not possible? Some services work that way? Only some? If you have a security fix, you have to restart every service to get the new code. Firewalld is not able to save the state for a later start. And for things like the ten-second-temporary rule, it could hang around for a while. It is using glib timeouts for this, it is not hanging around and blocking. Sorry, this comment lost context: I didn't mean that the timeout implementation was poor. I meant that if the service were dbus activated, it could stay running if it continued to have things to do, and exit (maybe after a brief wait) if not. The security team asked me not to make firewalld a D-BUS driven mechanism, because of security concerns and also because of SELinux. Additionally every load of the mechanism could have to load modified or removed configuration files. So how should it get to the same state then again? How should it react on and reflect configuration changes? So it would have to write out everything - the state and all configuration files. I am sorry, but this is overkill and a most likely a source of big problems. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
On 11/13/2012 06:16 PM, Dennis Jacobfeuerborn wrote: On 11/13/2012 05:28 PM, Thomas Woerner wrote: On 11/13/2012 03:46 PM, Matthew Miller wrote: On Tue, Nov 13, 2012 at 02:28:17PM +0100, Tomasz Torcz wrote: Here, I mostly don't see the reason for it to be running all the time. Couldn't it be dbus activated, and then go away when it's not needed? Then, it would matter less what it was written in. It would loose internal state if it would be D-BUS activated. Surely it could persist it somewhere? Like in the actual netfilter rules? Yes. It has to be able to save internal state *somehow*, because if restarting the service breaks everything, we're not gaining much over the old way, are we? Plus, for a critical service like this, the service needs to be designed to be as robust as possible in situations where it might crash or get killed arbitrarily. With the old static firewall model every firewall change was a complete firewall recreate with conntrack loss. With firewalld changes to the firewall are done dynamically and conntrack is preserved. That's not correct. You can modify the firewall just fine without restarting it. This is related to system-config-firewall/lokkit. You are right, if you are using iptables directly then you do not have this limitation. firewalld is a replacement for s-c-fw/lokkit. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
On 11/09/2012 07:45 PM, Reindl Harald wrote: Am 09.11.2012 17:45, schrieb Thomas Woerner: On 11/09/2012 05:24 PM, Eric H. Christensen wrote: Please have a look at the feature list for F-18. firewalld replaces system-config-firewall/lokkit, and the iptables and ip6tables services, not the iptables package and command. The ip*tables services and also system-config-firewall/lokkit are still available and also usable after deactivation of the firewalld serice. With the latest request to move the services of iptables and ip6tables in a sub package, I will add a requirement to system-config-firewall for this PLEASE do not Require: system-config-firewall this would pull useless dependencies What I meant: Add a requirement for iptables-services to system-config-firewall-base, this is currently not there. what we (users) really need is iptables.service as it was and working /sbin/iptables-save /etc/sysconfig/iptables to lod the with whatever shell script generated /etc/sysconfig/iptables so satisfy over many years perfect working setups for (the same for iptables6.service) * firewalls * NAT * routing as example i have a large shellscript with the following start $IPTABLES -P INPUT DROP $IPTABLES -P FORWARD DROP $IPTABLES -F $IPTABLES -X CHAINS=`cat /proc/net/ip_tables_names 2/dev/null` for i in $CHAINS; do $IPTABLES -t $i -F; done echo Flush OK || echo Flush FAILED for i in $CHAINS; do $IPTABLES -t $i -X; done echo Clear OK || echo Clear FAILED for i in $CHAINS; do $IPTABLES -t $i -Z; done and ending with /sbin/iptables-save /etc/sysconfig/iptables after that any needed rules are added with iptables-command this script is distributed to a LOT of machines of any type at the begin it has basic rules for any machine (accept, block, reject) followed by a lot of if [ $HOSTNAME == hostname ]; then specific rules fi this is maintained on a staging server, distributed to any amchine and called with ssh root@host '/scirpts/iptables.sh for other networks / routers / nat-gateways outside the main network a fork of this thing exists, using over years grown knowledge and adds specific rules, mostly controlled by a lot of variables at the begin call this script does NOt interrupt connections it handles really a lot of specific filters it works like a charme these setups does not need firewalld at all nor do they need any dependency of GUI/TUI tools Yes, full ack. You will be able to use it after switching off firewalld.service and enabling iptables.service and ip6tables.service. I will add a script for switching from and to dynamic/static mode: switch-firewall -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how do I allow a service on an arbitrary local interface the firewalld way?
On 11/09/2012 05:21 AM, Matthew Miller wrote: I'm making a crude fake EC2 environment on my test machine, and as part of that, I need a web server listening on 169.254.169.254. I've bound this address to lo:0. How do I use firewall-cmd to allow http through? It's blocked by default. I thought I could do it with the interface=lo:0 argument, but that gives me Warning: ALREADY_ENABLED. And firewall-cmd --list-interfaces returns only 'wlan0' Add the interface to the default zone or to trusted, if you want to have full access: To add the interface to the default zone: firewall-cmd --add-interface=lo:0 To add the interface to the trusted zone: firewall-cmd --add-interface=lo:0 --zone=trusted As : was not allowed in interface names up to now, this is only possible with the GIT version and also soon with an updated firewalld package in Fedora. There doesn't appear to be any real documentation for firewall-cmd. The web page is just development plans, the help is a maze of BNF, and the man page is full of less-than-helpful stuff like: interface=interface Use an interface name. Man pages with more information and also examples are in the works. Where should I look to find out more? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
On 11/09/2012 03:33 PM, Matthew Miller wrote: https://fedoraproject.org/wiki/Features/firewalld-default We have an accepted feature for Firewalld to be the default in Fedora 18. The old scripts are primitive and can't handle dynamic environments very well, so having something new and modern is admirable. The lokkit family of GUI config tools is primative enough to be considered dangerous. And a lot of integration work has been done in NetworkManager, libvirt, and a bunch of other places. But, I think we should strongly consider pushing this to F19, because: - this turns out to be a big change! - there's little to no documentation Have you had a look at the man pages? - the UI is very confusing, with a large number of zones and no apparent way to configure those zones Go to the persistent view and you can configure zones, services and icmptypes. - toolset is not yet robust -- has funny things like `firewall-cmd --enable` enables *panic mode*. Nice find. You are the first to get this. Will work on it. - no way to run once and exit for cloud guests with *non-dynamic* firewall needs, and it's a non-trivial user of system resources You can use the old firewall environment for static firewall use cases. Everything is still there. Firewalld is using about 12M of memory (RES), produces only a small amount of wakeups ( 0.1) if idle. Where is the non-trivial use of system resources. The alternative is to enable it by default in some cases but not in others, but I think that's just confusing. We should wait until it's ready and then turn it on everywhere. I think this bug is illustrative of the problems we're going to see if we ship as-is: https://bugzilla.redhat.com/show_bug.cgi?id=869625. Stef isn't trying to anything crazy, but is both foiled by the lack of options and confused by the choices that are there. We're going to get a lot more bugs like this, and worse, unhappy users. libvirt is creating the firewall rules for guests - it is doing this with the old static model, where you loose these rules in case of other firewall changes, or with firewalld, but here changes are dynamic. The lack of documentation is really the showstopper here. If we had really good 1) hand-holding documentation and 2) technical documentation for admins, I'd be more willing to take the risk. (In an even more ideal world, the UI would be so well designed that the hand-holding documentation wouldn't be necessary.) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
On 11/09/2012 05:24 PM, Eric H. Christensen wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Nov 09, 2012 at 09:33:08AM -0500, Matthew Miller wrote: https://fedoraproject.org/wiki/Features/firewalld-default We have an accepted feature for Firewalld to be the default in Fedora 18. This replaces iptables and ip6tables? Perhaps I have had my head in the sand (I certainly haven't been looking around) but this is the first I've heard of a replacement for iptables. Has firewalld been tested as well as iptables has (which seems to be a fairly bullet-proof solution)? Please have a look at the feature list for F-18. firewalld replaces system-config-firewall/lokkit, and the iptables and ip6tables services, not the iptables package and command. The ip*tables services and also system-config-firewall/lokkit are still available and also usable after deactivation of the firewalld serice. With the latest request to move the services of iptables and ip6tables in a sub package, I will add a requirement to system-config-firewall for this. But, I think we should strongly consider pushing this to F19, because: ... - there's little to no documentation I'd happily help document it in the Fedora Security Guide if I could get the proper content or access to the developers. Heck, I'll even help write stand-alone documentation for this project if needed. I will provide content/help for this. The lack of documentation is really the showstopper here. If we had really good 1) hand-holding documentation and 2) technical documentation for admins, I'd be more willing to take the risk. (In an even more ideal world, the UI would be so well designed that the hand-holding documentation wouldn't be necessary.) +1 - -Eric Sparks -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJQnS4+AAoJEIB2q94CS7PRdGcP/1z5O5kgvHDX04E/6t3xhdWv w2JtwDC3zYc0KlASa+XFPlqFmvQUBngI7Esy3kJ8+mas+bFwVOftTRQhZz13mmfg C+eKe/rHtL2hEF/EDkWe23FSASrHdK6FNyotK7xxdfh3QYPGmavmFSvlETg6qUdS kkWRrTCtkro4EirO7KGbW7DDeuzcxqK6IHy6JStdevouwaTqJ/TtdCI2vYJKDTyg GkxQQwk00GCk7xox5dJq1jdpniVfpQ/pKAVb9BTuQYCaMCuqdv64xg6ggbkXi28T cIFkdKxNCBw0L5Ecwg3/d4y2OlTAJmBULsAQZ7piFKXFbHPb9CofxCypGSTn5cMw F9wnr/0geTw3UOxfi0OGNm2Wf0x2B9n7iyYZODxvihdoeg8OGbusPJr9viRYI7tA 47+/95ywXBTcAPxLwSCb3vXG2FImgnzwnaG/9xpKZk4dKAZcxQBxqlgDtBbilv8X zvr9ArmCG9hdEAojD66AKM5Qmzse+tPaAiDFecGBvlSN3/J2AOrTF9U64Akbkzg9 +uXkV3rk/DhP0JTLXvb8Aizbb9Y51PGO/G7KZH3tCYieaCQbkNdddNbIg3WI4kV1 AEGvDd30vDdAkl17UcguV6iwPwCP0tFs9GNcJRCEninL+/bQmVs2PcpYJ5+oPBsi vUc791SABXCttPkm1X/A =E0LH -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Attention, dependency fighters
On 11/08/2012 06:37 PM, Bill Nottingham wrote: Matthew Miller (mat...@fedoraproject.org) said: On Wed, Nov 07, 2012 at 07:56:30PM -0800, Adam Williamson wrote: long story short, it's firewalld. Its deps are pretty heavy for something that's supposed to be in minimal. I'm sure twoerner would welcome help in pruning the deps if it's possible. it should at least be possible for it not to depend on both pygobject2 and pygobject3, one would think :) Maybe we could have a release criterion which states that the minimal install doesn't have anything which pulls in the X libraries (or Wayland)? That's not a _completely_ arbitrary line in the sand. Probably the issue here is just a matter of what goes in what subpackage. Nod, this is more due to how pygobject3 is packaged rather than firewalld itself. Bill firewalld has been in base for F-18 alpha and now is in standard group after rework of the package groups. anaconda pulls it in directly to be able to configure the firewall. The firewall server only needs GLib, GObject and Gio from pygobject3, so if cairo support could be sub-packaged in pygobject3, we have a small requirement list: +dbus-python +ebtables +firewalld +gobject-introspection +libselinux-python +pygobject2 +pygobject3 +python-decorator +python-slip +python-slip-dbus pygobject2 is needed by python-slip, maybe we can get rid of this. gobject and gi.repository.GObject are exchangeable. I do not know about the libselinux-python requirement, but the package is fairly small. Would this requirement set be ok? Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [FYI] Motif finally opened under LGPL
Hello, On 10/25/2012 10:17 AM, Peter Lemenkov wrote: Hello All! Not so long after opening CDE they relicensed (Open)Motif under LGPL. http://sourceforge.net/projects/motif/ Time to rewrite everything with Motif! :) after more than one year of work with ICS and the Open Group it finally got released. BTW: I have submitted a review request for Motif 2.3.4, see https://bugzilla.redhat.com/show_bug.cgi?id=870049 If someone wants to make the review, we might get it in pretty fast. Regards. Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17, firewalld, avahi
On 04/17/2012 11:17 PM, Chris Murphy wrote: On Apr 17, 2012, at 2:32 PM, Al Dunsmuir wrote: On Tuesday, April 17, 2012, 4:15:53 PM, Chris Murphy wrote: On Apr 17, 2012, at 1:49 PM, Andreas Tunek wrote: I do not see anything in the f17 feature page describing any graphical configuration tool. But I also agree that gui configuratio is needed, otherwise it will probably be really difficult to do things like connect via ssh or share via rygel or other dlna server. http://fedoraproject.org/wiki/FirewallD#Graphical_Configuration_Tool firewall-config is the main configuration tool It also says is... but in spite of the use of the present tense, that tool is not available on the Fedora 17 Beta.? Negative. I speculate many or most people disable firewalld. This was an explicit recommendation during Virtualization Test Day. So it's not just the config tool that isn't getting as much testing as it otherwise would. For the LiveCD, it needs to be a GUI configurable, and work, because firewalld is enabled by default. I am working with libvirt upstream to get firewalld support in libvirt. There are patches for firewalld support in libvirt, but without firewalld reload support. The dbus code is not working corrytly in libvirt, currently. If reversion is going to occur back to iptables and its Firewall tool, slipping that in a final RC seems risky. That combo hasn't been tested since early alpha. And in effect neither firewall package is getting nearly as much testing before final. I feel that firewalld's updated man pages and GUI config tool need to appear by final TC1, or reversion should occur. The man pages and more documentation will be released in a new package this week. firewall-config will not be finished before F-17 GOLD. Chris Murphy Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17, firewalld, avahi
On 04/13/2012 07:13 PM, Chris Murphy wrote: On Mar 26, 2012, at 4:21 AM, Thomas Woerner wrote: firewalld-config is not finished, yet. I am working on it. This is still not in F17 beta RC4 which means it's not going to be in the beta at all. I'm a little mystified why firewalld would ship as the default firewall without the *primary* configuration tool being available for testing. firewall-cmd is irritating to use. man firewall-cmd and firewall-cmd -h return two different results. My SOP at the moment is having systemd stop and disable firewalld in order to actually get work done. firewall-config is the graphical config tool. firewall-cmd is the command line config tool. The man page for firewall-cmd is outdated. There will be an update package this week with new and also updated man pages. Is the plan still to ship firewalld as the default in F17 final? I personally think this needs to be regressed and give firewalld more time to bake. Chris Murphy Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17, firewalld, avahi
On 03/24/2012 10:09 PM, Chris Murphy wrote: Fedora-17-Beta-x86_64-Live-Desktop.iso http://fedoraproject.org/wiki/FirewallD suggests I should have firewall-config. The configuration tool firewall-config is the main configuration tool for the firewall daemon. But I'm not finding firewall-config. So unlike with iptables, where I had a GUI Firewall app, now I no longer have an easy or obvious way of altering the default behavior and I'm in effect stuck without ssh. Seems the missing firewall-config is probably an oversight, and it needs to be included on LiveCD installs, and default DVD installs as well. Chris Murphy firewalld-config is not finished, yet. I am working on it. Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17, firewalld, avahi
On 03/24/2012 10:09 PM, Chris Murphy wrote: Fedora-17-Beta-x86_64-Live-Desktop.iso http://fedoraproject.org/wiki/FirewallD suggests I should have firewall-config. The configuration tool firewall-config is the main configuration tool for the firewall daemon. But I'm not finding firewall-config. So unlike with iptables, where I had a GUI Firewall app, now I no longer have an easy or obvious way of altering the default behavior and I'm in effect stuck without ssh. Seems the missing firewall-config is probably an oversight, and it needs to be included on LiveCD installs, and default DVD installs as well. Chris Murphy Please use firewall-cmd for now. Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] Test Day: firewalld
Hello, today is firewalld test day. https://fedoraproject.org/wiki/Test_Day:2012-03-19_firewalld For testing please use a fully updated Fedora 17 installation (all testing packages applied). For test cases and more information please have a look at the test page. If you need assistance or if you have quesitions about firewalld, feel free to ask us on #fedora-test-day. Thanks, Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DHCPv6 *still* broken for F17 alpha
On 03/02/2012 11:31 PM, Tore Anderson wrote: * Tom Callaway On 03/02/2012 04:39 PM, Tore Anderson wrote: This one *most likely* works (it assumes /sbin/dhclient in Fedora will *always* use a link-local source address when building a DHCPv6 request. I believe that is the case, but I have not reviewed its source code to verify): ip6tables -A INPUT -p udp --dport 546 -d fe80::/64 -j ACCEPT Can you please confirm that in the source code? I agree that this seems like the better option. Hi again, I've been poking around in the ISC-dhcp code for a while now, but I think I don't have sufficient C skills to follow what is going on 100%. I *think* it doesn't specify the source address anywhere, leaving it up to either glibc or the kernel to pick one when the packet is put on the wire. The ff02::1:2 multicast address (All_DHCP_Relay_Agents_and_Servers) has the link-local scope, so if the entity doing source address selection (be it the kernel or glibc) implements RFC 3484 correctly, the link-local source should be chosen, due to the the prefer matching scope rule. (If that didn't come into play, the prefer longest common prefix rule would also have ensured the link-local address was used for the source.) On my own system, where the interface is configured both with a link-local address and a global address (from SLAAC) at the time DHCPv6 is invoked, the link-local address is being used (so the -d fe80::/64 restriction works for me). So, based on observed behaviour, my reading of the IETF standards, and the fact that I cannot find anything that would suggest otherwise in the ISC dhcp sources; my estimate is that it's95% certain that including -d fe80::/64 will work in all cases. Or, to put it another way, it's ∞ better than what we have today, and since I assume people would be more comfortable with including that particular restriction in an enabled-by-default ip6tables exception, I say go for it. If it turns out there's someone out there it won't work for, then we can consider changing the rule (or the DHCPv6 client). Best regards, For firewalld we added the dhcpv6-client service in the GIT repo and it is part of the 'work' and 'home' zone already. I will also add it to the 'public' zone (the default zone) and the 'internal' zone for the F-17 package. The dhcpv6-client service adds the rule -p udp --dport 546 -d fe80::/64 -j ACCEPT Regards, Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Notice: IPv6 breaking issues tentatively considered blocker for F17
On 03/10/2012 03:31 PM, Tore Anderson wrote: Regarding this bug in particular, I'll just note that it there is already a precedent. In a default Fedora installation, traffic to the DHCPv4 client (which is the same binary as the DHCPv6 client) is allowed from the entire internet. From a security standpoint, blocking only one of the two does not make much sense. At least not to me, and there has been no attempt at an explanation for any other viewpoint that I'm aware of. There are also a few other problems that prevent IPv6-only from working out of the box. I have also nominated those as release blockers: https://bugzilla.redhat.com/show_bug.cgi?id=538499#c65 https://bugzilla.redhat.com/show_bug.cgi?id=798697#c3 Also, I also understand that the ip6tables service might be replaced with firewalld in F17 (cf. https://fedorahosted.org/fesco/ticket/805). If so, that would probably make #591630 irrelevant, however firewalld has IPv6 problems all on its own (even more so than just breaking DHCPv6, *all* IPv6 connectivity is broken by default), see: https://bugzilla.redhat.com/show_bug.cgi?id=801182 I did not nominate this one as a blocker yet though, as I don't know if firewalld will indeed be made the default solution for F17. However, if it does, #801182 needs to be a release blocker as well. Best regards, With zone support in firewalld I'd like to start a discussion on the zones that should enable DHCPv6 client support. We have these zones: block all incoming connection requests blocked (rejected) dmz ssh enabled drop all incoming connecion requests dropped external ssh and masquerade enabled home ssh, ipp-client, mdns, samba-client, dhcpv6-client enabled internal ssh, ipp-client, mdns and sambla-client enabled publicssh enabled trusted all incoming connections allowed work ssh, ipp-client and dhcpv6-client enabled For now DHCPv6-client support is enabled in 'work' and 'home', but not in the default zone 'public'. Should we enable dhcpv6-client in the default zone and maybe others also? Thanks, Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DHCPv6 *still* broken for F17 alpha
On 03/01/2012 04:52 PM, Paul Wouters wrote: On Thu, 1 Mar 2012, Dan Williams wrote: On Wed, 2012-02-29 at 17:20 +0100, Tore Anderson wrote: * Jerry James Interesting. I'm seeing kind of the inverse problem: https://bugzilla.redhat.com/show_bug.cgi?id=771130. Could that be related to the issues discussed in this thread? Hard to tell, without (preferably debug-level) logs. I have the same problem you're describing occur in 0.9.2-1 (see bug #797524), but I've not seen it with 0.9.3-0.2.git20120215. 0.9.4 snapshots do not require both methods to complete (with either success or failure) before saying the machine is connected. Thus if IPv4 completes first, NM will say it's connected, and continue IPv6 in the background. And vice versa. But that does not yet address the dhcpv6 ip6tables ACCEPT rule that is missing right? There will be a dhcpv6 service entry for firewalld soon and later on also for system-config-firewall. Where how and when it will and could be enabled will be evaluated. Paul Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: service iptables save, systemctl, and unhelpful error messages
On 02/16/2012 03:22 AM, Emanuel Rietveld wrote: On 02/16/2012 02:06 AM, Jóhann B. Guðmundsson wrote: On 02/15/2012 11:09 PM, Emanuel Rietveld wrote: I propose the following script in /etc/init.d/iptables I propose you file a BUG against IPTABLES and put your proposal into that bug report then wait and see what Thomas has to say. I can only say, that I'd like to have a solution, and there has been some discussion about this some time ago. But the result was that it is not possible and/or allowed. JBG I did so. Thomas pointed out that complying with my request would be against the packaging guidelines and suggested this needs to be discussed at best on Fedora-devel. The addition of 'at best' in there leads me to believe that he is not especially interested in my proposal, but may be willing to add the wrapper script if I get wider support for it and/or get the packaging guidelines changed. I can not decide the way to go here. Also I can not change packaging guidelines. If I add the script to the package, I will get a message that this is not allowed. 'at best' meant that this is the best place for this discussion, because according to the guidelines I am not allowed add the script to the main package and therefore a user has to install an additional package to get the help message. This is not working. I tried to find another solution for this as I switched to systemd, but failed also. Presumably, getting the packaging guidelines changed involves a lot of people's attention - people who are generally already very busy, and do not really want to spend precious brain cycles and time on what is ultimately a minor improvement visible to only a small number of people. If packaging guidelines will not get modified, then I have no solution. Oh well, at least I tried. Thanks Emanuel Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Plan for tomorrow's FESCo meeting (2012-01-23 at 18UTC)
Here are two more in ReadyForWrangler state: https://fedoraproject.org/wiki/Features/firewalld-default https://fedoraproject.org/wiki/Features/network-zones Thanks, Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Features firewalld-default and network-zones
Hello, the features firewalld-default and network-zones will be postponed for Fedora-17. The features are not ready yet and also the integration into other projects. The network zone backend in NetworkManager is making progress, but the front ends are not done yet. Without the front ends (nm-applet, gnome-shell, kdenetworkmanager) the features are not usable and firewalld as the default firewall solution does not make sense either. The firewalld zone code will be integrated into firewalld shortly, but will be deactivated by default. This needs some more work also. The NetworkManager zone code will be sent upstream to initiate the integration process. Thanks in advance, Thomas Wörner Jiri Popelka -- Thomas Woerner Software EngineerPhone: +49-711-96437-310 Red Hat GmbH Fax : +49-711-96437-111 Hauptstaetterstr. 58 Email: Thomas Woerner twoer...@redhat.com D-70178 StuttgartWeb : http://www.redhat.de/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Features firewalld-default and network-zones
Hello Jaroslav, On 07/25/2011 05:04 PM, Jaroslav Reznik wrote: On Monday, July 25, 2011 04:43:37 PM Thomas Woerner wrote: Hello, Hi Thomas! the features firewalld-default and network-zones will be postponed for Fedora-17. The features are not ready yet and also the integration into other projects. The network zone backend in NetworkManager is making progress, but the front ends are not done yet. Without the front ends (nm-applet, gnome-shell, kdenetworkmanager) the features are not usable and firewalld as the default firewall solution does not make sense either. What's needed to be implemented in kde-nm to support firewalld? Are you in touch with upstream or it's upon us :) the support for network zones needs to be added to kde-nm and the other frontends as soon as the NetworkManager backend is ready and functional. There is no support for firewalld needed in the frontends; the NM backend is dealing with firewalld. Here is a list of proposed changes for the frontends: - A dialog to define the default network zones for wired and wireless connections for initial setup and also for configuration changes. - A zone selector for active connections in the primary UI. - A zone selector in the connection editor. - A way to enable and disable network zone support (by backend). But this is still to discuss - the where and how and look and feel. Jaroslav Thanks, Thomas PS: I should ask Jiri, as he sits in same cubicle ;-) The firewalld zone code will be integrated into firewalld shortly, but will be deactivated by default. This needs some more work also. The NetworkManager zone code will be sent upstream to initiate the integration process. Thanks in advance, Thomas Wörner Jiri Popelka -- Thomas Woerner Software EngineerPhone: +49-711-96437-310 Red Hat GmbH Fax : +49-711-96437-111 Hauptstaetterstr. 58 Email: Thomas Woerner twoer...@redhat.com D-70178 StuttgartWeb : http://www.redhat.de/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: firewalld - A firewall daemon with D-BUS interface providing a dynamic firewall (test version)
On 12/24/2010 11:45 PM, Colin Walters wrote: On Thu, Dec 23, 2010 at 11:03 AM, Thomas Woernertwoer...@redhat.com wrote: - A simple tray applet (firewall-applet) Actively deprecated; please consider other interfaces. In this case, I think a control panel module is just fine. Is there an interface to use control panel modules with other desktop environments and also window managers? An applet for a component like a firewall should be usable with more than one desktop environment. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
firewalld - A firewall daemon with D-BUS interface providing a dynamic firewall (test version)
Hello, as discussed some time ago, I worked on the proof of concept implementation of firewalld. FirewallD is a service daemon with a D-BUS interface that provides a dynamic managed firewall. For more information on firewalld, please have a look at: https://fedoraproject.org/wiki/FirewallD/ About this version: This is mostly the proof of concept implementation with some changes and is feature complete for F-15 as a firewalld preview version. It will not be enabled per default and will also not get installed per default. The system-config-firewall with static firewall model will still be the default firewall solution for Fedora 15. What this firewalld version can do: - It supports most of the firewall features system-config-firewall had, but there are three limitations: 1) custom firewall rule files (iptables save format) are not supported and most likely will never be, but there is support for custom rules (limited functionality). 2) sysctl changes for ip_forward are not done, yet. 3) There are no permanent firewall settings, this means that all settings are lost after a service restart or reboot. Permanent firewall settings will be added later on. - The firewall daemon manages the firewall dynamically. This means that changes are done without recreating the whole firewall. Also there is no need to reload all firewall modules anymore. Firewall helpers are loaded and unloaded if needed. - A simple tray applet (firewall-applet) shows the status of the public firewall and is makes it simple to enable and disable firewall services. The applet does not show firewall configuration settings done with the libvirt interface. - firewall-cmd is the command line client that makes it possible to enable, disable, query and list firewall features. firewall-cmd is also not able to show firewall settings of the libvirt interface. - There is an rule and chain interface for libvirt, but the PolicyKit policy is not in place, yet. What this version can not do (future features): - firewall-config, the firewall configuration utility, is not functional - System vs. User/Session configuration - Zone support - NetworkManager firewall rule support firewalld made it into a fedorahosted repo at: git://git.fedorahosted.org/git/firewalld.git The fedoraproject wiki page at https://fedoraproject.org/wiki/FirewallD/ exists and will get more updates soon. The feature request page for Fedora 15 is also up to date: https://fedoraproject.org/wiki/Features/DynamicFirewall#How_To_Test For test packages, please have a look at http://twoerner.fedorapeople.org/firewalld/ firewalld has a requirement for system-config-firewall-1.2.28. This version has checks for an active firewalld in the tools. Please have a look at http://koji.fedoraproject.org/koji/buildinfo?buildID=211013 for the Fedora 15 packages of this version. It is usable on fedora versions 15. How To Test - Install firewalld and firewall-applet - Start the firewalld service - Start the tray applet firewall-applet - Use firewall-cmd to enable for example ssh: firewall-cmd --enable --service=ssh - Enable samba for 10 seconds: firewall-cmd --enable --service=samba --timeout=10 - Enable ipp-client: firewall-cmd --enable --service=ipp-client - Disable ipp-client: firewall-cmd --disable --service=ipp-client - To restore your static firewall with lokkit again simply use: lokkit --enabled You can also use the D-BUS interface directly. This is required for libvirt (and later on also NetworkManager). The D-BUS interface documentation is work in progress and will be added later on. Comments and additional information is highly welcome. Thanks in advance, Thomas -- Thomas Woerner Software EngineerPhone: +49-711-96437-310 Red Hat GmbH Fax : +49-711-96437-111 Hauptstaetterstr. 58 Email: Thomas Woerner twoer...@redhat.com D-70178 StuttgartWeb : http://www.redhat.de/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firewall settings unworkable
On 10/06/2010 08:31 PM, Richard W.M. Jones wrote: Seems quite complex. What's wrong with a directory: /etc/iptables.d/ where RPMs like libvirt just drop the required additional rules (in a separate chain if you like) and restart the iptables service? It's low-tech but simple and it's all that libvirt needs. Rich. I have thought a lot about the iptables.d directory. It is a nice thing if your firewall is static and there are no dynamic elements like wireless networks or services or programs requesting to open a port and also if the rule representation would be non-ambiguous. Saving the rules with service ip*tables save is hard to do with this because you you have to check if the rules in the firewall match rules in one or more of the files to prevent to have double, triple, .. rules every time you are saving them. The biggest problem here is though that ip*tables are reformatting and also changing parameters from the external to the internal representation (see icmp types, marks, insert id's, addresses, .. ). If you are saving, then you will get the internal representation, which might be different to the one you have in the file. Therefore simple rule matching is impossible to decide if the rule is the same or not. You have to actively parse and compare every single parameter. Insert id's for example are completely lost in the internal representation. Using the ip*tables commands to add and remove rules is working, because it does not matter if you are using names or id's and so on, because it matches the internal representation in netfilter. Ciao, Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firewall settings unworkable
On 10/07/2010 02:20 AM, Genes MailLists wrote: On 10/06/2010 11:26 AM, Thomas Woerner wrote: 6) Compatibility Mode The current static firewall model will still be available for compatibility for users or administrators creating their own firewall. This deactivates the firewall service and also the D-BUS daemon. --- Comments and additional information is highly welcome. I hope by 'compatibility mode' you mean it is 'completely off' and there is no possibility of it touching the rules because its not running in any form. Its vital for those of us who have hand coded firewall rules that this is totally turned off and it is impossible for it to touch the rules. In my case, I have about 40,000 rules and I def don't want anything else mucking with them! Thanks - its an interesting idea and the default firewall could use some spiffing up for many use cases. Yes, the compatibility mode means that the dynamic daemon is disabled and the current system-config-firewall, ip*tables and ebtables services will still be availabe to be able to have an own and/or static firewall setup. The only question here is what the default should be in the furture. I think for desktop installations it should be the daemon and for servers the static model. Firstboot, installation time or first network usage is a good place to define this in my opinion. Ciao, Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firewall settings unworkable
I am currently working on a proof of concept implementation of a firewall daemon, that will support dynamic firewall management with a D-BUS interface. This implementation should be usable in some days and will feature the transition of the current firewall model to the dynamic version. It will provide the majority of features system-config-firewall has at the moment (services, ports, trusted, forward, icmp and masquerading), but will be limited to a command line client with D-BUS interface. Here is more information on planned and proposed features: Firewall Concepts - PROPOSAL 1) Firewall daemon The current firewall services are static and can not handle dynamic firewall changes. Also system, user and administrator preferences can not be incorporated easily. The separation of IPv4 and IPv6 firewall services makes all this even worse. The solution is to create a firewall service with a daemon, which is taking care of the firewall similar to NetworkManager that does this for network connections. The firewall daemon provides information about the current active firewall settings via D-BUS and also accepts firewall changes via D-BUS by using policykit authentication methods. The firewall daemon is acting as a single authority for firewall creation and management. Controlling and maintaining the firewall if there are several applications or daemons changing firewall rules and behavior independently will most likely make it impossible to have a sane firewall state. Support for additional firewall features like ebtables is needed to be able to support desktop and virtualizsation requirements. 2) Dynamic firewall The current static model does not allow to add or remove rules and to load or unload netfilter firewall helpers easily. Restarting the firewall completely is required. Also the order of rules is very important and the usage of the predefined INPUT and FORWARD rules chains only is not helping to solve this. The chains need to be separated. For example chains for services and ports, masquerading, port forwarding, icmp filtering and virtualization and custom rules. This makes it much more flexible, safe and robust. Adding a rule with the firewall daemon to one of these chains will most likely not interefere with rules of other chains. The order of the chains and how they are used is fixed and will not change. For the netfilter firewall helpers it is not that easy. Helpers are for example used for amanda, ftp, samba and tftp services. If one of these services gets disabled, then the helper has to get unloaded from the kernel. For some of the helpers this is only possible after all connections that are handled by the module are closed. Therefore connection tracking information is important here and needs to get into account. Adding support for conntrack connection handling is therefore needed here. It is possible to specify a timeout for a firewall service and also the other features. The service will be opened immediately and closed again after the defined period is over. This allows to accept new connections from unknown sources in the specified time frame. This will be very useful for UPNP, SNMP or NetBIOS for example to find printers or to share data with others. This mechanism is similar to the bluetooth handler in cell phones. 3) Network zones: Network security model The network security model specifies the default trust level of all connections and can be selected initially at installation time, firstboot or when the first network connection gets established. The model describes the trust level of the whole network environment, the host is connected to and also defines what to do with new connections. There are different initial models: - Home / Work - Public - Connection specific The home or work zone has the highest trust level. All incoming connections are allowed. The public zone on the other hand is fully untrusted. No incoming connection is allowed. The connection specific model requires that the user tunes the trust level of a connection according to the needs. The default is untrusted. The user or administrator is able to define new zones or adapt initial zones to change the behaviour according to their needs. Network connections can be bound to zones. The network security model makes it possible to have one trust level for all connections or to have several connections with different trust levels. The firewall has support for these zones and makes it possible that the user or admin can enable firewall features for zones. If a new or undefined network connection is enabled in NetworkManager, the firewall daemon gets informed about this via D-BUS and can set firewall rules accordingly. There are chains for all supported network zones 4) Port metadata information (proposed by Lennart Poettering) To have a port independent metadata information would be good to have. The current
Re: Licensing Guidelines Update - Please Read
On 07/07/2010 10:29 PM, Tom spot Callaway wrote: [twoerner] system-config-firewall: system-config-firewall-base-1.2.25-1.fc14.noarch system-config-firewall and system-config-firewall-tui both require system-config-firewall-base. system-config-firewall-base provides the COPYING file. Therefore no need for the others to provide it also... Thanks, Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FYI: NVR issues from f12 - f13
On 05/04/2010 11:21 PM, Mike McGrath wrote: Here's a list of f12 - f13 with unclean update paths based on srpm. I'll work with FES to to go through and get some builds out. Some might make it in to F13 final, some will go out as F13-updates. greater for f12: rawtherapee f12 = rawtherapee-3.0-0.20.a1.fc12.src f13 = rawtherapee-3.0-0.18.a1.fc13.src greater for f12: ipa f12 = ipa-1.2.2-3.fc12.src f13 = ipa-1.2.2-2.fc13.src greater for f12: eclipse-cdt f12 = 1:eclipse-cdt-6.0.1-8.fc12.src f13 = 1:eclipse-cdt-6.0.1-7.fc13.src greater for f12: lftp f12 = lftp-4.0.5-3.fc12.src f13 = lftp-4.0.5-2.fc13.src greater for f12: sos f12 = sos-1.9-3.fc12.src f13 = sos-1.9-1.fc12.src greater for f12: evolution-couchdb f12 = evolution-couchdb-0.3.4-1.fc12.src f13 = evolution-couchdb-0.3.2-2.fc13.src greater for f12: pothana2000-fonts f12 = pothana2000-fonts-1.3.2-2.fc12.src f13 = pothana2000-fonts-1.3.2-1.fc13.src greater for f12: iptstate f12 = iptstate-2.2.2-4.fc12.src f13 = iptstate-2.2.2-2.fc13.src Fixed in iptstate-2.2.2-4.fc13 - submitted for testing. greater for f12: emacs-goodies f12 = emacs-goodies-31.5-2.fc12.src f13 = emacs-goodies-31.4-1.fc13.src greater for f12: lirc f12 = lirc-0.8.6-6.fc12.src f13 = lirc-0.8.6-5.fc13.src greater for f12: fusecompress f12 = fusecompress-2.6-6.20100223git754bc0de.fc12.src f13 = fusecompress-2.6-5.fc13.src greater for f12: pure-ftpd f12 = pure-ftpd-1.0.29-2.fc12.src f13 = pure-ftpd-1.0.29-1.fc13.src greater for f12: vrq f12 = vrq-1.0.74-1.fc12.src f13 = vrq-1.0.72-1.fc13.src greater for f12: python-cssutils f12 = python-cssutils-0.9.6-1.fc12.src f13 = python-cssutils-0.9.5.1-6.fc12.src greater for f12: perl-IO-Compress-Bzip2 f12 = perl-IO-Compress-Bzip2-2.015-1.fc12.src f13 = perl-IO-Compress-Bzip2-2.005-6.fc12.src greater for f12: oprofile f12 = oprofile-0.9.6-5.fc12.src f13 = oprofile-0.9.6-2.fc13.src greater for f12: xinha f12 = xinha-0.96-0.1.b2.fc12.3.src f13 = xinha-0.96-0.1.b2.src greater for f12: pari f12 = pari-2.3.4-3.fc12.src f13 = pari-2.3.4-2.fc11.src greater for f12: php f12 = php-5.3.2-1.fc12.src f13 = php-5.3.1-3.fc13.src greater for f12: rb_libtorrent f12 = rb_libtorrent-0.14.10-1.fc12.src f13 = rb_libtorrent-0.14.8-2.fc13.src greater for f12: viking f12 = viking-0.9.92-1.fc12.src f13 = viking-0.9.9-1.fc12.src greater for f12: sbcl f12 = sbcl-1.0.35-3.fc12.src f13 = sbcl-1.0.35-1.fc13.src greater for f12: gsim85 f12 = gsim85-0.3-2.fc12.src f13 = gsim85-0.3-1.fc13.src greater for f12: fence-virt f12 = fence-virt-0.2.1-2.fc12.src f13 = fence-virt-0.2.1-1.fc13.src greater for f12: eclipse-slide f12 = eclipse-slide-1.3.14-2.fc12.src f13 = eclipse-slide-1.3.14-1.fc13.src greater for f12: anjuta f12 = 1:anjuta-2.28.2.0-1.fc12.src f13 = 1:anjuta-2.28.1.0-2.fc13.src greater for f12: terminator f12 = terminator-0.14-4.fc12.src f13 = terminator-0.14-3.fc13.src greater for f12: openwsman f12 = openwsman-2.2.0-3.fc12.src f13 = openwsman-2.2.0-1.fc13.src greater for f12: k3guitune f12 = k3guitune-1.01-6.fc12.src f13 = k3guitune-1.01-5.fc12.src greater for f12: dropwatch f12 = dropwatch-1.1-3.fc12.src f13 = dropwatch-1.1-2.fc13.src greater for f12: gedit-latex-plugin f12 = gedit-latex-plugin-0.2-0.5.rc3.fc12.src f13 = gedit-latex-plugin-0.2-0.4.rc2.fc13.src greater for f12: drehatlas-xaporho-fonts f12 = drehatlas-xaporho-fonts-1.0.3.3-3.fc12.src f13 = drehatlas-xaporho-fonts-1.0.3.3-2.fc13.src greater for f12: libgdl f12 = libgdl-2.28.2-1.fc12.src f13 = libgdl-2.28.1-2.fc13.src greater for f12: libotf f12 = libotf-0.9.9-4.fc12.src f13 = libotf-0.9.9-3.fc13.src greater for f12: libhugetlbfs f12 = libhugetlbfs-2.8-1.fc12.src f13 = libhugetlbfs-2.7-2.fc13.src greater for f12: scotch f12 = scotch-5.1.7-3.fc12.src f13 = scotch-5.1.7-2.fc13.src greater for f12: debmirror f12 = debmirror-20090807-1.fc12.src f13 = debmirror-2.4.3-1.fc13.src greater for f12: kanyremote f12 = kanyremote-5.11.4-1.fc12.src f13 = kanyremote-5.11.3-1.fc13.src greater for f12: bip f12 = bip-0.8.4-3.fc12.src f13 = bip-0.8.4-2.fc13.src greater for f12: maniadrive f12 = maniadrive-1.2-21.fc12.src f13 = maniadrive-1.2-19.fc13.src greater for f12: PyYAML f12 = PyYAML-3.09-5.fc12.src f13 = PyYAML-3.09-2.fc13.src greater for f12: rcssserver3d f12 = rcssserver3d-0.6.3-2.fc12.src f13 = rcssserver3d-0.6.3-1.fc13.src greater for f12: spring f12 = spring-0.81.2-1.fc12.src f13 = spring-0.81.1.3-1.fc13.src greater for f12: libhocr f12 = libhocr-0.10.17-5.fc12.src f13 = libhocr-0.10.17-4.fc13.src greater for f12: archmage f12 = archmage-0.2.4-2.fc12.src f13 = archmage-0.2.4-1.fc13.src greater for f12: dnssec-tools f12 = dnssec-tools-1.6-1.fc12.src f13 = dnssec-tools-1.5-5.fc13.src greater for f12:
