On Tue, 2014-12-09 at 01:28 +0100, Kevin Kofler wrote: > Matthew Miller wrote: > > Whether you agree or not, reasonable people argue that a host-based packet > > filter isn't really a meaningful increase in security. I don't think we're > > _really_ leaving the security emphasis behind. > > And I argue that the firewall is by far the most important security > mechanism we have available, and a lot more effective than SELinux, which we > are forcing on all our Spins. Instead of merely trying to limit the damage > an intruder can do, it's a lot safer (and also less annoying to legitimate > users) to not let them intrude in the first place. > I think you're forgetting the core tenet of security: good security is *always* layered. > How do you protect your house or apartment from thieves? Do you: > (a) … lock your entrance door? or Yes > (b) … put locks on every single valuable item to keep it from being removed? Also yes: I keep my irreplaceable and most valuable things inside a fireproof lockbox inside my locked house. I may also have (c) between (a) and (b) which is a house alarm system tied to the local police department, so that when (a) fails, the police may arrive before the intruders have time to open my lockbox (or rip it out of the wall, etc.) > A firewall does (a), SELinux does (b). > Sure, and these are both parts of the story. We also have kernel auditing, container faux-isolation and other useful techniques that work to minimize the potential damage. Remember, even in the "DROP everything" firewall, if you're running a service, there's a chance that a vulnerability will be found in it. Now they've escalated past the service and you need to rely on those non-firewall solutions. It will always be impossible to eliminate all human coding errors. Now, the real question to ask here is not "Is the firewall secure?" but "Is my system secure?". The fundamental question at stake here is this: "What new avenues of attack are open if I don't block this firewall port?". If there are system services running on that port that are unexpected, then this can lead to an overall increase in attack surface (partly because of the additional possibility of coding errors as well as the admin being unaware that it's running and therefore not accounting for it). I think we're (Fedora) in reasonably good shape here in the core distro, because we have a lot of stringent requirements on packagers not to start any services by default. There *is* a net lowering of security when we look to the larger open-source ecosystem where others providing packages may not be following this rule. So that's an argument for this being a net lowering of security. Other than a package ignoring the rules, the only other case I can think of would be a malicious trojan horse. Of course, if an attacker already has sufficient access to run a network service on your system, they have already achieved a level of control of at least one user account. In this case, the primary risk is that of inappropriate data access to content visible to the affected user or being joined to a botnet without the user's knowledge. Both cases are fairly serious, and therefore constitute a considerable degree of concern, but I would also argue that this is mitigated by other factors. In the data-access case, this is a perfect example of where the layered security comes into play. If the SELinux rules are properly enforced, malware that comes in through e.g. Apache would not be privileged to actually access anything besides the static HTML files. The bot-net case is less easy for us to deal with, but while it's a net loss in security for the internet at large, I'd say that it's less of a *direct* concern for the compromised machine itself. So from a pure security perspective, I'd come to the following conclusions: 1) Yes, there is a net reduction in security and 2) It's probably a sufficiently small reduction given the other layered mechanisms in place. I'm not sure I necessarily buy the UI decisions either; I think if we push for appropriate systemd and firewalld integration (perhaps requiring all network services to request their port via systemd's socket-activation feature which can be extended to talking to a prompter for the GUI; just spitballing here), it should be possible to provide at least a somewhat reasonable interface to at least let the user know that "<application> wants to listen on the network. Is this expected?" (and perhaps maintain a sensible whitelist for things like SSHD). I'd leave it up to the designers to figure out the actual correct approach to that, but I'd like to see that discussion happen (again, since I *do* know that some of it happened the first time around). > > On Mon, Dec 08, 2014 at 03:20:30PM -0500, Mike Pinkerton wrote: > >> Perhaps the Workstation team thought that opening up the firewall > >> defaults was the best compromise. I disagree. Perhaps a better > >> compromise would have been to leave the old defaults in place, and > >> add a new pre-configured "more open" zone for those who want fewer > >> constraints.AAAA > > > > Wait, my last paragraph was a great end to a long message :) but I need > > to also add: please take a look at the actual implementation. The above > > suggestion is _exactly_ what was done. > > Uh no, it was not. > 1. The default zone is the insecure one. Mike Pinkerton says that the > default zone should be the secure one, and the insecure one opt-in, not > opt-out (and I agree with him). I generally agree, but I'll come at it with the caveat that the "pure" secure solution of blocking everything has usability issues that need to be balanced as well. For example, people STILL have trouble working with network printers. In 2014. > 2. The tool to change to a secure firewall zone isn't even installed by > default. This is a somewhat misleading statement. The GUI tool to change the default isn't in place, but there is 1) The CLI tool to change the default (see my earlier message to this thread) 2) A GUI tool to change the zone on any or all of the network interfaces on the system. Change them all and it's the same as changing the default. Also, while I think it's been unclear in this thread, the main reason that the firewall GUI was taken out was because the Workstation guys want to design a more user-understandable one and include that directly (if I am remembering that conversation correctly). The current one is not terribly easy to understand (though it's certainly an improvement over s-c-firewall).
Attachment:
signature.asc
Description: This is a digitally signed message part
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
