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

Delete this message

Reply to this message
Author: Jacob Appelbaum
Date:  
To: The Tails public development discussion list
Subject: Re: [Tails-dev] Reducing attack surface of kernel and tightening firewall/sysctls
On 12/4/14, anonym <anonym@???> wrote:
> On 03/12/14 18:22, Jacob Appelbaum wrote:
>> I propose that we change the rule to be:
>>
>>             mod state state (NEW ESTABLISHED) ACCEPT;

>>
>> The reason is pretty simple - RELATED makes the kernel do a lot of
>> extra lifting that is not needed by using the conntrack kernel code:
>
> While I think we should investigate whether RELATED can be dropped for
> the reasons you outline but adding NEW seems like a mistake.


Ok. That sounds good - I was thinking that NEW may be required for
OUTPUT (not INPUT) but I think I'm totally wrong. I'm glad to see
that! Thank you!

> In fact, I
> see no discussion why it should be there at all, so please clarify its
> purpose.
>
> From iptables(8):
>
>     NEW    meaning that the packet has started a new connection, or
>            otherwise associated with a connection which has not seen
>            packets in both directions

>
> That sounds pretty bad. In my tests of your suggested rule, Tails' Tor
> enforcement [1] is broken:
>
>     unset http_proxy https_proxy HTTP_PROXY HTTPS_PROXY
>     curl https://check.torproject.org | grep "Your IP address"

>
> and so is the local services whitelist [2]:
>
>     nc -l -p 1234 &
>     echo "if you receive this, then you are pwned" | nc 127.0.0.1 1234

>
> Or am I missing something obvious here?
>


I think you're exactly correct. NEW is not needed, I think.

> FWIW I experienced no issues during my tests with *only* ESTABLISHED in
> both the INPUT and OUTPUT chains so neither NEW nor RELATED seems
> essential for the basic usage I tested. And of course the above
> "exploits" didn't work due to the absence of NEW.


Great - I'm glad to hear it!

All the best,
Jake