But then they wouldn't be able to see that new awesome website that requires javascript 9.1 and flash 15.8 and 3 new plugins. You don't really expect them to give up that, do you?From: Stewart Stremler <[EMAIL PROTECTED] Don't understand the consequences of executable attachements? Say no, and have the software strip 'em out. Don't understand the consequences of running Network Services? Say no, and don't enable 'em on the system. Don't understand the tradeoffs and risks of Javascript? Disable it.
Malice cannot always be detected. It depends on _intent_, and there's no way of getting that into the system.
Don't you always set your evil bit?
They argue that this is why they need administrative access. They are trying to "minimize negative side effects".
So I think we need to phrase things differently. Coming up with that phrasing is proving to be difficult...
What we need is an efficient way of sandboxing processes. Because programs can often test their environment to see if they've been given the sort of control that the programmers desire, we need to have the sandbox be *transparent*.
What we really need are more fine grained permissions. Right now, all we have is root/not root. All or nothing. What really needs to be done is to allow file IO, network IO (of all different types- TCP, UDP, listen(), and connect() by port), execute, etc to be set separately. So you can set Apache to allow incoming connections on port 80 and read from /http, but not allow it to execute a program. All programs start with minimum permissions, and the OS querries the user for more if needed. Ideally permission sets could be saved so you can start a program with pre-arranged privlidges each time. Oh, and normal users could not grant additional privlidges beyond read/write in their own home.
Gabe
-- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
