At 8:12 AM -0700 9/27/03, [EMAIL PROTECTED] wrote: >On Fri, 26 Sep 2003, Bill Frantz wrote: > >> 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". >> > >And what privileges should the Perl interpreter run with when I click on a >".pl" file? How would the graphical shell know what privileges to assign >to each file?
Given a strange program that has just arrived on my machine, my current policy is not to run it at all. I might be willing to adopt a policy of giving it a small amount of memory, CPU, and some space to render on the screen. That would allow people to exchange active amusements with a degree of safety. If the program required more privilege (for example, a new version of a utility from a co-worker), I would be happy to move it to an environment where it had the resources it needs to run. >On the other hand a *trivial* privilege system: "View" (zero privs) vs. >"Run" (full privs) is viable, and is one of the pre-requisites for a more >secure UI, along with the previously discussed trusted path issues, >non-spoofing of the security interface, ... Limiting the privilege of the "View" program would provide protection against flaws in the viewer. Given the number of flaws in very basic software, such protection seems of have real value. 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]
