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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
