Hello Tomasz, ----- Original Message -----    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.    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. --- Regards    -Prasad http://feedmug.com

  Hi Mateusz, ----- Original Message -----    Yep, true.Individual zones for each type of network seems to offer choice and versatility from Firewalld. But a user could end up using the same zone for all networks, because it appears as the default one when doing the network <=> zone assignment in NetworkManager. I don't use NetworkManager so not sure how it works.    Hmmn, it should have been a package for user to install at will, rather than a replacement of an understandable firewall. Thanks. --- Regards    -Prasad http://feedmug.com

On 17.09.2013 15:02, Kevin Kofler 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. Mateusz Marzantowicz

On 09/20/2013 04:15 PM, Matthew Miller wrote: 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.

On 09/20/2013 02:15 PM, Matthew Miller wrote: Do you have list somewhere of python dependent code in the core/baseOS? JBG

On 09/20/2013 06:07 PM, Phil Knirsch wrote: A quick bit more info to that: the pygtk2 stuff came from a powerpc-utils package, so ignore that for now. The rest is really yum, authconfig and firewalld in the chain. So i agree with a focus on those 3 apps to be tackled in the near future, and i know that firewalld is geting a rewrite in C soon, see the same for yum via dnf. That only leaves authconfig, which should be doable as well (just needs someone actually doing it). Thanks & regards, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Manager Core Services | Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch <pknirsch(a)redhat.com&gt; Wankelstrasse 5 | Web: http://www.redhat.com/ D-70563 Stuttgart, Germany

On Fri, Sep 20, 2013 at 06:07:17PM +0200, Phil Knirsch wrote: [...] Oops I forgot that one. [...] It looks like a long list, but actually those are mostly leaf nodes pulled in by the others -- authconfig, firewalld, yum. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org&gt;

On Fri, Sep 20, 2013 at 10:15:33AM -0400, Matthew Miller wrote: dnf is written in Python, so I don't think that'll be possible. The roadmap for 2.0 is apparently going to involve porting to Python3, which will most likely help with the memory usage, but not with the installation size. luke

On Wed, 2013-09-25 at 21:04 +0200, Kevin Kofler wrote: ...it's not just a "wrapper". DNF have replaced yum's depsolver but ~90% of the code in yum *isn't* depsolving. To replace yum you still need to (re)write all the *other* parts that are written in Python. Like: * config file parser (reading and writing) * GPG key handling (importing keys, checking signatures, etc.) * mirrorlist handling (metadata/failover/etc, plus most of urlgrabber) * RPM utility functions (canonicalizing arches for multilib, etc.) * miscellaneous utilities (like "get_running_kernel_*") * yumdb support zif did all that (although it doesn't use hawkey/libsolv, so that's a bit of a problem), but you're still missing: * A plugin API * standard plugins (fastestmirror, langpacks, refresh-packagekit) * deltarpm support * history/transaction support On the bright side, there's a new C library for comps support: https://github.com/midnightercz/libcomps So if you actually wanted to write another yum replacement in C you could probably start with zif, port it to use libsolv and libcomps, fix up the CLI, and have yourself a functional prototype. Looking forward to seeing what you come up with! Good luck! -w

Mateusz Marzantowicz wrote: So when some innocent-looking guy is sitting in the café with a smartphone posing as an access point with an SSID of "MyHomeNet", will your Fedora laptop connect to it, switch to the Home zone, and assume that everybody on that network is friendly? -- Björn Persson Sent from my computer.

Le Mar 17 septembre 2013 11:33, Björn Persson a écrit : Does not matter if the firewall rules become complex enough no one will ever audit them and they become the malware-ridden black-boxes common in windows environments. (though systemd and gnome3 are taking the 'pile of overengineered rules no one checks' route fast) -- Nicolas Mailhot

    Hello, ----- Original Message -----    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.    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. --- Regards    -Prasad http://feedmug.com

Hello, On 09/16/2013 07:55 AM, P J P wrote: 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. This was not my decision. You can disable it in the zones if you do not want to have it. Regards, Thomas

On 09/17/2013 07:21 AM, P J P 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_firew... 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, Thomas

   Hi, ----- Original Message ----- What happens if an application/daemon/user edits firewall rules in a way that puts the user at risk? Isn't that possible?? --- Regards    -Prasad http://feedmug.com

  Hi, ----- Original Message -----   Sure. But user authentication is function of the task an application performs and not of the firewall rules it adds or removes. In most cases, user won't even know what firewall rules an application is going to add/edit/remove. Meaning if an authenticated application leaves user's machine vulnerable, that is always going to be a side-effect and not an intended one. Ex. Say I start virt-manager, it prompts me for authentication, I enter password and click [Ok]. It starts libvirtd in the background, creates interfaces, adds firewall rules etc. etc.  As a user looking at the GUI, I'm completely oblivious to what it is doing(or did) in the background. This side-effect design is what I think isn't a good idea. --- Regards    -Prasad http://feedmug.com

----- Original Message ----- Heh...just an  example, doesn't really happen like that, but not too far from it either. :) --- Regards    -Prasad http://feedmug.com

On 09/21/2013 12:22 AM, Chuck Anderson wrote: 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"

On 09/15/2013 08:52 PM, P J P wrote: https://bugzilla.redhat.com/show_bug.cgi?id=907375#c2 http://fedoraproject.org/wiki/Features/AvahiDefaultOnDesktop It is, yes. It had started as quite simple tool but bloated very fast because all the features we added recently. -- Jiri

Am 20.09.2013 15:59, schrieb Thomas Woerner: oh yeah, let us open some more ports as default to increase security especially for servcies like avahi which *can't* be disabled if you tend to look in the syslog which get cluttered if you mask it god save "iptables.service" such decisions are *plain wrong* someone can consider a desktop-firewall like on windows (not that i ever would use it) which *asks* at the first incoming connection - and before this is not possible it is *plain wrong* to open whatever port because it could be useful for someobody a fresh install should *never* have *any* port opened the is no "but" and no "if" - period and no i am not speaking for me - because i know what i am doing in context of networking - most users do not

On 09/20/2013 09:05 PM, P J P wrote: 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. 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. firewalld is not a desktop firewall in the first place. Regards, Thomas

On 09/24/2013 05:15 PM, P J P wrote: 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, Thomas

On Sat, 2013-09-21 at 03:05 +0800, P J P wrote: That's ironic: just yesterday - without having yet read this discussion - I used the firewalld on my laptop to lock down the 'public' zone to allow nothing at all (not mdns or ssh), make sure it was the default zone, then special-case the connection for my home wireless network to be in the 'home' zone. Took two minutes. I'd have no idea how the hell to do that with iptables. So, you're already wrong. :P -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

Thomas Woerner wrote: Anyone can broadcast an SSID. How does FirewallD authenticate the network connection? -- Björn Persson Sent from my computer.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Eric H. Christensen wrote: I guess you refer to using 802.1X with an EAP method that provides mutual authentication, authenticating both the supplicant and the authentication server to each other. As a test I opened the Network Manager connection editor and put my Ethernet connection in the home zone while connected to my home network which doesn't have 802.1X. The filtering rules were immediately changed. There were no protests and no warnings. Obviously nothing tries to ensure that only authenticated networks are put in a trusted zone. Network Manager uses this same connection for all Ethernet networks I connect to. I see no indication that the home zone wouldn't be used for other networks, if I hadn't already changed it back to "public". Perhaps an authenticated network would become a separate connection, but I estimate that approximately zero homes and smaller offices use 802.1X on wired networks. Given that many wireless home networks use WPA2 these days, but few if any wired home networks use 802.1X, it looks like with FirewallD wired connections may actually be *less* secure than wireless connections. I strongly suspect that many users put both their wired and wireless networks in the home zone when at home. Then when they go elsewhere, Wifi networks will be considered different connections and will be in the public zone by default, but any Ethernets they connect to will be treated as the home network, which many users probably don't realize. This difference may be temporary though. Sooner or later ISPs will be forced to start providing IPv6 to customers, and then NAT will no longer function as a firewall. It remains to be seen how home networks will evolve then. It may be that people are so used to being crippled by their NAT routers that they will buy home routers with zealous firewalls in them, blocking all incoming IPv6 traffic and disrupting peer-to-peer communication like NAT does. Or it may happen that homes and small offices finally get fully functional Internet. In the latter case link-layer encryption like WPA2 won't protect anything anymore, as all the computers will be addressable from the outside anyway, and then protocols designed for an isolated friendly network will be equally insecure on both wired and wireless networks. - -- Björn Persson Sent from my computer.

Eric H. Christensen wrote: Me? Other than address translation (a necessary evil) I use packet filters mostly to restrain crazy programs that open listening sockets for unknown reasons even though I don't use them for any kind of communication. There was for example some kind of Gnome daemon that popped up and started listening on an RTSP port just because I was playing music from the local disk through the local loudspeakers. Such behaviour is equally crazy on all networks, so I don't need firewall zones for that. Better ask those who think they need "home" and "work" zones what they're trying to achieve. That's not its primary purpose, no, but not having a public IP address is in practice much like being behind a really zealous firewall that only allows outgoing connections. People rely on that when they use naïve protocols at home, for example unencrypted or passwordless file and printer sharing protocols. I agree. As far as I know it's also supposed to prevent active attacks, not just passive eavesdropping. The underlying assumption is that your local wired network is protected by a firewall plus physical walls and locked doors, and that you have something insecure on your network that needs that protection. Then when you add a wireless link you have to prevent others from connecting to it and attacking your insecure stuff. That's what WPA2 is for. But if your firewall is just a side effect of your NAT, and IPv6 makes NAT obsolete, then your insecure stuff is no longer protected. And I don't use those protocols, but other people apparently do. Why else would there be a need for WPA2 or firewall zones? -- Björn Persson Sent from my computer.

On 20.09.2013 22:23, Björn Persson wrote: FirewallD is not responsible for such authentication/AP validation. Firewall as such is not meant to assure you're connecting to where you want. Mateusz Marzantowicz

On Sat, Sep 21, 2013 at 12:40:15AM +0200, Björn Persson wrote: I haven't looked, but I assume that it's not actually the SSID that makes them unique but rather done by NetworkManager UUID. See <https://wiki.gnome.org/NetworkManagerConfiguration>;. So, the attack I think you're talking about would be someone making a network with the same SSID as one you trust. NetworkManager won't automatically connect to that, and it even if you do, it won't automatically put them in the same zone. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org&gt;

On 09/21/2013 12:08 AM, Mateusz Marzantowicz wrote: NM tells firewalld where to put the interfaces bound to a connection. firewalld is not doing anything with SSIDs and other connection related information. Thomas