[Cryptography] Simpler programs?

Jerry Leichter leichter at lrw.com
Fri Apr 18 10:27:08 EDT 2014


On Apr 18, 2014, at 3:44 AM, Guido Witmond <guido at witmond.nl> wrote:
>> I'm not sure the Unix model is the correct model, but that's what we
>> have in Windows, MacOS, Linux, and Unix. KeyKOS had a Unix emulator. The
>> question always came up, "How compatible is it?" When we probed the
>> answer seemed to be, "We need bug for bug compatibility."
> 
> I'm very sure the unix model is not the correct model as hostile code
> can run inside a trusted environment.
> 
> In unix the maximum security-level (for each user-id) is that of the
> lowest security level of all of the programs that that user can run.
> Each program has access to everything that is important to the user,
> their files.
Both iOS and Android have changed this.  The Android model is straightforward:  Keep the basic security model, but re-purpose the notion of "user" so that it identifies not a person but an installed application.  I haven't looked closely enough at iOS to understand everything it's doing, but I think that's part of it - and also there's a mechanism (perhaps the same one?) to keep each application's data separate from every other application's.  (Even MacOS has had something of this general flavor for years - I ran across it at one point but forget the details.  iCloud deliberately doesn't look like a traditional file system and maintains the same kind of separation for files written by separate applications.)

I'm not *recommending* either approach.  The iOS/iCloud approach sounds great in theory, but ends up preventing all kinds of obvious information sharing that you'd really like to do.  The Android mechanism escapes this limitation by providing explicit ways around its limitations based on a privilege mechanism - which again sounds great in theory, but turns out to be incomprehensible and impossible for users to manage in any effective way.

We've had many years of development on two broad design schemes:  The Unix-style user/group/other model, with "user" being a single human's identity and all controls being discretionary (i.e., up to the "user", who's also the owner of the file); and the mandatory access control (MAC) ideas that came out of a military context and have seen relatively little use elsewhere.  ACL's of various power have been around for years, but are rarely used.  Both MAC's and ACL's have suffered because no one has come up with a good way for people to understand what they mean as actually applied to files.

Both approaches grew up in a world of time-sharing.  They worked reasonably well for back-end servers, until servers went multi-thread multi-tenant, which required them to re-implement security for themselves.  (VMS actually provided OS support for thread-specific OS security identities.  Since this idea never caught on elsewhere, at best, it would be used in VMS-specific code - no one would have any reason to add support for this kind of thing to Apache, for example.)

These were barely appropriate to workstations and PC's, and clearly inappropriate for the "truly personal machines" (phones, tablets) of today.  While, as I mentioned, OS's aimed for these environments have been looking for a new, more appropriate, model, none of them have really found it yet.

We desperately need new ideas here.  Unfortunately, today we also have the installed base problem that wasn't present when the current schemes were developed in the 1970's.  (How did God create the world in only 6 days?  No installed base.)  Today, any operating system that doesn't provide either the Windows API's or the Unix API's is a non-starter in the back-end and desktop worlds.  (There might be more "give" for personal machines, but if you don't have the weight of an Apple or a Google behind you, you stand little chance.  Even Microsoft is completely outclassed here.)

It's not as if this is new:  Mach, started in 1985, lives on only as a kernel hidden behind a Unix compatibility layer.  Clean, powerful ideas were fine - as long as it could run all that existing Unix code (complete, of course, the the Unix security model).
                                                        -- 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/20140418/495de6c7/attachment.bin>


More information about the cryptography mailing list