Vincent Untz wrote:

Le lundi 01 août 2011, à 14:03 +0200, Ludwig Nussel a écrit :

...

Vincent Untz wrote:

...

I wonder: did anybody look at integrating firewalld (a firewall service daemon with D-BUS interface managing a dynamic firewall), or proposing a similar dbus API for what we have?

Like this? http://lizards.opensuse.org/2009/07/10/1453/ http://lizards.opensuse.org/2009/08/28/firewall-zone-switcher-updated/

I'm unsure if this covers the exact same use case; see below for an example of how firewalld is being used.

...

...

I'm starting to see some applications making use of the dbus API,

For what purpose?

...

and it does improve user experience to have that.

What exactly?

For instance, when configuring printers, the tool can open the mdns, ipp, ipp-client and samba-client ports for 5 minutes and probe the network (ports will get closed after the 5 minutes). And if the user chooses to use a printer using one of those ports, the tool will permanently open the port.

Well, I could implement something like that for SuSEfirwall2/fwzs (using service definitions instead of ports though) but I'm not sure it's good behavior anyways. Users are not supposed to punch holes in the external zone just because they wanted to print once. That would permanently expose cupsd after all. It would be better to switch to a trusted zone that allows e.g. printing in the first place instead. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On 08/01/2011 01:04 AM, doiggl@velocitynet.com.au pecked at the keyboard and wrote: You have hi-jacked an existing email thread and may not get a response to your question. PLEASE, DoNot hit reply to a message and simply change the "Subject" line to send a message to this list, that is thread hi-jacking. There are settings in the headers of the emails (in this case: In-Reply-To: <4E36A37C.7020608@suse.de>) that help people "group" emails into "threads" so that we can keep a specific subject matter together. If you start a message on this list please start with a fresh email by using your compose button instead of reply. -- Ken Schneider SuSe since Version 5.2, June 1998 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Le lundi 01 août 2011 à 16:28 +0200, jdd a écrit :

Le 01/08/2011 15:00, Ludwig Nussel a écrit :

...

Well, I could implement something like that for SuSEfirwall2/fwzs (using service definitions instead of ports though) but I'm not sure it's good behavior anyways. Users are not supposed to punch holes in the external zone just because they wanted to print once.

it's somewhat necessary only for printers detection and no more after that

Not only for printers. We have several locations in Yast which states "you might need to lower / punch firewall for this autodetection to work". It would be better for an usuability PoV for Yast to talk to the firewall and punch it just for the autodetection. -- Frederic Crozat SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Le mardi 02 août 2011 à 08:54 +0200, Ludwig Nussel a écrit :

Frederic Crozat wrote:

...

Le lundi 01 août 2011 à 16:28 +0200, jdd a écrit :

...

Le 01/08/2011 15:00, Ludwig Nussel a écrit :

...

Well, I could implement something like that for SuSEfirwall2/fwzs (using service definitions instead of ports though) but I'm not sure it's good behavior anyways. Users are not supposed to punch holes in the external zone just because they wanted to print once.

it's somewhat necessary only for printers detection and no more after that

Not only for printers. We have several locations in Yast which states "you might need to lower / punch firewall for this autodetection to work". It would be better for an usuability PoV for Yast to talk to the firewall and punch it just for the autodetection.

The need for that will mostly vanish as soon as network connections (rather then network interfaces) have firewall zones attached. When connecting to a new network NM would ask whether you are connected to e.g. your home network or some untrusted public one. The former choice would just map to the internal zone ie no filtering, therefore no problems.

Except : - it is not there yet - we should still be installing and enabling a firewall by default, even the one in internal zone : a lot of home users are currently using DSL / cable modem / routers which are "protecting" them with NAT but as soon as the NAT goes down (restarting the modem in factory setting) or with IPv6 becoming more and more prevalent, relying on internal zone isn't a good idea (for a company network, I agree it is "safe"). - current yast tools behavior is still screaming "I'm broken, unbroke me to get the function you want", from a usability PoV. -- Frederic Crozat SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Le mardi 02 août 2011 à 10:55 +0200, Ludwig Nussel a écrit :

Frederic Crozat wrote:

...

Le mardi 02 août 2011 à 08:54 +0200, Ludwig Nussel a écrit :

...

Frederic Crozat wrote:

...

Le lundi 01 août 2011 à 16:28 +0200, jdd a écrit :

...

Le 01/08/2011 15:00, Ludwig Nussel a écrit :

...

Well, I could implement something like that for SuSEfirwall2/fwzs (using service definitions instead of ports though) but I'm not sure it's good behavior anyways. Users are not supposed to punch holes in the external zone just because they wanted to print once.

it's somewhat necessary only for printers detection and no more after that

Not only for printers. We have several locations in Yast which states "you might need to lower / punch firewall for this autodetection to work". It would be better for an usuability PoV for Yast to talk to the firewall and punch it just for the autodetection.

The need for that will mostly vanish as soon as network connections (rather then network interfaces) have firewall zones attached. When connecting to a new network NM would ask whether you are connected to e.g. your home network or some untrusted public one. The former choice would just map to the internal zone ie no filtering, therefore no problems.

Except : - it is not there yet - we should still be installing and enabling a firewall by default, even the one in internal zone : a lot of home users are currently using DSL / cable modem / routers which are "protecting" them with NAT but as soon as the NAT goes down (restarting the modem in factory setting) or with IPv6 becoming more and more prevalent, relying on internal zone isn't a good idea (for a company network, I agree it is "safe").

Let's accept your assumption that home routers would actually route all traffic into your network for a moment. That would mean opening some port, even for a little while is even more wrong. You'd expose your cups/avahi/rpc ports not only to the local network but the whole internet! So you'd have to restrict access to your local IP range at which point things get difficult to squeeze into a usable UI. Esp with v6 where you get multiple, dynamically assigned and potentially even changing prefixes depending on connectivity (e.g. ULAs if router is offline).

So either the router takes care of filtering traffic or the network really is untrusted in which case you don't want to suggest the user to open ports.

From what I see, such routers aren't common in SOHO market (and I'm not sure they will be in the near future). And I'm not convinced explaining those concepts to average users (or even a SOHO admin) will be successful.

...

- current yast tools behavior is still screaming "I'm broken, unbroke me to get the function you want", from a usability PoV.

Well, feel free to file bugs against yast modules that are broken in that regard. No need to wait for firewalld.

Ok, I'll open bug reports for those. -- Frederic Crozat SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Tue, Aug 02, 2011 at 11:11:21AM +0200, Frederic Crozat wrote:

Le mardi 02 août 2011 à 10:55 +0200, Ludwig Nussel a écrit : [ 8< ]

...

Let's accept your assumption that home routers would actually route all traffic into your network for a moment. That would mean opening some port, even for a little while is even more wrong. You'd expose your cups/avahi/rpc ports not only to the local network but the whole internet! So you'd have to restrict access to your local IP range at which point things get difficult to squeeze into a usable UI. Esp with v6 where you get multiple, dynamically assigned and potentially even changing prefixes depending on connectivity (e.g. ULAs if router is offline).

So either the router takes care of filtering traffic or the network really is untrusted in which case you don't want to suggest the user to open ports.

From what I see, such routers aren't common in SOHO market (and I'm not sure they will be in the near future). And I'm not convinced explaining those concepts to average users (or even a SOHO admin) will be successful.

IPv6 enabled Integrated Access Devices (IAD) are more and more common. Also more and more Internet Service Providers (ISP) have v6 on the agenda. For Germany they're also driven by the decision of Deutsche Telekom to offer v6 to all customers till end of 2011. Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany

Frederic Crozat wrote:

Le mardi 02 août 2011 à 14:15 +0200, Lars Müller a écrit :

...

On Tue, Aug 02, 2011 at 11:11:21AM +0200, Frederic Crozat wrote:

...

Le mardi 02 août 2011 à 10:55 +0200, Ludwig Nussel a écrit : [ 8< ]

...

Let's accept your assumption that home routers would actually route all traffic into your network for a moment. That would mean opening some port, even for a little while is even more wrong. You'd expose your cups/avahi/rpc ports not only to the local network but the whole internet! So you'd have to restrict access to your local IP range at which point things get difficult to squeeze into a usable UI. Esp with v6 where you get multiple, dynamically assigned and potentially even changing prefixes depending on connectivity (e.g. ULAs if router is offline).

So either the router takes care of filtering traffic or the network really is untrusted in which case you don't want to suggest the user to open ports.

From what I see, such routers aren't common in SOHO market (and I'm not sure they will be in the near future). And I'm not convinced explaining those concepts to average users (or even a SOHO admin) will be successful.

IPv6 enabled Integrated Access Devices (IAD) are more and more common.

Also more and more Internet Service Providers (ISP) have v6 on the agenda. For Germany they're also driven by the decision of Deutsche Telekom to offer v6 to all customers till end of 2011.

Agreed (my own ISP Free.fr is one of the first big ISP to enable IPv6 on its IAD years ago) but I'm not sure those IAD will have filtering capabilities for IPv6.

Well, I seriously hope so. While we can come up with creative firewall solutions for openSUSE other devices found in home networks certainly wouldn't have them. After all nowadays not only printers have network connectivity themselves but also TV's, radios and even cameras. I doubt Joe Average expects them to be hack^Wreachable from the Internet by default. It's the job of the router to prevent that. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Hello, On Aug 2 12:32 jdd wrote (excerpt):

We don't speak opening the internet router firewall, but the client station firewall. ... my ISP box have two interfaces: extenal (to the ISP server in the phone company building) and internal (my private network and the printer)

I assume that "private network" also means "trusted network". If I understand you correctly, I wonder why you need a firewall on client stations in an trusted internal network? In other words:

From what do you like to protect client stations in a trusted network?

Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Aug 2 14:37 jdd wrote (excerpt):

Le 02/08/2011 14:21, Johannes Meixner a écrit :

...

If I understand you correctly, I wonder why you need a firewall on client stations in an trusted internal network?

the wiki page quoted in the beginning say that it's always better to have one

Yes, http://en.opensuse.org/SDB:CUPS_and_SANE_Firewall_settings reads "to be on the safe side ... when whatever kind of server process was started by accident" but there is also -------------------------------------------------------------------- If your host is connected only to a trusted internal network where a dedicated firewall machine protects the whole internal network, you may switch off the firewall on your host. ... If your router-box supports private IP addresses together with NAT (and if there is no security flaw in the router-box), your hosts are in a trusted internal network where the the router-box is a dedicated firewall machine which protects your whole internal network so that you may even switch off the firewall on your hosts (provided you trust your router-box). ... When the CUPS print server process is the only server process which runs on the workstation, opening its IPP port 631 removes effectively any firewall protection from the workstation. -------------------------------------------------------------------- I was asking "from what do you like to protect client stations in a trusted network?" I meant against which actual threats (describe some examples please) do you like to protect your client stations when you run a firewall in your trusted network but open ports for the services which you use in your trusted network? Doing this removes effectively any firewall protection so that there is no reason to have the firewall at all. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer

Hello Vincent, On Aug 3 09:07 Vincent Untz wrote (excerpt):

Le mercredi 03 août 2011, à 09:03 +0200, Johannes Meixner a écrit :

...

When the CUPS print server process is the only server process which runs on the workstation, opening its IPP port 631 removes effectively any firewall protection from the workstation.

This is assuming that there is no non-root processes opening ports above 1024, which is not necessarily true.

I do not understand what you mean. I meant: When a "whatever" server process is the only server process which runs on the workstation, opening its port removes effectively any firewall protection from the workstation. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer

Hello, On Aug 3 09:41 Vincent Untz wrote (excerpt):

My point is that you cannot assume it's the only server process

Of course. http://en.opensuse.org/SDB:CUPS_and_SANE_Firewall_settings ----------------------------------------------------------------------- ... to be on the safe side you should not switch off the firewall because it will protect your host against unwanted access via network when whatever kind of server process was started by accident. In contrast if one or more server processes are running on your host and you open their matching ports in the firewall, you remove any firewall protection from your host because you only need a firewall to protect running server processes against unwanted access via network. ----------------------------------------------------------------------- Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Hello, On Aug 2 18:13 Rob Davies wrote (excerpt):

One incident that comes from personal experience, was in a "trusted" company network. Basically I got port scanned from the Internet Gateway host

If you have the ports open in the firewall for the services which you use in your internal network, the firewall would not help you against a port scan or against any kind of attack regarding the services which you use in your internal network. If you use services in your internal network, you cannot protect them with firewalls inside your internal network. You can only protect your whole trusted network with a firewall at the borderline of your trusted network. If the protection at the borderline fails you are basically doomed. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On 3 August 2011 08:31, Johannes Meixner wrote:

On Aug 2 18:13 Rob Davies wrote (excerpt):

...

One incident that comes from personal experience, was in a "trusted" company network. Basically I got port scanned from the Internet Gateway host

If you have the ports open in the firewall for the services which you use in your internal network, the firewall would not help you against a port scan or against any kind of attack regarding the services which you use in your internal network.

If you use services in your internal network, you cannot protect them with firewalls inside your internal network.

You can only protect your whole trusted network with a firewall at the borderline of your trusted network.

If the protection at the borderline fails you are basically doomed.

Actually I arranged to explicitly enable host IP addresses requiring access, detecting "unauthorised" accesses. Furthermore I took advantage of the subnetting. Resigning oneself to "being doomed" is not a practical option, it certainly won't enhance your reputation with the managers who allocate the department budgets.. You can for instance arrange for a peer's DNS or NTP server UDP packets to pass, but generally block UDP on that interface as illegitimate. There is a general problem with idea of "trusted", it is far too black & white when reality hits. BTW Someone mentioned ssh, sshd can listen on alternative ports to 22, that seems actually a wise step from the ssh port probing I've seen. Rob -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On 3 August 2011 13:03, Johannes Meixner wrote:

I wonder why you seem to use firewalls inside your internal network to do this (i.e. with firewalls running on each host in the internal network)?

Why don't you do this with a firewall at the borderline of your internal network (i.e. with a dedicated firewall machine that protects your whole internal network)?

If a malicious user is inside your internal network neither explicit IP address requirements nor subnetting nor blocking what goes into your internal network helps.

The problem seems to be you are thinking of "firewall", whereas I answered a question about why you may want to filter packets or restrict access to services, in what is meant to be a "trusted" network. If you are in a large corporate network, then other people in other departments may be in charge of the corporate Internet "firewall", you cannot "balkanise" physically and branch offices require connection to services; because the infrastructure is shared for cost, flexibility & practical reasons. Modems may be less common now, but such was a possibility for subverting a corporate firewall, perhaps VPN's are more common now a days. The "trusted" vs "external" is as I think I said before too black & white and fails in real world situations, where not every employee is impeccable and departments can have conflicts of interest. For example one department may be spun off and sold to commercial rival of another part of the corporation. Furthermore one department may minimise disruption, whereas another that's open and poorly administered may be completely compromised. These are things I have personally experienced, it's the real world. Rob -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Monday, August 08, 2011 04:35:22 PM doiggl@velocitynet.com.au wrote:

Hello There seems to be unresolvable statuses on all live cd builds [1] ....

Wrong thread Glenn :) Changing topic (subject line) will not change "In-Reply-To:" field based on "Message-ID: " of previous message, which are parts of message header that is used by mail programs and in regular workflow is not editable by users. The result is that KMail, and any other client programs that support threading, will include your email in a thread: "opensuse-factory] Integration of firewalld?" instead to open a new thread. What to do? We have answer to this and few other useful things, collected in a wiki article: http://en.opensuse.org/openSUSE:Mailing_list_netiquette Questions, comments, or ideas how to improve mail list workflow, can be discussed on opensuse-project mail list. The same for wiki article is welcome on its discussion page: http://en.opensuse.org/openSUSE_talk:Mailing_list_netiquette -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Tuesday, August 02, 2011 01:28:00 AM Johannes Meixner wrote:

Hello,

On Aug 1 16:42 Frederic Crozat wrote (excerpt):

...

We have several locations in Yast which states "you might need to lower / punch firewall for this autodetection to work".

I don't know the details but from my point of view each such location could be a security bug in YaST. I assume it depends on how excactly it is implemented whether or not YaST suggests (or even urges) that the user should remove his current protection.

...

It would be better for an usuability PoV for Yast to talk to the firewall and punch it just for the autodetection.

Punch the firewall is in almost any case wrong except you really want to set up a public accessible service.

From my point of view usability should not mean "just remove whatever protection to make it just work". In contrast usability should mean to guide the user towards a reasonable setup.

Kind Regards Johannes Meixner IF we were talking Windows I would agree. But considering how unlikely it is to have malicious software on a machine running openSUSE, punching may not be a bad idea. Or make it need the password before opening up. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Hello, On Aug 2 08:30 Rajko M. wrote (excerpt):

I vote of selective opening of ports, just as needed.

Repeating the plain statement again and again does not help. I really wish someone would describe where there is security when opening ports "as needed" in a firewall. Of course there are particular cases where opening a particular port makes sense but in general opening ports make the firewall useless. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Hello, On Aug 3 09:27 jdd wrote (excerpt):

Le 03/08/2011 09:15, Johannes Meixner a écrit :

...

Of course there are particular cases where opening a particular port makes sense but in general opening ports make the firewall useless.

A port opening break security only if the daemon listening have bugs, isn't it?

Exactly. And opening a daemon's port makes the firewall useless for this daemon and you must rely on that this daemon has no bugs.

The problem of "trusted" networks in home or small company network is childs and guests.

Most of the time the network is really to be trusted, but childs may accidentally break the security (installing trojan) or hack for fun.

Guests may also come home with cracked computers and ask for connection.

When you let childs and guests in your trusted network, you must trust the childs and guests. If you do not trust the childs and guests, you must not let them in your trusted network. If childs are installing trojans or when guests connect cracked computers in your trusted network, you are doomed. Therefore you must separate your trusted network from the rest of your network and no longer let such childs and guests in your trusted network. http://en.opensuse.org/SDB:CUPS_and_SANE_Firewall_settings --------------------------------------------------------------------- A trusted network means that you trust all users who can access this network. A user who can connect a computer to a network (e.g. a laptop where the user can work as "root") can send and receive any network traffic. Such a user can eavesdrop on the network and he can also fake any server machine in the network (except additional network switch hardware with an appropriate setup limits the user's network access). ... your trusted internal network traffic must be separated from the other non-trusted network traffic. The best way to get different kind of network traffic separated is when different networks are used. The simplest and most secure solution to maintain separated networks is when separated network hardware is used. ... The basic idea to increase likelihood that your network security is doomed is to mix up trusted and non-trusted network traffic in one same network environment. Save money and use the same network hardware for trusted and non-trusted network traffic and as a consequence pay with an increased likelihood that your network security is doomed --------------------------------------------------------------------- Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer

Hello, On Aug 3 10:14 jdd wrote (excerpt):

Le 03/08/2011 09:55, Johannes Meixner a écrit :

...

And opening a daemon's port makes the firewall useless for this daemon and you must rely on that this daemon has no bugs.

yes

This is what I liked to point out all the time.

...

If childs are installing trojans or when guests connect cracked computers in your trusted network, you are doomed.

that's a reason to have a firewall in every computer :-)

Of course "to be on the safe side you should not switch off the firewall".

...

Therefore you must separate your trusted network from the rest of your network and no longer let such childs and guests in your trusted network.

this is not always (often) possible. We have to share the printer, for example, to come back to the thread object.

When non-trusted users should be able to use your printing service you may have the CUPS server in the non-trusted network. When you need trusted printing, you cannot let non-trusted users also access your printing service. This means you would have to buy a second printer. Of course for a home network this is probably overkill. Usually you set up something wich provides reasonable security for your particular environment. But for a company network, it should not matter to pay the price for a separated printer for the separated network for guests.

It's also why I prefere to have a network printer

In this case you rely on that the services which run on your network printer have no bugs. Have in mind that nowadays network printers run several web-services like a HTTP server, often a FTP server, often several other services too. If a malicious user can compromise the services which run in your network printer or if a malicious user can even replace the whole software which is in your network printer (e.g. via firmware upload), you have a full network capable device in your internal network which can be remote controlled by the malicious user. When a device looks like a printer, acts like a printer, and sounds like a printer, that device could be a computer. You may Google for "network printer security risk". Happy frightening! ;-) Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer

Hello, On Aug 3 22:34 Rajko M. wrote (excerpt):

On Wednesday, August 03, 2011 02:15:05 AM Johannes Meixner wrote: ...

...

I really wish someone would describe where there is security when opening ports "as needed" in a firewall.

We already open ports when browsing the web

Aarrgghh! Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Le mardi 02 août 2011, à 10:16 +0200, Johannes Meixner a écrit :

Hello,

On Aug 1 14:18 Vincent Untz wrote (excerpt):

...

For instance, when configuring printers, the tool can open the mdns, ipp, ipp-client and samba-client ports for 5 minutes and probe the network (ports will get closed after the 5 minutes). And if the user chooses to use a printer using one of those ports, the tool will permanently open the port.

What is the security concept behind this?

In other words: Why is it secure to remove security for 5 minutes? Why is it secure to remove security permanently for particular stuff?

Oh, it's certainly not the most secure approach; it's a compromise between user-friendliness and security. A few ways it could be made more secure include: - instead of having a 5 minutes timeout, just revert to previous state at the end of the probing - instead of blindly opening the service, open it only when on a specific network and for a specific server And while I haven't thought about firewall security in a while, the first example I come with when talking about trusted zones is connecting to WiFi at a university. Is this trusted or not? It might need to be trusted to allow printing documents and most people would trust it, and yet there are hundreds of individuals on this network, including some who might abuse your trust. My question is really: do we plan to integrate firewalld, or something similar, that would improve user-friendliness? This "something similar" could be based on zones -- even if I don't believe it's a better approach, at least, for users, it's an improvement compared to what we have today. I'd just like us to have a solution in the near future (12.1 if we can have fast action, 12.2 otherwise). Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Le mardi 02 août 2011, à 11:38 +0200, Johannes Meixner a écrit :

Hello,

On Aug 2 10:59 Vincent Untz wrote (excerpt):

...

Le mardi 02 août 2011, à 10:16 +0200, Johannes Meixner a écrit :

...

In other words: Why is it secure to remove security for 5 minutes? Why is it secure to remove security permanently for particular stuff?

Oh, it's certainly not the most secure approach; it's a compromise between user-friendliness and security.

From my experience I think the only user-friendly way to deal with security settings is to talk to the user so that he knows what is going on. In particular when security should be removed, I think that an explicite confirmation by the user is mandatory.

Of course, the user would need to confirm this. And my understanding is that firewalld does this, thanks to PolicyKit. I'm not asking for ways to open the firewall without any interaction :-) (and again, just to be really clear, I'm not asking for firewalld itself to be integrated, but for something working in a similar way) [...]

To print documents on a remote printer, there is no need to open any port in the firewall on your host.

Just wondering: is this true for smb printers too? Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Vincent Untz wrote:

And while I haven't thought about firewall security in a while, the first example I come with when talking about trusted zones is connecting to WiFi at a university. Is this trusted or not? It might need to be trusted to allow printing documents and most people would trust it, and yet there are hundreds of individuals on this network, including some who might abuse your trust.

What are you trying to protect against by running a firewall anyways? We always had the policy not run "unneeded" services by default. So cups and avahi are the only ones left. Both will hopefully be (local) socket activated in the future so they are only started if a local process actually requires their service, ie no ports open to the world by default at all anymore then.

My question is really: do we plan to integrate firewalld, or something similar, that would improve user-friendliness? This "something similar" could be based on zones -- even if I don't believe it's a better approach, at least, for users, it's an improvement compared to what we have today. I'd just like us to have a solution in the near future (12.1 if we can have fast action, 12.2 otherwise).

I don't know who 'we' refers to. I for one don't have plans to reimplement SuSEfirewall2 as DBus service. I also don't think that a dumbed down packet filter for the desktop gains us anything except for update problems (btdt). What I've read about firewalld so far isn't rocket science though and some features could be implemented on top of SuSEfirewall2 if really needed. The firewalld author also seems to think in the direction of a zone model similar to SuSEfirewall2 the hooks he needs in NM would serve SuSEfirewall2 (or rather fwzs on top of it) too. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Johannes Meixner wrote:

On Aug 2 13:17 Ludwig Nussel wrote (excerpt):

...

What are you trying to protect against by running a firewall anyways? We always had the policy not run "unneeded" services by default. So cups and avahi are the only ones left. Both will hopefully be (local) socket activated in the future so they are only started if a local process actually requires their service, ie no ports open to the world by default at all anymore then.

By default cupsd is only accessible via the internal interface of the local host (lo) to accept print jobs via TCP port 631.

Additionally by default cupsd is accessible via UDP port 631 to get "CUPS browsing information" from any remote host.

If you like to receive "CUPS browsing information" you need a listening (i.e. running) cupsd on your local host which accepts "CUPS browsing information" from the remote host plus a firewall on your local host which permits incomming packages at UDP port 631.

With socket activation, you may not receive "CUPS browsing information" unless the cupsd would also be activated if a package arrives at UDP port 631.

But then I wonder if there is really better security because any malicious host could then send a package to UDP port 631 to get the cupsd activated there and afterwards send malicious "CUPS browsing information" to do "print job phishing".

I don't think starting up cups when receiving a broadcast packet on port 631 makes sense. That wouldn't be any improvement at all of course. Default socket activation should only trigger on local sockets for cups IMO. It's your package though so that's in your hands. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org