Bitfrost and dual-boot

[david at lang.hm]

On Thu, 29 May 2008, Jameson "Chema" Quinn wrote:

> 2008/5/29 <david at lang.hm>:
>
>> On Thu, 29 May 2008, Jameson "Chema" Quinn wrote:
>>
>>  I just had an IRC conversation with Benjamin Schwarz in which we talked
>>> about:
>>>
>>> He said that 3,4, and 5 have been considered more serious than 1 and 2;
>>> since they are impossible, there is little point doing 1 and 2. I
>>> disagreed.
>>>
>>> There is no way with current hardware to write-protect the NAND storage,
>>> and
>>> not too much space (<<512K) in the firmware storage. However, it would be
>>> possible to hash NAND or some subset thereof, and complain loudly on boot
>>> if
>>> it changed.
>>>
>>
>> not really, you would have to hash NAND on every shutdown. remember
>> everything you do is in thr journal on NAND, and any change (including
>> things like a file timestamp, including atime) will invalidate your hash.
>>
>> David Lang
>>
>> The idea would be to have a separate read-only volume on NAND, which
> included everything executable as root (in other words, 90-100% of glucose
> and ribose; the kernel, though, is already signed, so could be elsewhere).
> Mounting this ro would prevent silly atime breakage, and there could be
> strong protections to prevent anything NOT on this volume from being
> considered "executable" by root. (Of course, this is not the whole story, as
> there are uncountable ways for non-"executable" stuff to compromise
> security; but it is a start. It would break any rpm's that only know how to
> run as root - but these are broken anyway.)

if you run everything as user olpc and user olpc can become root without a 
password, getting olpc is as good as getting root.

so you have to check everything that could run as user olpc as well.

not to mention the fact that you would need to audit every program to see 
what it will do with the data you feed it (if anything reads something 
from a file and then executes arbatrary commands based on it, you've lost)

given that this would prevent anywone from writing or modifying any 
software on the machine, this conflicts quite explicitly with the goals of 
the project.

the best you can do is to protect the firmware, and give the firmware a 
way to re-image the NAND so that you can be sure of recovering from any 
corruption. you are not going to be able to prevent it.

David Lang