Re: Bug#752450: ftp.debian.org: please consider to strongly tighten the validity period of Release files
On Mon, Dec 01, 2014 at 04:55:55AM +0100, Christoph Anton Mitterer wrote:
> On Sat, 2014-11-22 at 11:42 +0100, Wouter Verhelst wrote:
> > Except that if a firewall "protects" a user from using their printer
> > (random example, not sure how likely)
> Well most security guys are probably sceptical about any automagical
> confiugration of things like a printer... so "protects" can actually
> really mean protect here.
>
> But apart from that, other distros seem to manage that problem (simply
> allowing the CUPS ports?)
As said, "cups" is an example. It's not about cups specifically, it's
about the fact that you want a computer to *do something*, not break
because "firewall!"
> > and they have no way of fixing
> > that (or even understanding what's wrong), that's not very helpful. This
> > is why I said "with the current state of affairs".
> >
> > Before we enable a firewall by default, we should, IMO, have the
> > following:
>
>
> > - A way for a user to configure it without understanding iptables.
> IMHO, this is a bad idea. If a user doesn't know what he's doing that he
> usually makes more harm than good.
I didn't say "without knowing what they're doing", I said "without
understanding iptables". There's a difference, and it's not subtle.
> People probably have to accept the fact that they cannot blindly act
> without any knowledge and this still work.
Not in all cases, no, that much is true.
However, there are a few common configurations where we *can* usefully
provide a default configuration for the system. When my father uses his
laptop, he never uses it for anything but "browsing the web", "printing
out his writings", and "reading his mail". Any kind of server on such a
machine is most likely *wrong*.
This configuration is common, and easy to configure. Yes, there may be a
few corner cases where the default firewall config will not do what is
expected. That's not necessarily a problem.
> > - A way for a user to debug (without understanding iptables) if things
> > don't work.
> Mhh, that I agree,... OTOH, having some basic knowledge on iptables and
> debuggin is rather easy, at least speaking about simple cases like "I
> block my CUPS port"... other cases like IPv6 needs ICMPv6 to work or
> things that require protocol level knowledge are nothing that one can
> really automagical debug for a user without the willingness to learn
> about these things.
I'm not talking about a default firewall that will interfere with
ICMPv6 (or ICMPv4, for that matter; blocking ICMP is evil). I'm talking
about a default firewall that will do things like close ports 80, 22,
25, etc.
If a user tries to connect to port 22 from a remote machine and it
doesn't work, this user should have an easy way of figuring out "why
doesn't my SSH connection work".
That's not too difficult to accomplish.
> > - A way for a package maintainer to assert that this particular package
> > needs a hole in the firewall to be useful, and that this hole needs to
> > be available to a particular group of remote machines. E.g., cups
> > would not expect connections from the other end of the world, while
> > webservers would.
> This is really a bad idea. Most sysadmins probably wouldn't want their
> firewall rules to be automagically changed by some pseudo-smart
> mechanism.
Who said anything about "automatigically changing" or "pseudo-smart
mechanism"?
I'm suggesting that a package be able to communicate to some other part
of the system that it needs a hole in the firewall. That other part of
the system can then decide (based on user configuration or interactive
input) to ignore the request, change the firewall (with a better
understanding of how the firewall is configured), mail root, segfault,
or spawn nasal daemons.
Or just not exist, if the local sysadmin decides not to allow firewalls.
> In fact, no one can really know how fire wall rules are set up, and even
> the placement of a rule make completely change the semantics.
Well, no, that's true. If we ship a default firewall, we know what the
firewall looks like. If the user installs a different piece of firewall
software, and that piece has understanding of this proposed mechanism,
then it may assume it knows what the firewall rules look like.
If the local sysadmin wrote their own scripts to handle firewall, and
they incorporated support for this proposed mechanism, then they should
damn well understand what they did.
Here's what I'm suggesting:
User: apt-get install apache
Apache package: "Hello system. If you're a server, you will probably
want to open port 80/tcp in the firewall."
System firewall: "here you go."
User: apt-get install cups
Cups package: "Hello system. If you're a user machine and you're on
something resembling a 'home network', you will probably want to open
port 631/tcp".
System firewall: "we're not on a home network, but I've stored that
information for later reference, thanks."
User: apt-get install ntpd
Ntpd package: "Hello system. There are some useful configurations where
you might want to open port 123/UDP"
System: "Not sure what to do with that. User, what do you think?"
User: "Hell no!"
User: apt-get install squid
Squid package: "Hello system. If you have a home network, you will want
to open port 3128 on that network."
System: "Ah, yes, thanks. eth1 is a home network. I'll open the port
there. eth0 isn't, though, so I'll keep things closed there."
User: apt-get remove <firewall package>
User: apt-get install openssh-server
openssh-server package: "Hello system. You will probably want to open
port 22."
System: (no reply)
openssh-server package: "System? Hello?"
System: (no reply)
openssh-server package: "Ah well, I'll just assume the port is open,
then."
etc. The package's suggestion would be a *hint*. What happens with it,
is fully and completely dependent on the local system's configuration.
After all, I do not expect a desktop firewall to look the same way as
would a server firewall.
> > I'm sure the first of those exists, someone with more of an opinion
> > about it than me should have a look at the available options and decide
> > what should be made the default.
> If Debian should really get a default set of rules,
I didn't say a default set of rules, I said a default piece of software.
This default may also be different depending on whether the user chose
the "desktop" task or one of the other tasks.
[...]
> I've just proposed a small default set of rules which blocks most
> incoming stuff that is not from ESTABLISHED/RELATED...
> I've added the default rules which I'm using at the faculty... think
> away the IPsec handling stuff, the way I specially handle fail2ban, and
> add you printer rules,... and I think it should already work for 99%
> cases.
> These are actually the rules I'm using on my desktop as well, and so far
> (except for CUPS or zeroconf stuff) I haven't seen any software having
> network troubles with that.
You may not like cups or zeroconf, but many of our users do; and
zeroconf is also enabled by default (cups' network browsing isn't). To
disable it (without providing an alternative) would be a regression from
previous releases.
--
It is easy to love a country that is famous for chocolate and beer
-- Barack Obama, speaking in Brussels, Belgium, 2014-03-26
Reply to: