[ubuntu-hardened] Firewall settings: User interface review and questions

[Jamie Strandboge]

On Thu, 2011-06-23 at 10:30 -0700, Kees Cook wrote:
> Hi,
> 
> On Thu, Jun 23, 2011 at 05:12:13PM +0100, Matthew Paul Thomas wrote:
> > Part of the planned "Desktop-side networking enhancements"
> > <https://launchpad.net/ubuntu/+spec/desktop-o-desktop-network-enhancements>
> > is the addition of a graphical interface for configuring a firewall.
> > 
> > Mathieu Trudel-Lapierre and I have been working on a design for the
> > firewall settings. Here's what we have so far:
> > <https://wiki.ubuntu.com/OneiricDesktopNetworkEnhancementsSpec#Design>
> > 
> > We'd appreciate a general sanity check for these settings, from people
> > who know more about security than we do. Are they missing anything
> > highly useful? Or is there anything there that shouldn't be?
> 
> First, please make sure the UI will interface correctly with "ufw",
> which is the official Ubuntu firewall tool. Jamie Strandboge, as the
> author, can help guide you there.
> 
Indeed, Mathieu and I have been in discussions about this and I have a
work item already. :)

> > There are also two specific questions we have:
> > 
> > *   Does Ubuntu have any "essential" incoming connections, which should
> >     be allowed in the normal case even when the firewall is turned on?
> >     (As a comparison, Mac OS X identifies "DHCP, Bonjour, and IPSec" as
> >     essential.)
> 
> Yes, they are outlined in what we consider "Infrastructure Services":
> https://wiki.ubuntu.com/SecurityTeam/Policies#No_Open_Ports
> and we make case-by-case exceptions for them (presently DHCP and Avahi/mDNS).

ufw takes these into account as well. When it is enabled and in
enforcing mode, it allows dhcp, avahi, ping and some other stuff that is
generally needed. For a full list, see /etc/ufw/before*.rules

> >     -   If so, how much use is it to have a graphical setting for
> >         blocking even those "essential" connection types?
> 
> Since they would break the functionality of most systems, I'm not sure it's
> a great idea, but ufw does allow control over it, so it's really up to us
> about how to present it in the UI.

The ufw API and cli command do not currently expose turning off these
'essential' connection types. I don't think it is worthwhile exposing
this in the gui. ufw uses good defaults for most people. Those who need
more can edit the /etc/ufw/before*rules directly IMHO.

> > *   Does Ubuntu have any "essential" outgoing connections? Web
> >     browsing? E-mail? Avahi?
> 
> At present, we view everything as essential. Since there is no way
> currently to sanely hook outgoing traffic and pop up dialogs about "do you
> want Program talking to the internet?" it doesn't make much sense to try to
> filter it.

This is correct. The ufw API and cli command do provide for egress
filtering though, so this could be exposed in the gui if desired. In
general I don't think this needs to be exposed in the gui.

> In fact, we don't believe in filtering _incoming_ traffic by default
> because of the no open ports policy. There's nothing listening, so why
> confuse things and make it harder for people to install services they want
> listening only to have the firewall block them by default?

This could conceivably be revisited if there was a gui tool to adjust
the firewall. In general, I think opting into the firewall is a good
idea since people have the chance to realize if something breaks it is
because of something they did. ufw does have debconf functionality for
preseeding (enable/disable and basic opening of ports), so it is
possible to add a question in ubiquity if desired, though I'm not sure
that is desirable if the firewall configuration is easily discoverable
via network manager.

-- 
Jamie Strandboge             | http://www.canonical.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/ubuntu-hardened/attachments/20110623/1736ec69/attachment.pgp>