[EROS-Arch] Re: [E-Lang] Interaction Design for End-User Security

[Bill Frantz]

At 9:21 PM -0800 3/16/01, Mark S. Miller wrote:
>At 05:01 PM Friday 3/16/01, Ka-Ping Yee wrote:
>>As i'm sure you all realize, the user interface is critical since
>>it communicates intent, and it is only from an interpretation of
>>that intent that a meaningful definition of security is possible.
>>
>>Miriam Walker and i worked together on a paper last semester to
>>describe and apply a set of design principles for usable security.
>>Mark has encouraged me to post it here for review.  Here it is:
>>
>>    http://www.cs.berkeley.edu/~pingster/sec/project/
>>
>>We're very interested in your thoughts on the topic and look
>>forward to your comments on the paper.
>
>I'd like to emphasize just how crucially important this work is, as well as
>how good it is.  Security isn't very meaningful if humans can't be securely
>included...

Miriam and Ping - I am very impressed with this paper.  Your Principles of
Secure Interactive Design seem to be right on.  However, I do have a couple
of comments:

4.5 Software Installation and maintenance (Device Drivers)

The common device driver interface in most operating systems (Mac OS/OS X,
Windows, NT, Linux, BSD, etc.) gives far too much authority to the device
driver.  Generally they run at the highest privilege level in the machine.
This level of privilege is not necessary.

We can look at the examples of IBM OS/360 and IBM VM/370.  In both these
systems, channel programs were built by unprivileged code, and later
scheduled with a system call.  In the case of VM/370, which created a
virtual 370 architecture "machine" for each user, it would translate and
validate the user's channel program as part of emulating the StartIO
instruction.  While the process of translation and validation was delicate,
and was released with a number of security bugs, it was certainly less
complex then security processes such as the Java byte code verifier.

KeyKOS/370 performed a similar process, but was MUCH more restrictive in
the channel programs it would accept.  (In KeyKOS/370, the disk drivers
were in the kernel, however other drivers, such as the disk formater and
the tape and printer drivers were outside the kernel.)

The biggest problems with putting device drivers outside the EROS kernel
come from performance issues, and the desire to port BSD or Linux drivers
easily.


5.1 Installing and Launching Applications

"... Untrusted documents downloaded from elsewhere must be associated with
applications explicitly by user selection from a menu of the local names
for application factories."

An approach similar to that used by Internet Config on Macintosh systems
could be used.  Internet Config maintains an association between file
extensions and applications.  There are certainly risks associated with
this automatic selection, but if the application factories selected have
minimal privilege it should be manageable.

<cynic>
Of course, to maintain backward compatibly, Microsoft will deliver the
system with the extension .vbs associated with a Visual Basic interpreter
which has read/write privileges at the file system root.
</cynic>

Cheers - Bill


-------------------------------------------------------------------------
Bill Frantz       | Microsoft Outlook, the     | Periwinkle -- Consulting
(408)356-8506     | hacker's path to your      | 16345 Englewood Ave.
frantz@netcom.com | hard disk.                 | Los Gatos, CA 95032, USA