Re: [Tails-dev] Fwd: Re: Reducing attack surface of kernel a…

Delete this message

Reply to this message
Author: intrigeri
Date:  
To: The Tails public development discussion list, Cornelius Diekmann
Subject: Re: [Tails-dev] Fwd: Re: Reducing attack surface of kernel and tightening firewall/sysctls
Hi,

Jurre van Bergen wrote (11 Feb 2016 16:46:47 GMT) :
> Forwarding e-mail.


Thanks :)

> Date:     Thu, 11 Feb 2016 12:28:35 +0100
> From:     Cornelius Diekmann <diekmann@???>


> A conservative change to the tails config would be to keep an RELATED
> rule but limit it to known good ICMP messages.


Yes, this was proposed on the thread; in the email you're replying to
I explained why I didn't pick this option, mainly because no (pseudo-)
implementation thereof has been proposed nor discussed yet.

Given this discussion has been going on for more than a year, and
apparently most of the people involved in it are not quite into the
summing up and making decisions game, my goal here was to build on top
of what has been agreed upon as an improvement already, and to
actually make it happen. This of course works only if the current
proposal does not break too much stuff (see discussion below about
Destination Unreachable).

In any case, I'm happy if people discuss how we can make things even
better in a second iteration :) … especially since once we do IPv6,
apparently we can't escape dealing with this problem.

> What I did not see in the discussion is the Destination Unreachable ICMP
> error. If a host is unreachable, tails will eventually find out by a
> timeout. But with an unreachable message, a user does not have to wait
> for a timeout.


Good point! I say let's evaluate if this is a _practical_ problem for
Tails first.

In the current state of Tails, if I got it right this should only
affect:

* trying to access an unreachable host on the LAN: indeed this has
the potential to cause minor usability issues, e.g. when the
network printer is turned off; it would be nice if someone tested
how Tails _currently_ behaves in this respect (just configure
a network printer with an unused IP on the LAN), and how things
would look like with the firewall changes one can find in the
feature/various-firewall-hardening branch;

* Tor trying to connect to an entry guard or directory authority that
is currently unreachable: I'm curious what would happen
in practice;

* I2P: I don't know (and I don't maintain our I2P support)

* Unsafe Browser: very minor issue IMO

Cheers,
--
intrigeri