[Cryptography] North Korea and Sony

[Jerry Leichter]

On Dec 12, 2014, at 1:15 AM, Bill Frantz <frantz at pwpconsult.com> wrote:
>> Right now there do not seem to be any capability-based secure
>> Operating systems that have reached a level of development
>> making them viable as real options for real companies to be
>> using for everyday work.
>> 
>> Could this be fixed?
> Marc Stiegler, Alan H. Karp, Ka Ping Yee, and Mark Miller addressed this specific issue for Windows in "Polaris: Toward Virus Safe Computing for Windows XP", <http://www.hpl.hp.com/personal/Alan_Karp/polaris.pdf>. The basic approach (described on page 5) is to run these programs under a separate userID, unique to the program. It seems likely that their approach would extend to other popular systems.
Both Android and, I believe, iOS do this already.  Probably ChromeOS, too.

It's an interesting re-use of the basic system capabilities.  All three of these systems grew out of Unix, which was a time-sharing system.  Such a system needs to protect users against each other, so developed a way to identify users and then do authentication based on user id.  Modern devices are pretty much intended for use by one user - but that user no longer completely trusts the code he runs.  So we can flip things around and identify not users, but individual programs.  All the isolation that the traditional systems enforced between users now isolate programs from one another; in fact, now you have to figure out what should be shared between programs and how to share it.

The old division between discretionary access control - controlled by the users - and mandatory access control - controlled by system policy, not directly influenced by the user - has been flipped around, and the mechanisms that used to be discretionary are now controlled by policy and are mandatory.

BTW, it's this repurposing of the user ID mechanism that makes it complicated to support multiple users on devices running these OS's.

                                                        -- Jerry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4813 bytes
Desc: not available
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20141212/8c00c627/attachment.bin>