Reliance on Microsoft called risk to U.S. security

[Bill Frantz]

Peter has raised a number of important points.  Let me start by saying that
I do not see a strong distinction between a file to be viewed and a
program.  Both are instructions to the computer to perform some actions.
While we might think the renderer showing us flat ASCII text is quite
trustworthy, our degree of trust in an HTML should be less, and we
shouldn't trust a Word format renderer at all (thanks to Word Macro
viruses).

At 9:21 PM -0700 9/30/03, Peter Gutmann wrote:
>Bill Frantz <frantz at pwpconsult.com> writes:
>
>>The real problem is that the viewer software, whether it is an editor, PDF
>>viewer, or a computer language interpreter, runs with ALL the user's
>>privileges.  If we ran these programs with a minimum of privilege, most of
>>the problems would "just go away".
>
>This doens't really work.  Consider the simple case where you run Outlook with
>'nobody' privs rather than the current user privs.  You need to be able to
>send and receive mail, so a worm that mails itself to others won't be slowed
>down much.

I do not envision running either programs or viewers under the privileges
of the mail agent.  Since I am not really a Unix person, let me take a stab
at a design and let the people who know what they are doing take stabs at
it.

What we need is an environment of very limited privilege to use to confine
our untrusted code.  Specifically:

* No ability to make connections to other services, either over the network
or locally.  (I think this item requires a kernel change.)

* Very limited access to the file system.  We might take the view that
since we control all the ways the confined process can send data out of the
system, it can have full read-only access to the file system without
risking anything important.  I am told we can build general limits of file
system access with chroot, but I am also told that processes can break out
of these limits.  This is an area where I would love to learn more.

* We can pass in the privileges we think the process should have via open
file handles.  These will probably include the ability to render on a
portion of the screen, and the ability to get mouse and keyboard focus.
(We need a way for trusted code to mediate these accesses so the user can
have a "secure attention" function.)

* Strict control of other communication paths I haven't thought of.  :-)


>In addition everyone's sending you HTML-formatted mail, so you
>need access to (in effect) MSIE via the various HTML controls.

An HTML renderer should be able to run in the above environment.


>Further, you
>need Word and Excel and Powerpoint for all the attachments that people send
>you.

For viewing Word etc. documents, the applications should run in the above
environment.  The interesting case is where someone has sent you something
like a Word document and asked you to mark it up.  Everything should
proceed well in the above until it comes time to save a local copy or mail
the changed document back.

http://www.combex.com/papers/darpa-report/html/ describes the "Powerbox"
pattern for allowing the user to specify an output file for a confined
process such as we are discussing.  I would think the best way to return
such a file in Unix would be as an open file handle.  However I don't know
of a way for a program to call a service with greater privilege than it has
and accept a return value unless that service is part of the kernel.
Perhaps some Unix experts can come up with ideas.

As for mailing the document back, if the mail agent gave the confined
program read-write access to a copy of the file, the confined program could
write its output over the input and the mail agent could then make that
file available to the user when the confined program returns, and the user
could include it in the reply email.


>They need access to various subsystems like ODBC and who knows what else
>as an extension of the above.

Since most users do not have these facilities running on their machines, I
suspect that most Word/Excel/Powerpoint files would render quite well from
a confined process.  I would say that having random, perhaps hostile, files
able to update my local data bases is a violation of my security policy.


>As you follow these dependencies further and
>further out, you eventually end up running what's more or less an MLS system
>where you do normal work at one privilege level, read mail at another, and
>browse the web at a third.  This was tried in the 1970s and 1980s and it
>didn't work very well even if you were prepared to accept a (sizeable) loss of
>functionality in exchange for having an MLS OS, and would be totally
>unacceptable for someone today who expects to be able to click on anything in
>sight and have it automatically processed by whatever app is assigned to it.

UIs have changed considerably since the 1980s.  It turns out that modern
UIs make it much easier for users to run programs with only the privileges
they need than the UIs of the 80s.  (See the email thread at
<http://www.eros-os.org/pipermail/e-lang/2001-March/004818.html>)  Running
programs with only the privileges they need is a good way of controlling
viruses and other hostile programs.


>Even if you could somehow enforce the MLS-style restrictions and convince
>people to run an OS with this level of security enabled, the outcome when this
>was tried with MLS OSes was that users would do everything possible to bypass
>it because it was seen as an impediment to getting any work done: SIGMA
>eventually allowed users to violate the *-property to avoid them having to re-
>type messages at lower security levels (i.e. it recognised that they were
>going to violate security anyway, so it made it somewhat less awkward to do),
>Multics and GEMSOS allowed users to be logged in at multiple security levels
>to get work done (now add the 1,001 ways that Windows can move data from A to
>B to see how much harder this is to control than on a 1970s system where the
>only data-transfer mechanism was "copy a file"), KSOS used non-kernel
>security-related functions ("kludges") to allow users to violate security
>properties and get their work done, etc etc.

I am not sure that classical MLS really models well our current security
problem.  Consider the *-property.  Systems which enforce the *-property
say that less trusted processes can send data to more trusted processes but
they can't read data from more trusted processes.  The reverse of that is
also true, more trusted processes can read data from less trusted
processes, but they can't write data to them.  The application library is
available to everyone, so the policy allows the least trusted program in
the system to write the library, obviously a silly result.

I think our security problems today are much more in the area of protecting
systems from unauthorized modification than they are in the area of
protecting data from unauthorized access.  When I was doing Orange Book
stuff in the 1980s, the people I was working with called this "Integrity",
and said that is was no where as well understood as security (by which they
meant the Bell and LaPadula model, D. E. Bell and L. J. LaPadula , Secure
computer system: unified exposition and Multics interpretation).

Cheers - Bill


-------------------------------------------------------------------------
Bill Frantz        | "There's nothing so clear as   | Periwinkle
(408)356-8506      | vague idea you haven't written | 16345 Englewood Ave
www.pwpconsult.com | down yet." -- Dean Tribble     | Los Gatos, CA 95032


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com