Bitfrost and dual-boot

[Jameson "Chema" Quinn]

Actually, the goals are more limited. Say you have dual-boot; OS 1 has
bitfrost, OS 2 does not. Things OS 2 should not do:

1. Read private files from OS 1.
1a. Read encryption key from OS 1, thus subverting all security which that
key gives. This, in particular, should be avoided.
1a(i). By reading unitialized memory, snoop passwords which OS 1 had only in
volatile memory. This threat was not mentioned in my initial email because
such passwords are not envisioned by Bitfrost as being part of sugar - it is
the one case where OS 1 could be windows. However, it is easy enough to
prevent by clearing volatile memory on reboot. This would give the XO, which
has soldered-on RAM, better security characteristics than any laptop I know
of (until the macbook air updates its firmware).

2. By writing to OS 1's file system, subvert the bitfrost security within OS
1 itself, such that even if OS 2 is later deleted, malware can now do bad
things inside OS 1.
2a. By simple changes to files that should be writeable within OS 1 - that
is, chmod on a data file, or changing a file of user-granted extra Bitfrost
privileges.
2b. By changes to files that could be read-only within OS 1 - that is, by
replacing the kernel or bitfrost-related code or binaries.
2c. Do 2a and/or 2b in such a way that they are not detectable, or not
fixable simply through a reinstall. In other words, I would like to be able
to say "I just removed a major trojan from my Windows, please rescan Sugar
to ensure that system files have not been changed" or, more simply,
"reinstall Sugar".

3. Cause denial of service by erasing or changing files necessary for OS 1
to run.

4. Cause dataloss by erasing or changing OS 1's data files.

5. Insert data into OS 1's journal by writing new data files.

...

I am only focused on preventing 1 and 2 here. In particular, I think that 1a
and 1a(i) are worth considering. Also, If 2b is deemed impractical to guard
against, 2 may be acceptably addressed only by 2a and 2c.

3 would be very hard to accomplish. However, security measures to prevent 2b
should also help mitigate the risks of 3.

5 is arguably even desirable, and it is impractical to allow 5 without
allowing 4, so these should not be considered.

...

Ivan, could you elaborate on why you think that this is not a "good
extension of the threat model"? Do you believe that these threats is not
real, or do you believe that it will be impossible to guard against them, or
other?

Jameson

On Wed, May 28, 2008 at 7:01 PM, Ivan Krstić <
krstic at solarsail.hcs.harvard.edu> wrote:

> On May 28, 2008, at 8:33 PM, Benjamin M. Schwartz wrote:
>
>> What are you trying to prevent?
>>
>
>
> He doesn't want one OS to be able to screw with files from another in a
> dual-boot scenario. I don't think it's a good extension of the threat model.
>
> --
> Ivan Krstić <krstic at solarsail.hcs.harvard.edu> | http://radian.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20080529/c9ae52bf/attachment.html>