Compartment Security Model Date: 2007-11-27 12:08:52
All this recent complaining about the horribly botched UAC got me thinking. Also, I had to install a lot of stuff on several computers and different operating systems recently. There is a kind of obvious observation about all OSes' security systems: they all work exactly the same.
It doesn't matter whether you're on XP or OS X or Vista or Linux: you execute an installer with administrator privileges and then you sit down and pray to your favorite tech-deity the installer does exactly what it promised you beforehand instead of, say, installing a rootkit or something.
Is it really essential for installers to have root? No, certainly not! If an operating system would provide a compartmentalization mechanism it wouldn't be necessary for 99% of all apps that you ever wanted to install.
The idea is simple: every app gets a designated little bucket where it can put its files and its user data. The system even creates a user account for the app to run as, it doesn't even have to run under the current user's account in most cases.
This would virtually guarantee that neither the installer nor the application itself can do anything shady to your system. But there is more. Let's face it, the most sensitive part of your electronic home isn't the operating system, as all the software stuff can be re-installed when something goes awry. No, the most important stuff on your computer are your files! It doesn't really make sense to grant every application access to all your files. Even if by some miracle a malicious piece of software doesn't manage to get privilege elevation, it still can freely delete, corrupt or upload all of your data.
So, compartmentalization can be an easy answer. Nothing more secure than a program that can't see or access anything else but its own little world. It's a simple and workable alternative to the increasingly complicated soup of security applets and kernel layers and whatnot. Why is nobody working on this?
It doesn't matter whether you're on XP or OS X or Vista or Linux: you execute an installer with administrator privileges and then you sit down and pray to your favorite tech-deity the installer does exactly what it promised you beforehand instead of, say, installing a rootkit or something.
Is it really essential for installers to have root? No, certainly not! If an operating system would provide a compartmentalization mechanism it wouldn't be necessary for 99% of all apps that you ever wanted to install.
The idea is simple: every app gets a designated little bucket where it can put its files and its user data. The system even creates a user account for the app to run as, it doesn't even have to run under the current user's account in most cases.
This would virtually guarantee that neither the installer nor the application itself can do anything shady to your system. But there is more. Let's face it, the most sensitive part of your electronic home isn't the operating system, as all the software stuff can be re-installed when something goes awry. No, the most important stuff on your computer are your files! It doesn't really make sense to grant every application access to all your files. Even if by some miracle a malicious piece of software doesn't manage to get privilege elevation, it still can freely delete, corrupt or upload all of your data.
So, compartmentalization can be an easy answer. Nothing more secure than a program that can't see or access anything else but its own little world. It's a simple and workable alternative to the increasingly complicated soup of security applets and kernel layers and whatnot. Why is nobody working on this?
Comments
EMSPV says
(2007-11-28 00:02:44)
This is already extensively done under Linux. Every build system on every major distribution runs chrooted in a nobody account environment. Look at Gentoo's portage, at FreeBSD's port system. Of course, everything could be done better, with an even more secure containment. But where do we stop? Actually, applications do have to communicate with the rest of the world, and this is done by sending messages, accessing files, and so on. In the end, people will begin to complain that they just want to use drag & drop. ;-)
Udo says
(2007-11-28 00:13:56)
This is exactly what I mean. While it doesn't make sense to separate background/console apps beyond what's already possible, there is some huge potential for GUI applications. Incidentally, this is the type of app that casual users are most likely to download and install from untrusted sources.
So, as you said, in order for this to work in GUI applications, there would have to be some additional plumbing that simply isn't there today. In every graphical OS I know, those apps are executed in the name of (and on behalf of) the actual human user who owns the current session. Thereby, any program I launch can access all of my data. For most apps there is no reason to do that, but they can do it anyway.
Right now, the only protection against that is to ask the user for root privileges at install time. That shouldn't be required to install GUI apps that are only supposed to work for my account anyway. But that's not even my main concern. Rather I think it's kind of irresponsible to run every app with the full rights of the user who launched it. For instance, why does a new chat software have to have access to my files?
So, as you said, in order for this to work in GUI applications, there would have to be some additional plumbing that simply isn't there today. In every graphical OS I know, those apps are executed in the name of (and on behalf of) the actual human user who owns the current session. Thereby, any program I launch can access all of my data. For most apps there is no reason to do that, but they can do it anyway.
Right now, the only protection against that is to ask the user for root privileges at install time. That shouldn't be required to install GUI apps that are only supposed to work for my account anyway. But that's not even my main concern. Rather I think it's kind of irresponsible to run every app with the full rights of the user who launched it. For instance, why does a new chat software have to have access to my files?
EMSPV says
(2007-11-28 01:40:16)
Perhaps just because you might want to transfer whatever file via DCC to another guy in the chat room? At the moment you code your app, you try to think about what your user might want. Normally, you stop when you have a fairly huge amount of "must haves", "should haves" and exciters. If you try to go beyond this scope to imagine even more potential user interactions, your head will explode.
Alot can be done by using message systems like D-Bus. Messages like "hey, the user wants to drag something from app foo to app bar" would be enough for most of the GUI interactions. But eventually the user will have his app to access some data, the programmer doesn't know what files this will be. So, with a containment area for each program, we end up with alot of "do you want to allow Foo to access the file /home/user/quuz?", and after 10 of these boxes, any user will just click on "yes." He will even cry out for a "Never ever bug me again with this shit" option. (Thats the whole problem of UAC anyways in my eyes.)
By the way, Linux doesn't require an installer to have root privileges. You can install and run any software you like from your home directory. I do this with alot of apps.
Alot can be done by using message systems like D-Bus. Messages like "hey, the user wants to drag something from app foo to app bar" would be enough for most of the GUI interactions. But eventually the user will have his app to access some data, the programmer doesn't know what files this will be. So, with a containment area for each program, we end up with alot of "do you want to allow Foo to access the file /home/user/quuz?", and after 10 of these boxes, any user will just click on "yes." He will even cry out for a "Never ever bug me again with this shit" option. (Thats the whole problem of UAC anyways in my eyes.)
By the way, Linux doesn't require an installer to have root privileges. You can install and run any software you like from your home directory. I do this with alot of apps.
Udo says
(2007-11-28 01:56:04)
Perhaps just because you might want to transfer whatever file via DCC to another guy in the chat room? [...]
That's not a problem if the file selection dialog would be able to pass along the access permission for the single file that has been explicitly chosen by the user.
If you try to go beyond this scope to imagine even more potential user interactions, your head will explode.
Not really, the goal is simplification. How often does a classical GUI app need to access data that is outside its domain? Not that often.
Btw, I'm actually talking about reducing the number of warning dialogs. And to come back to my original argument: most applications do not need access to all my files. How much integration is there anyway between this stuff? When was the last time you saw the browser access your OpenOffice templates? Why does the browser process need to see anything outside its domain? There are very few apps that need to talk directly to one another through my personal files, right?
The number one reason why attacks like buffer overruns are so dangerous is the danger of having suddenly having a hostile application running on the user's behalf. Same thing happens if users download a trojan payload with, say, their latest favorite porn collection. Compartmentalization would significantly reduce the effect of such attacks with the added benefit of having a security model that is not based on warning dialogs.
By the way, Linux doesn’t require an installer to have root privileges.
At least that's a little better than Windows, where Admin is required to execute most - if not all - installers. If for no other reason than writing to the registry (dont' even get me started on that).
That's not a problem if the file selection dialog would be able to pass along the access permission for the single file that has been explicitly chosen by the user.
If you try to go beyond this scope to imagine even more potential user interactions, your head will explode.
Not really, the goal is simplification. How often does a classical GUI app need to access data that is outside its domain? Not that often.
Btw, I'm actually talking about reducing the number of warning dialogs. And to come back to my original argument: most applications do not need access to all my files. How much integration is there anyway between this stuff? When was the last time you saw the browser access your OpenOffice templates? Why does the browser process need to see anything outside its domain? There are very few apps that need to talk directly to one another through my personal files, right?
The number one reason why attacks like buffer overruns are so dangerous is the danger of having suddenly having a hostile application running on the user's behalf. Same thing happens if users download a trojan payload with, say, their latest favorite porn collection. Compartmentalization would significantly reduce the effect of such attacks with the added benefit of having a security model that is not based on warning dialogs.
By the way, Linux doesn’t require an installer to have root privileges.
At least that's a little better than Windows, where Admin is required to execute most - if not all - installers. If for no other reason than writing to the registry (dont' even get me started on that).
Name
Email
URL(optional)
Text
Page time:
0.962 seconds.