11:52 a.m.
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
6:07 p.m.
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.
7:12 a.m.
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, Red Hat, Inc.
10:13 a.m.
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
--
Tim Niemueller <tim(a)niemueller.de> www.niemueller.de
=================================================================
Imagination is more important than knowledge. (Albert Einstein)
1:05 p.m.
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
Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs
2:24 a.m.
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
--
Tim Niemueller <tim(a)niemueller.de> www.niemueller.de
=================================================================
Imagination is more important than knowledge. (Albert Einstein)
2:40 a.m.
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
--
Tim Niemueller <tim(a)niemueller.de> www.niemueller.de
=================================================================
Imagination is more important than knowledge. (Albert Einstein)
11:48 a.m.
On Jan 16, 2008 7:07 PM, Bastien Nocera <bnocera(a)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 :)
12:06 p.m.
On Thu, Jan 17, 2008 at 12:48:27PM -0500, Jon Stanley wrote:
On Jan 16, 2008 7:07 PM, Bastien Nocera <bnocera(a)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
--
Adam Tkac, Red Hat, Inc.
12:23 p.m.
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.
5:06 p.m.
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.
*/
5902
days inactive
5952
days old
10 comments
8 participants
participants (8)
-
Adam Tkac -
Bastien Nocera -
Callum Lerwick -
Jon Stanley -
Matthew Saltzman -
Thomas Woerner -
Tim Niemueller -
Tim Waugh