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ć < [EMAIL PROTECTED]> 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ć <[EMAIL PROTECTED]> | http://radian.org >
_______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
