I love to see comments like this, because that is what my research is designed to do. Make it easy for end users (or admin) to specify what an application is supposed to do, and the program is restricted to the behaviour that is needed to do those things. For example, so you can say "this program is a web browser and an email client". Then, if you like, you can give some app-specific details such as "I download stuff to this directory", or "I only want access to these hosts". Then the program cannot do anything beyond what would be expected of those types of programs. In case you are interested, a Linux implementation is available: http://schreuders.org/FBAC-LSM

My research and Linux implementation allows users to restrict apps based on the features they provide. To confine a PDF viewer you simply specify that it is a "PDF viewer" (which it would more than likely suggest to you), then if you like you can specify where the pdf files are stored on the computer. A bunch of other details are automatically detected. Then the program will only be able to access the libraries and resources it requires to run, and only the pdf files in the places you specified. Presto, if the program is malware or has vulnerabilities it is severely limited in the damage it can do. You can do the same for Web browsers, games etc. Check it out: http://schreuders.org/FBAC-LSM

While AppArmor can be considered a huge improvement usability-wise over some previous systems, policy can still be extremely complex, as it exposes the complexity of the resources used by applications and platforms. I ran a usability study, which amongst other things showed that even many advanced users and experienced Linux system administrators cannot successfully vet the policies created in learning modes such as that used in AppArmor. One of the problems with this approach is that typical applications can require access to a myriad of resources, of which the security implications are not always clear. Also you need to run the program in order to create a profile, so this approach cannot protect against malware. I think having a database of user-created profiles is a great idea. Although, if someone wants to use the program differently, only grant the program permission to access particular resources, only use a certain features of the program, or understand what the program is allowed to do, or restrict a new program, then higher levels of abstraction (such as with FBAC-LSM) can help make this possible. FBAC-LSM can create policies before running the program, and FBAC-LSM has other features such as allowing normal users to create policies for the applications they use, to protect their own data.

Looks like a nice approach to program isolation. A system which was in some ways similar to Qubes was developed for Windows known as WindowBox. My research takes another approach, program restriction. Systems such as SELinux and AppArmor allow precise policies to define the types of actions and resources which are made available to each application. However, the finer the granularity of privilege assigned, the more detailed and complex policies become. The system I created for my PhD research, FBAC-LSM, restricts applications based on the functionalities they perform. Eg Web Browser, Email Client, Image Viewer etc. Then the programs can not act beyond the things they need to do, and the damage which can be caused by vulnerabilities and malware is severely limited. Basing policy on functionalities means that policy is easier to construct (since it is based on high-level abstrations) than other systems based on fine grained restrictions. The advantages compared to isolation systems such as Qubes is that normal work flows (where a user creates, views, edits and shares the same files with many different apps) can be used while each application is restricted to the privileges it needs. FBAC-LSM is in development and is available as free open source software: http://schreuders.org/FBAC-LSM