Hello,
here are the latest changes for system-config-firewall for F-9+:
The usage of --port=<port>:<proto> for lokkit will open up this port and not a service using this port anymore. To enable a service you have to use the new --service=<name> option. There are no magic default open services. You have to open up the services, you want to use. The interim options --no-X; X in ["ipsec", "mdns", "ipp"] are obsolete now.
To setup a new firewall, you can use the new --default=<name> configuration option as a start: server : ssh is enabled desktop : ipsec, mdns and ipp are enabled
These changes for lokkit also affect the kickstart firewall configuration.
There is an utility to convert existing configurations, which will be used automatically while updating the package.
Thanks, Thomas
On Wed, 2008-01-16 at 18:52 +0100, Thomas Woerner wrote:
Hello,
here are the latest changes for system-config-firewall for F-9+:
The usage of --port=<port>:<proto> for lokkit will open up this port and not a service using this port anymore. To enable a service you have to use the new --service=<name> option. There are no magic default open services. You have to open up the services, you want to use. The interim options --no-X; X in ["ipsec", "mdns", "ipp"] are obsolete now.
To setup a new firewall, you can use the new --default=<name> configuration option as a start: server : ssh is enabled desktop : ipsec, mdns and ipp are enabled
IpSec and IPP as services don't sound very much like desktop applications.
On Thu, Jan 17, 2008 at 12:07:52AM +0000, Bastien Nocera wrote:
On Wed, 2008-01-16 at 18:52 +0100, Thomas Woerner wrote:
Hello,
here are the latest changes for system-config-firewall for F-9+:
The usage of --port=<port>:<proto> for lokkit will open up this port and not a service using this port anymore. To enable a service you have to use the new --service=<name> option. There are no magic default open services. You have to open up the services, you want to use. The interim options --no-X; X in ["ipsec", "mdns", "ipp"] are obsolete now.
To setup a new firewall, you can use the new --default=<name> configuration option as a start: server : ssh is enabled desktop : ipsec, mdns and ipp are enabled
IpSec and IPP as services don't sound very much like desktop applications.
Definitely. Also mdns enabled on desktop doesn't make sence for me. I think only ssh will be enabled on both server and desktop.
Adam
Adam Tkac schrieb:
IpSec and IPP as services don't sound very much like desktop applications.
They do if you have a desktop machine sharing a printer. If the system-config-printer tool would open up the IPP port automatically when you share a printer that would be fine though.
Definitely. Also mdns enabled on desktop doesn't make sence for me. I think only ssh will be enabled on both server and desktop.
DNS-SD over mDNS is used by Avahi for service discovery. Especially on a desktop/laptop you want to see the services other machines announce on the network like file shares (someone going to solve the firewall issue here?), VNC, printer etc.. I'd consider Avahi to be important for the "just works" network experience.
Tim
On Thu, 2008-01-17 at 17:13 +0100, Tim Niemueller wrote:
Adam Tkac schrieb:
IpSec and IPP as services don't sound very much like desktop applications.
They do if you have a desktop machine sharing a printer. If the system-config-printer tool would open up the IPP port automatically when you share a printer that would be fine though.
Does the "sharee" also need the IPP ports open? So a user would need to explicitly set "show printers shared by other systems" in s-c-printers--it couldn't be the default.
ISTR some discussion in the past of why it was a bad idea for s-c-printers to open and close the ipp and lpr ports. (Don't have a link handy, but I think there was a BZ about this issue).
Definitely. Also mdns enabled on desktop doesn't make sence for me. I think only ssh will be enabled on both server and desktop.
DNS-SD over mDNS is used by Avahi for service discovery. Especially on a desktop/laptop you want to see the services other machines announce on the network like file shares (someone going to solve the firewall issue here?), VNC, printer etc.. I'd consider Avahi to be important for the "just works" network experience.
Tim
Matthew Saltzman schrieb:
On Thu, 2008-01-17 at 17:13 +0100, Tim Niemueller wrote:
Adam Tkac schrieb:
IpSec and IPP as services don't sound very much like desktop applications.
They do if you have a desktop machine sharing a printer. If the system-config-printer tool would open up the IPP port automatically when you share a printer that would be fine though.
Does the "sharee" also need the IPP ports open? So a user would need to explicitly set "show printers shared by other systems" in s-c-printers--it couldn't be the default.
The one who shares has to have the ports open for others to be able to open a connection.
For the "Show printers shared by other systems" you need to have udp:631 open or mDNS (not currently the default to use mDNS, but cups broadcast is used instead.
Tim
I just realized that my previous email was rather short.
The current setup for printing and mDNS is perfect for our desktop machines. Let me give you a few impressions of the scenario why it fits so well:
We have a central Fedora-based print-server. This uses cups broadcast messages to announce printers. A freshly installed desktop or laptop with udp:631 open will catch these messages and have the printer available, no configuration needed at all! So this port has to be open on the clients to get these auto-configure messages!
On our network we make use of mDNS. For example our robots announce there services on the network. So in the control application you can just choose any of the currently available robots and start working, no typing of a robot name needed. For servicing it is also good to see VNC hosts in vinagre. No typing, it just works.
About IPSec I'm not completely sure. But we are using a Cisco VPN Concentrator with vpnc. I don't know for sure atm if that is tunneled via UDP or if this needs AH/ESP at all. This should be investigated as this is a service provided by default via NetworkManager-vpnc!
So I think having these ports open on a freshly installed desktop in fact makes a lot of sense, because it complements the "just works" ambitions the desktop has. For the IPSec more investigation would be needed if the protocols actually need to be open to establish a client connection.
Tim
On Jan 16, 2008 7:07 PM, Bastien Nocera bnocera@redhat.com wrote:
IpSec and IPP as services don't sound very much like desktop applications.
IPSec sounds reasonable since users may be using a VPN client in order to access a corporate or remote network. If not enabled by default, there needs to be something easy in s-c-firewall to enable it, since making IPSec work is a non-trivial endeavor. In the 'server' profile, though - it's absolute rubbish. If someone wants to run a VPN server, they should know enough about it to configure the firewall appropriately :)
On Thu, Jan 17, 2008 at 12:48:27PM -0500, Jon Stanley wrote:
On Jan 16, 2008 7:07 PM, Bastien Nocera bnocera@redhat.com wrote:
IpSec and IPP as services don't sound very much like desktop applications.
IPSec sounds reasonable since users may be using a VPN client in order to access a corporate or remote network. If not enabled by default, there needs to be something easy in s-c-firewall to enable it, since making IPSec work is a non-trivial endeavor. In the 'server' profile, though - it's absolute rubbish. If someone wants to run a VPN server, they should know enough about it to configure the firewall appropriately :)
I think you don't need open ports for VPN clients. State firewall should take care about such situation, doesn't?
Adam
On Thu, 2008-01-17 at 19:06 +0100, Adam Tkac wrote:
I think you don't need open ports for VPN clients. State firewall should take care about such situation, doesn't?
In the case of IPSec, it is implemented as a distinct protocol directly on top of IP, so no. It does not run over TCP or UDP.
On Wed, 2008-01-16 at 18:52 +0100, Thomas Woerner wrote:
Hello,
here are the latest changes for system-config-firewall for F-9+:
The usage of --port=<port>:<proto> for lokkit will open up this port and not a service using this port anymore. To enable a service you have to use the new --service=<name> option. There are no magic default open services. You have to open up the services, you want to use. The interim options --no-X; X in ["ipsec", "mdns", "ipp"] are obsolete now.
To setup a new firewall, you can use the new --default=<name> configuration option as a start: server : ssh is enabled desktop : ipsec, mdns and ipp are enabled
These changes for lokkit also affect the kickstart firewall configuration.
There is an utility to convert existing configurations, which will be used automatically while updating the package.
I don't think it's a good default to have IPP disabled. The cupsd process already binds to localhost by default, and only binds to '*' when a printer is explicitly shared by the user.
As for RPC services binding to the IPP port instead -- well, this is a bug that needs to be fixed regardless. Whether it's done with SELinux policy, or with a port reservation daemon, or with portmap/glibc hacks, I don't mind.
It would be differnet if there were a mechanism that system-config-printer could use to request that the IPP port be opened (with user approval), perhaps based on PolicyKit. The truth is that there is no such mechanism, even though I have repeatedly asked for it. (No, lokkit is not sufficient: it needs to be something that a non-root user application can request, as system-config-printer will not run as root in the future.)
Until that mechanism is provided, blocking the IPP port will make the user experience of sharing printers quite a lot worse, and will probably lead to people disabling the firewall altogether in the same way they have previously disabled SELinux.
Just my humble opinion, Tim. */
devel@lists.stg.fedoraproject.org
-
Adam Tkac -
Bastien Nocera -
Callum Lerwick -
Jon Stanley -
Matthew Saltzman -
Thomas Woerner -
Tim Niemueller -
Tim Waugh