Other than spam, the biggest problems the average computer user faces today are viruses, worms, and spyware. These three problems are all instances of software which does things the computer user didn't expect or want them to do.

Interestingly, well-behaved application software in Windows and MacOS (with a few exceptions, like utilities, helper applications, and system applications) generally only needs to access a few types of files: (a) files created or owned (in the MacOS sense) by that application; (b) certain preference and configuration files; and (c) if anything else, usually read-only. Most applications have a similarly limited need to access network resources. in other words, most people don't try to open an Excel file using a screensaver, or send E-mail from Photoshop.

This suggests that creating a more restrictive security model can make it much harder for software to misbehave, with only minimal impact on the user.

From the Unix world (and directly carried into MacOS X and Linux), there is the familiar idea of file ownership and permissions on both the user and group level. Every file is owned by a user and a group, and every file has certain permissions (read, write, and execute) for the file's owner, members of the file's group, and everyone else. This model is easy to understand, and has proven to be very robust.

What I propose is to extend this model to include file ownership/permissions by application and application group ("suite"), and network permissions by application.

How It Works (for files)
Each file or directory would have two sets of ownership and permissions: both the familiar user/group/world permissions which exist today, and a parallel set for application/suite/any (a "suite" is a set of related applications, like Microsoft Office).

By default, a file or directory is owned by the application and user which created it, but the user-owner can change the application ownership, as can the application-owner. By default, the permissions would likely be read/write for the application and suite, and read only for other applications.

Just as with standard file permissions, an application can read, write, create, rename, and delete files if it has the appropriate permissions, with two new elements: (1) Both the application and the user must have permission (in other words, the permissions are always at least as restrictive as straight user/group permissions); and (2) If the application does not have sufficient permission for some action, but the user does, then the user may grant permission. This must be done through some explicit action by the user (for example, pop a distinctive window with a message like "The program NastyVirus wants permission to read addressbook.txt. Do you want to allow this?") handled by a system call.

How It Works (for network services)
Network services (such as opening a TCP connection, or listening for incoming connections) aren't "owned" the way files are, but both users and applications can have permission for certain actions.

By default, applications would have no permission to access any network services. Permission would come only through some explicit action by the user, and can be permanent or one-time (at the user's choice). Installer scripts could ask for the user to grant the appropriate permanent permissions to the application; and a system configuration application would let the user see what permanent permissions each application has and grant (or remove) them individually.

As with files, for an application to take some action, both the user and the application need to have the proper permissions. For example, if a user does not have permission to listen on TCP ports, then no application running under that user's account can listen on TCP ports.

Finally, some intelligence needs to be applied to permission requests. When a window is presented to the user asking for permission, it should say something like, "The application SpywareKeylogger wants to open a network connection on port 25 to mail.fbi.gov, probably to send an E-mail message. Do you want to permit this?" rather than a cryptic message like, "The application SpywareKeylogger wants to connect to 123.45.67.89 on port 25....."

Inheritance of Application Permissions
Programs which are launched directly by the user run under their own and the user's permissions. There's an ambiguous situation, though, when one application launches another application (for example, a utility or a "helper" application).

In most cases, the "helper" program should inherit the permissions of its parent--this avoids the loophole of using generic utilities like telnet or ftp to get around security restrictions on an application. For those cases where it is necessary for a "helper" to always run with its own permissions, the equivalent of the "suid" flag in Unix (which allows a program to run under a different user's permissions) can allow individual programs to always run under their own application permissions.

Other Thoughts....
* MacOS already tracks file ownership by application, so part of this idea is already in place.

* Essentially what this model boils down to is that programs always run under more restrictive permissions than the user rather than the usual model of programs running with the same permissions as the user. With well-thought-out default settings, it should be possible to add a very high level of security with only minimal disruption of the user experience.

* Asking the user for permission should be handled transparently at the system level. In other words, when an application tries to take an action (i.e. delete a file) which it does not have permission to do but the user does, the system notices this condition and pops a window to ask for permission. This should avoid the problem of trojans which ask for innocuous-sounding but destructive permissions: the window displayed to the user is controlled by the system, which can warn about potentially dangerous actions.

* For purposes of inheriting permission from a parent program, the kernel would need to track not just the user ownership of a process, but the application ownership. Not being a kernel programmer, I'm going to hazard a guess that this would involve ripping out the guts and starting over from scratch. In other words, this whole concept is hopelessly impractical...

* Most existing security models are based on the notion that the average user is untrusted (i.e. only allowed limited access to system files and other users' files). This proposal extends that to include the notion that the average program is also untrusted. This seems entirely appropriate for an age when most users are not programmers, and many programmers (especially the big software companies) are pursuing agendas often at odds with the user's goals.

* If Microsoft ever implements this, then Windows will default to giving super-permissive privileges to Office and Outlook.