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 model with a static assignment of ports and protocols from /etc/services is not a good solution and is not reflecting current use cases. Ports in applications or services are dynamic and therefore the port itself does not describe the use case. This metadata information could be used to form simple rules for the firewall. Here are some examples: allow external access to file sharing applications or services allow external access to music sharing applications or services allow external access to all sharing applications or services allow external access to torrent file sharing applications or services allow external access to http web services The metadata information here could not only be application specific, but also a group of use cases. For example the "all sharing" group or the "file sharing" group could match all sharing or file sharing applications, for example torrent file sharing. These are examples, therefore it might be that they are not useful. There are two possible solutions to get metadata information in the firewall: The first is to add it to netfilter (kernel space). This has the advantage, that it can be used by everyone, but also limits the use. To get user or system specific information into account, all these need to be implemented in kernel space also. The other one would be to add this to a firewall daemon. These abtract rules could be used together with informations like the trust level of the network connections, the user decision to share with as specific person/host or the hard rule of the administrator to forbid sharing completely. The second solution would have the advantage that new metadata groups or changes in incorporation of trust levels, user preferences or administrator rules would not require to push a new kernel. Adding these kind of abtract rules to a firewall daemon would make it much more flexible. Even new security levels woule be easy to add without kernel updates. 5) User interaction mode This is a special mode of in the firewall the user or admin can enable. All requests of applications to alter the firewall are directed to the user to get notified and granted or denied. It is possible to set a time limit for the acceptance of a connection and to limit it to hosts, networks or connections. It can be saved to behave the same in the future without notification. An additional feature of this mode is direct external connection attempts on preselected services or ports to the user with the same features as the application initiated requests. The limitation on services and ports will also limit the amount of requests sent to the user. 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. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
