Re: F21 System Wide Change: Workstation: Disable firewall

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 04/22/2014 09:17 PM, Russell Doty wrote:
On Tue, 2014-04-22 at 15:04 -0400, Simo Sorce wrote:
On Tue, 2014-04-22 at 14:41 -0400, Russell Doty wrote:
On Tue, 2014-04-22 at 14:23 -0400, Simo Sorce wrote:
On Tue, 2014-04-22 at 13:22 -0400, Russell Doty wrote:
On Tue, 2014-04-22 at 19:01 +0200, Miloslav Trmač wrote:
2014-04-22 13:40 GMT+02:00 Stephen Gallagher <sgallagh@xxxxxxxxxx>:
         3) Recovery and auditing are more important than prevention.

This is only true for large managed enterprises, where recovery is
possible in the first place (how many people don't have good
backups?), and prevention is bordering on impossible (with the high
number of systems and administrators).  For individual users auditing
is completely pointless, recovery is either impossible or a huge
hassle, and prevention the only option.
Well, the presentation was focused on enterprise systems...

But there were some underlying themes:

* Users will work around anything, including security features, that
interfere with them doing their job.

* It is impossible to completely secure a system. A prevention only
approach doesn't work well.

* An effective security model is built around Deter, Detect, Delay,
Respond, Remediate.

* Security is one of multiple threats to system integrity.

All very true, but you do not remove the Deterrent, just because you
have the other 4 layers (which we do *not* have very much in Fedora when
it is used as a simple workstation).
Absolutely true - the foundation of the stack is Deter. The point is
that we can't harden a system enough for Deter alone to be fully
effective, so we need to have the complete security model.

And you are right. We have a real opportunity to look at an overall
"people centric" approach to security in Fedora. Look at the traditional
threat models, look at the people issues, and look at an overall
approach to maintaining system integrity.

I'd like to see us exploring system integrity in greater depth.

This is why people say we need to improve the Firewall experience not
raise white flag and disable it.
Agree. Unfortunately, the easy way out is to punch so many holes in the
default firewall that it doesn't offer much protection...

not really true, having the default one allow access only from the local
lan at most is a huge improvement rather than no firewall.

All you need is a button that lets you select between 3 zones when you
join a new network and you have a much better system already, nothing
fancy, and the 3 zones correspond to the concepts of:
open to everyone (effectively disables any protection)
open to the local lan only (what you would select at home/work/trusted
network)
closed (what you would select in a public place on an untrusted network)
This sounds a lot like the Network Manager model.

Could this basic firewall configuration be integrated with the Network
Manager interface? So that a user sets their "security profile" one
place, and all related system settings and configurations are updated?
Please have a look at "edit connection" in the NetworkManager applet.

There have been plans to query for the zone that should be used for a connection before activating this connection for the first time. There are even sketches for this. But as I said before, this has been rejected by the desktop team.

Because of this I created firewall-applet, which provides a simple UI to switch zones for connections with NetworkManager and for interface and source bindings.


It is quite simple to describe even to a non expert user what these
means in general terms.

Of course it won't be perfect, but much better than nothing, and much,
much friendlier than what we have now.
A combination of this and having all commonly used applications
configure the firewall when installed/uninstalled looks like a good
start, especially from a usability perspective.

Simo.

--
Simo Sorce * Red Hat, Inc * New York



Thomas
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux