There are three ways to approach the problem of determing the correct constraints for software, as discussed in a previous journal entry.
- Ask the user to grant permissions “just in time”
- Provide pre-written trust profiles that bundle together allowed actions, then let the user select each one
- Have some external authority determine trust. Won’t deal with this one today.
A real world implementation of the first is my Sony Ericsson W800 mobile phone. Like most J2ME phones, when a mobile app wants to do something potentially Evil, the application manager asks the user a simple question like, “Allow FooApp to take photos with the camera?” or “Allow FooApp to access the internet?”. Access decisions can be remembered. There are only 7 permissions:
- Internet access
- Messaging
- Automatic start
- Local connectivity
- Multimedia
- Read user data
- Write user data
These are all self explanatory. Even though apps can be quite sophisticated and do a lot of stuff, the permissions scheme is still intuitive, managable and it doesn’t normally get in your way. Note that “Read/write operating system internals” is not an option here, which is sensible because you can’t upgrade the OS by installing a J2ME Jar file. Instead you must use a SonyEricsson proprietary upgrade app which works via the USB cable. The different mechanism (wireless/over the air install vs USB) acts as simple trust cue: no app should ask you to install it in a totally different way to every other app. If it does that’s a good sign somebody is up to mischief.
Internet Explorer is an example of a program that uses the second approach. You can change the security level of each “zone”. In high security mode many things are disabled, like ActiveX controls and even cookies. In low security mode things are very permissive so you get max compatibility. Often a workaround for an exploit is to change security levels.
applicability to desktop operating systems
Sometimes people argue we should use the first system – selective granting of permissions – on desktop computers too. I’ve even seen somebody say with a straight face that it should be done on an individual syscall level, a suggestion that was rightly laughed at. But does this make sense? Is it possible to apply only 7 permissions to the full universe of software and get away with it? If not, how many permissions are too many? SELinux already has many, many different permutations of permission sets a process can have, most of them esoteric and low level (eg, connect to server X, ptrace, send data over message bus, screenshot an X window, access USB devices …)
So what about the second approach, that of fixed profiles which bundle up many different permissions? The user would assign an program a profile at install time. There are a whole bunch of different design issues here. For one, should you use an IE style “high security/low security” sliding scale? I don’t think so. How can the user objectively decide this? “High” is so relative it’s meaningless, there’s no way to figure out if an application needs high or low privs to work correctly.
A better style would be something like, “Internet Application”, “Game”, “Multimedia Application”, “Maintenance Tool” etc. But obviously much software can’t be pigeonholed like that. iTunes is both a Multimedia Application and an Internet Application. The next logical step is to let the user select more than one profile at once, the set of privileges granted to a process is then the union of all the selected profiles. It’s up to the user to decide what categories a program falls into, and up to the program to test for the exact privs it needs and if it doesn’t have them, ask the user to grant them along with an explanation of why it’s necessary. Arguably what we’ve done now is go back to the explicit privilege granting model except not done just-in-time and with renamed privs. But that’s not necessarily a bad thing.
Of course, users can still be socially engineered into granting excess privileges to an application which is why I argue the most important privs like operating system modification shouldn’t EVER be grantable by a user. But, through careful selection and authoring of profiles, I think we can help the user make the correct decisions much more often than they do now.
