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 _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel