Re: [Tails-dev] Reducing attack surface of kernel and tighte…

Delete this message

Reply to this message
Autore: intrigeri
Data:  
To: The Tails public development discussion list, Oliver-Tobias Ripka
Vecchi argomenti: Re: [Tails-dev] Reducing attack surface of kernel and tightening firewall/sysctls
Oggetto: Re: [Tails-dev] Reducing attack surface of kernel and tightening firewall/sysctls
Hi,

[cleaning my INBOX]

tl;dr: all the proposed changes were applied in Tails 2.4. Thanks!

intrigeri (Thu, 11 Feb 2016):
> intrigeri wrote (05 Mar 2015 21:14:50 GMT) :
>> intrigeri wrote (18 Jan 2015 21:45:15 GMT) :
>>> I see this thread has been quiet for a bit more than a month.


>>> Maybe it's time for someone to sum up whatever consensus was reached,
>>> and whatever disagreement may still be remaining?


>> Ping?


> OK, OK, here we go :)
> Thank you all for your contribution!


> I have compiled everything that everybody seemed to agree in this
> thread, into a Git branch (feature/various-firewall-hardening).
> I'll build it and run our automated test suite on it.


> There's one question below, mainly for Oliver-Tobias, but anyone else
> is free to have a look.


> Anyone who participated in this thread, please consider checking my
> summary below. This is _not_ my area of expertise, and it may very
> well be that I got something wrong from your discussion, which is why
> I was asking for someone else to sum it up a year ago.
> Thanks in advance!


> Note that all patches pasted below are entirely untested.


> Regarding the firewall rules, I think the agreement that was reached
> is:


> --- a/config/chroot_local-includes/etc/ferm/ferm.conf
> +++ b/config/chroot_local-includes/etc/ferm/ferm.conf
> @@ -15,7 +15,7 @@ domain ip {
>              policy DROP;


>              # Established incoming connections are accepted.
> -            mod state state (RELATED ESTABLISHED) ACCEPT;
> +            mod state state (ESTABLISHED) ACCEPT;


>              # Traffic on the loopback interface is accepted.
>              interface lo ACCEPT;
> @@ -25,7 +25,7 @@ domain ip {
>              policy DROP;


>              # Established outgoing connections are accepted.
> -            mod state state (RELATED ESTABLISHED) ACCEPT;
> +            mod state state (ESTABLISHED) ACCEPT;


>              # White-list access to local resources
>              outerface lo {


> So far, so good.


FTR these changes went in Tails 2.4.

> Except one problem was raised about this change, i.e.
> the potential for breaking stuff if a link along the way has a small
> MTU. On this we have two messages from Oliver-Tobias:


> Oliver-Tobias Ripka wrote (04 Dec 2014 01:06:11 GMT):
>> there are some cases where TCP also depends on
>> ICMP. What comes to mind is PATH MTU discovery. As TCP always has the DF
>> bit set it, packets might get rejected by routers on the path that only
>> allow for a small MTU. This results in an ICMP destination
>> unreachable/fragmentation needed(DU/FN) message that has the "next hop mtu"
>> value set.


>> [...]


>> The bottom line is that we should test if this theory above actually
>> results in problems when sending large packets in these circumstances.


>> Possible solutions would be to tweak the sysctls to allow the Kernel to
>> determine an efficient MTU via black hole router detection and MTU
>> probing.


> If I understand correctly this means settig net.ipv4.tcp_mtu_probing=1.
> Right?


> I've tested this 9 months ago and at least it didn't break our
> automated tests (https://labs.riseup.net/code/issues/9268#note-10).


This went into Tails 2.4 to.

> Another point that was raised was:


>> If we look at on the latest Tails, we'll see
>> /proc/sys/net/netfilter/nf_conntrack_helper is set to 1. I propose
>> that we set it to 0. We do not want help tracking connections, we do
>> not want those extra protocol parsers in the kernel doing this kind of
>> heavy lifting.


> ... that I think we should try (via our automated test suite).


This was applied in Tails 2.4 too.

> To end with, this other unrelated firewall hardening proposal was left
> unchallenged and is probably good (we have good test coverage in this
> area so our automated test suite should tell us relatively quickly if
> it breaks anything):


> Oliver-Tobias Ripka wrote (09 Dec 2014 22:40:32 GMT):
>> At the same time we should be able to change the debian-tor rule to
>> allow only NEW TCP packets, disallowing all other protocols.


> ... that is something like:


> --- a/config/chroot_local-includes/etc/ferm/ferm.conf
> +++ b/config/chroot_local-includes/etc/ferm/ferm.conf
> @@ -141,7 +141,9 @@ domain ip {
>              }


>              # Tor is allowed to do anything it wants to.
> -            mod owner uid-owner debian-tor ACCEPT;
> +            mod owner uid-owner debian-tor {
> +                proto tcp syn mod state state (NEW) ACCEPT;
> +            }


>              # i2p is allowed to do anything it wants to on the internet.
>              outerface ! lo mod owner uid-owner i2psvc {


> Thoughts?


Ditto, applied in 2.4.

Cheers,
--
intrigeri