[PATCH] Install customization packages left for us by a USB key.

[Michael Stone]

On Fri, Mar 07, 2008 at 03:32:14PM -0500, Benjamin M. Schwartz wrote:

First, thanks very much for the constructive criticism. 

> This discussion is ultimately about Bitfrost's P_SF_RUN, 

We should certainly design a solution compatible with P_SF_RUN. I submit
that the tactical part of the discussion contains material that extends
beyond the scope of Bitfrost, but it's certainly good to revist the
theoretical underpinnings of the enterprise.

> According to the Bitfrost spec, the P_SF_RUN permission is required
> for the user to modify the running system files.  Installing an RPM
> clearly constitutes a modification of the system files.  Moreover, any
> user who can install an RPM can make arbitrary modifications to the
> system, using setuid binaries or other techniques.

Certainly true.

> Once P_SF_RUN is implemented, this RPM installation feature will be
> incompatible with P_SF_RUN.  There are then two options:

> 1. RPM customization from USB sticks will not work if P_SF_RUN is disabled.

Agreed.

> 2. RPM customization from USB sticks will constitute a security hole,
> rendering P_SF_RUN ineffectual.

I would have suggested, instead, that 'once P_SF_RUN is implemented,
this RPM installation feature will operate by exercising P_SF_RUN.' In
other words, isn't rebooting with a specially formatted USB key (perhaps
with fancy signed instructions; perhaps not) a [1] perfectly good way to
determine that the human operator of the XO actually intends to modify
the system software contained on it?

  [1]: Clearly, some alternate mechanism is also needed in order to
  support users who do not possess spare USB keys.

Revertibility still needs some work: something like a CoW linking
primitive, union mounts, etc. are still needed in order to put a
writable layer on top of the read-only base layer.

Comments?

Michael