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:<br><br>1. Read private files from OS 1.<br>1a. Read encryption key from OS 1, thus subverting all security which that key gives. This, in particular, should be avoided.<br>
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).<br>
<br>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.<br>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.<br>
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.<br>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".<br>
<br>3. Cause denial of service by erasing or changing files necessary for OS 1 to run.<br><br>4. Cause dataloss by erasing or changing OS 1's data files.<br><br>5. Insert data into OS 1's journal by writing new data files.<br>
<br>...<br><br>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. <br>
<br>3 would be very hard to accomplish. However, security measures to prevent 2b should also help mitigate the risks of 3.<br><br>5 is arguably even desirable, and it is impractical to allow 5 without allowing 4, so these should not be considered.<br>
<br>...<br><br>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?<br>
<br>Jameson<br><br><div class="gmail_quote">On Wed, May 28, 2008 at 7:01 PM, Ivan Krstiæ <<a href="mailto:krstic@solarsail.hcs.harvard.edu">krstic@solarsail.hcs.harvard.edu</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On May 28, 2008, at 8:33 PM, Benjamin M. Schwartz wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
What are you trying to prevent?<br>
</blockquote>
<br>
<br></div>
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.<br><font color="#888888">
<br>
--<br>
Ivan Krstiæ <<a href="mailto:krstic@solarsail.hcs.harvard.edu" target="_blank">krstic@solarsail.hcs.harvard.edu</a>> | <a href="http://radian.org" target="_blank">http://radian.org</a><br>
</font></blockquote></div><br>