[Cryptography] Simpler programs?

Ben Laurie ben at links.org
Sat Apr 19 00:55:55 EDT 2014


On 19 April 2014 04:04, Bill Frantz <frantz at pwpconsult.com> wrote:
> On 4/18/14 at 7:27 AM, leichter at lrw.com (Jerry Leichter) wrote:
>
>> 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.
>>
>> ...
>>
>>
>> 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.)
>
>
> Actually, there are a number of ideas which just need to be implemented. Two
> off hand are the Powerbox and objects.
>
> The Powerbox is used by an application to gain access to the user's files.
> To the user, it looks just like the OS file selection dialog which now
> appears. However under the covers, the power box has access to the user's
> files while the application does not. When the user selects a file for the
> application, the necessary permissions for current instance of the
> application are changed and it can now open the file. Polaris worked this
> way, with no changes to Windows or to the applications.

My understanding is that a powerbox is a way for an application to get
at a users stuff (which includes things like network access). Files
are an attractive example, because its clear how you create a seamless
replacement. In a windowed environment. Kinda (e.g. what about
temporary files? shared libraries? dictionaries? users do not want to
be choosing these thing by hand).

But it is less clear how you deal with other resources. Not that we
should give up on the idea, but it isn't a painless as you suggest.

Also, we're working on a powerbox for FreeBSD, Casper. Not much
written about it yet, unfortunately, but here's a slide deck:
http://people.freebsd.org/~pjd/pubs/Capsicum_and_Casper.pdf.

> A story from the
> Polaris developers (Alan Karp and Marc Stiegler): They installed Polaris on
> a HP Labs executive's PC while he was out of town with a training session
> scheduled immediately after he returned. Scheduling problems forced a delay
> on the training. When the training session started the executive asked,
> "When are you going to install it?" He had been running it for a week.
>
> Obviously there are more elegant ways to accomplish this goal, but MIcrosoft
> could implement a Powerbox in the next version of Windows. This change would
> be less trauma for Windows programmers and users than the redesign of the
> desktop look and feel that comes with every new release.
>
>
> Object are really an old idea. However, if properly used, they can provide
> security barriers within an application. Java does a good job here as do a
> number of other languages. Java lost out in the desktop market because it
> took forever for the Java Virtual Machine to initialize itself. This problem
> admits to several solutions and other object languages do not have this
> problem.

I think this is simplistic. Also, Java doesn't really do a good job
because of reflection.

> With current object languages it takes discipline to keep objects from
> accessing each other's innards. Coding standards are something most
> programmers are familiar with. Enforcing them is a somewhat solved
> management problem. But, you need someone who gets information hiding in
> their guts to write the standards and keep rewriting them until they are
> right.

We're also trying to help with that:
http://www.cl.cam.ac.uk/research/security/ctsrd/soaap.html.


More information about the cryptography mailing list