Autore: Jacob Appelbaum Data: To: The Tails public development discussion list Nuovi argomenti: Re: [Tails-dev] minimalist/anonymity-preserving DHCP clients Oggetto: Re: [Tails-dev] minimalist/anonymity-preserving DHCP clients [was:
Re: Reducing attack surface of kernel and tightening firewall/sysctls]
On 12/9/14, Daniel Kahn Gillmor <dkg@???> wrote: > On 12/04/2014 10:37 AM, Jacob Appelbaum wrote:
>> On 12/4/14, Daniel Kahn Gillmor <dkg@???> wrote:
>
>>> I'm not sure i'd characterize a simple DHCP client as "quite straight
>>> forward", but certainly minimalist one is more straightforward than one
>>> which handles all the possible extensions that have cluttered DHCP over
>>> the years.
>>
>> We've already written the start of very basic non raw socket DHCP
>> client - it doesn't yet include the parser and later stages but it
>> does fetch leases. It is completely straight forward with the basic
>> socket API. It is absolutely not required to use a raw socket but it
>> requires some trickery with the rp_filter in the kernel.
>
> I'm happy to hear about your progress! can you point to the code
> someplace for people who are interested to review it?
>
The project isn't in a state where it makes any sense at all to share
it. It should not be used and we're just experimenting. Currently,
we've found a way to run without raw capabilities, which is a huge
security improvement. This is however a far far cry from a DHCP
client.
>> The parsers for any dhcp client are of course rather annoying and the
>> rest of the hooks are too. However - remember the DHCP client that
>> talks to the *network* does not need to do anything other than the
>> full DHCP lease process. Thus with the right design, a minimal or a
>> full client are something in another process anyway.
>
> Getting the thing to a state where it's usable for normal people with
> normal computers encompasses the whole scope, so the project will have
> to deal with the stickier parts eventually.
>
Hrm. I think not - I think a DHCP client needs to do four basic things
- everything else can be handled by a small daemon that deals with
timers, user space and kernel configuration and so on. In an ideal
world, I'd like to have a very slim thing that touches the network and
then reuse a lot of other code for everything else.
>> I'd be happy to talk with them. Please do introduce me to them in some
>> way?
>
> done offlist. hopefully we can produce something useful :)
Hope so too - thank you!
>
>>> * specify the lease renewal behavior algorithm
>>
>> It seems rather straight forward to use the time offered by the server
>> - what else do you think is important to consider?
>
> the time offered by the server tells you when the lease expires. it's
> up to the client to decide when to try to renew (t/2 seconds? t - 20
> seconds? something else? how does it deal with weird values for t like
> very small or very large values?). It's also up to the client to decide
> how to deal with the renewal when ACKs are delayed or not forthcoming.
>
I think MAC address randomization and captive portals are two other
issues that are directly related too.
> Specifying all of the fiddly optional parameters of the renewal strategy
> would help implementations avoid being fingerprintable based on timing
> as well as content.
I certainly think that is a good goal. The first step will be to have
a minimalist dhcp client - once we have that, I think you're correct,
we should consider how to make that a uniform privacy enhancing DHCP
client.
