XO automatic clock setting

[Daniel Drake]

2009/8/27 Martin Langhoff <martin at laptop.org>:
> On Thu, Aug 27, 2009 at 4:05 PM, Daniel Drake<dsd at laptop.org> wrote:
>>> This is a good thing if we assume that the initramfs can evolve faster
>>> than OFW,  and the case "OFW doesn't recognise this sig format but
>>> Initramfs does" is a valid one.
>>
>> Except, unless I missed something in the last discussion, we don't
>> fully understand why the system was ever designed like this. So I'm
>> making the assumption that there is something important that we aren't
>> understanding.
>
> Why do both OFW and initramfs check the same thing?

They don't, at the moment. The initramfs trusts whatever OFW said,
without checking.

But Michael's explanation is quite convincing. According to that
understanding, it would be reasonable to do it in both places, as your
patch implements.

> On the other hand, the Bitfrost arch has the expectation that the
> signed&trusted initramfs starts an 'init' that runs  the OAT protocol
> client. This work is not complete, but as you've seen, we _always_ end
> up with a python init (hence, a 'fat' initramfs).

As a sidenote, I ditched this in the reworked initramfs. It can come
back if someone implements the long-running antitheft client. For now,
we save memory and an initscripts package fork. I also wrote code to
generate a slim initramfs that boots straight (therefore we do get a
skinny one for fast OFW-verified boot) but never got around to testing
it.

>> Right now there is no assumption that the system that responds on port
>> 191 is the trusted system which generated the lease.
>
> The time is signed and with a nonce (so no replays).

I'm not talking about any kind of attack, or perhaps I misunderstand
your response.

My point was that there are reasonable setups where the time in the
lease is known to be correct, but that the time on the server that
dishes the leases out over port 191 (the XS) might have a bad clock.

>> Specifically I'm
>> thinking that we can trust that the lease was generated on a trusted
>> connected good-clock computer, was safely distributed to the local XS,
>> but then the XS clock is not necessarily accurate. This setup works
>> right now without the dependency on the XS clock being valid, but this
>> system would add such a dependency.
>
> Yes. But the XO clocks are not reliable either.

Agreed. My concern is that adding in another set of unreliable clocks
to our equation is going to add more cases for failure, and some of
those failures will be very painful.

>> Another potential situation: A deployment could be using long-lasting
>> leases but using the OATS server on a local server for OS update
>> advisories. No leases would be distributed in this system (except for
>> in the delivery chain) but still if OATS server were to set the wrong
>> time for the XOs, it would be devastating.
>
> I share your concern there.
>
> You can easily shut down the port 191 service via xinetd. And yes, you
> could make the time field in the response optional.

Michael, Scott, any comments on making the 'time' field in the theft
deterrence protocol optional? For situations where we'd like some
subset of the OATS functionality, but don't want to gamble that the
clock in the OATS server is correct.

> But the day it happens (that an XS clock is really off) things do go
> pear-shaped.

Even if they aren't using key delegation?

Our development XS here in Nepal has a bad clock and I have not seen
any problems. Although admittedly it is currently running v0.4.


I guess the recurring theme of my concerns is that the excellent work
you're doing on delegation does spill over to users who aren't using
the feature, adding complications and more conditions for failure.

Daniel