XO automatic clock setting

[Martin Langhoff]

On Thu, Aug 27, 2009 at 1:30 PM, Daniel Drake<dsd at laptop.org> wrote:
> I'd like to start a discussion about some of Martin's changes to the

Thanks Daniel for the outstandingly clear description of my patches
(and the review that backs it). Comments below -

...
> Also, the time is set regardless of whether the lease is valid or not.

Yes, the time is asked _after_ we get a response for the lease, but it
has to be set _before_ we validate the lease.

Otherwise, the lease validation would fail with a corrupt clock.

There is a (desired) side-effect to this as well: XOs with marginal
RTC batteries (or just marginal battery holders!) will skip a trip to
the repair shop.

There is a sizable number of such laptops out there.

> 2. olpc-update-query has recently been updated to look at the 'time'
> field in the OATS server response and to unconditionally update the XO
> hardware clock with that value.

Minor nit: not quite unconditional -- we are within 10s of the right
time. A true unconditional clock-set would mess w ntpd.

> 3. For the client-side activation code in the initramfs that parses a
> lease.sig from USB/SD, we now use a mmap() and regular expression
> based parsing solution because the previous cjson parsing didn't scale
> to 200,000 leases.

Actually, we use the fallback which is very unpretty, as there is no
mmap.so in the initramfs.

With my just-learned initramfs-foo I may be able to add mmap.so and
kill the ugly code.

> 4. sig02 leases are still unsupported in the latest OpenFirmware, but
> it looks like we have renewed interest in getting this finished off,
> so no initramfs changes will be needed in this area.

Here Daniel skips the fact that there is a homely but IMO valid patch
that -- when OFW tells us <activate> -- rechecks the filesystem for a
valid lease before trying to activate.

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.

In a perfect, "we have all the resources we need, we can clone Mitch
at will" world, we don't need this patch...

> My own questions/concerns:
>
> 1. When updating the time over port 191, is it OK to ignore the expiry
> of the sig02 lease? This seems to indicate that anyone who has got
> hold of the appropriate key material to sign sig02 leases at some
> point in time is now able to set the clock of any lease-expired XO who
> is in range of their open network, even if their "sig02 license" has
> expired.

Migitating factor: this risk is quite narrow -- sig02 leases depend on
delegations to specific XOs.

> 2. Why use OATS_KEYS for signing the time over port 191?

Because it is the same key that signs the time over HTTP.

In the HTTP side of things, the whole message is signed with OATS_KEYS
and that's the only thing that validates the time.

> 3. I'm uneasy at the idea of us trusting the XS clock. Particularly in
> unconnected environments where it can't even rely on something like
> NTP. If it hands out the wrong time then all XOs would be unable to
> boot.

If it hands out the wrong time, it will also hand out valid leases for
that time -- unless it's far in the future. That "a time in the
future" kills our XOs is pretty much part of the design.

>Are there other concerns here, perhaps with someone hijacking an
> XS?

In disconnected environments, if someone steals the XS -- game over.
But we have to avoid falling into the trap described here:
http://xkcd.com/538/ --

If an XS is stolen in the field, in disconnected environments
specially, it will be quickly formatted to run Windows. Or a desktop
linux.

And if not -- the stolen keys and delegation can only control OAT and
leases for the XOs in that school.

If someone "steals the whole school setup", and has good linux skills,
yes. We can't avoid that -- but we forced them into a pretty awkward
and unlikely move.

The main control over that risk is the length of validity of the delegation.

> I would vote that time-publishing should be disabled by default on the
> XS. However, in the case of the OATS protocol it is not an optional
> field. Should we extend/amend the protocol?

Disabled _on the server_? The hypothetical linux-savvy attacker
whostole the whole school will switch it *on*. Or am I missing
something?

Offtopic: how I wish we had some linux-savvy people in Lat Am to make
these scenarios more realistic :-)




m
-- 
 martin at laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff