Sun, 24 Apr 2011 11:39:00 GMT
Thinking of user accounts in unix-like systems, a lot can be done to secure the several users one from another:
Of course, from time to time there are privilege escalations, but bugs are not the major problem, in my humble opinion: There is quite a lot of software that breaks the barriers provided by the kernel. X11 would be an example of a possibility to break through this barrier: Let two X-Clients connect to the same X-Display, and they can send keystrokes, etc., and this is not limited to one machine either. On the other hand, of course, in the case of GUIs, there is no easy way to do it differently, if one wants to be able to take screenshots and send special events to other applications. And this is not limited to X11, as the Win-API gives a possibility to send keystrokes, take screenshots and even change some captions, and I think the Cocoa-API of OS/X allowes something similar. And while taking screenshots is hard to forbid, there are possibilities to create additional barriers, like Xnest in the case of X11.
On the other hand, there are things like DBus which form an RPC-Mechanism that also may break barriers between users. And of course, there are nice things like the setuid-bit.
Still, all of these mechanisms remain safe if used with caution. The worse thing comes from software that forces the user to remove barriers.
While it is generally a good thing to make user directories only readable, writable and executable by the current user, a common configuration of Apache, using mod-userdir, requires user directories to be +rx for at least the group, such that the user can put its content into a subdirectory www-public of his home directory. This setup is so annoying, especially in large computer pools where I do not want every other user to be able to read my local configuration. And it does something dangerous: It motivates users to be sloppy about access control. I would prefer a setup that has separated directories, maybe in /var/users, that can be symlinked into the user-directory (to make it easier for the users to handle), but are not read from there.
In general, when a user's access to system ressources is limited far enough, there should be no problem for him to run arbitrary executables, and in fact, the major problem mostly lies in the executables they want to run rather than the configuration. Thus, while I can remember that older hosting-providers gave user accounts, most modern providers give you a VPS. Ok, this is what the technical evolution brought us, and a VPS is easier to use and secure than multiple user accounts. It is simple to use multiple software distributions on the same machine, and have strong barriers between them. Often, technical progress evolves differently than intended at first.
The real question is whether the same will not happen to architectures with many virtual machines. A sufficiently cooperative operating system can already degenerate into a runtime library with the right virtualization environment. With the first companies giving up on securing their software and putting them in sandboxes, it might be just a matter of time until putting every larger application into a sandbox becomes common - which causes problems: Think of a webbrowser - with its own filesystem, you cannot easily download files and open them externally, without punching holes. But punching holes means breaking barriers, and breaking barriers usually means lowering security. The simplest configuration, and possibly the only one that unexpierienced users would accept, would be to give the virtual machine full access to your home directory (as far as I remember, that is what VMWare Fusion does, but VMWare Fusion is not meant to provide security) which makes the sandbox almost useless for security: The user will have most of his important files in his home directory.
I already wrote an article on that topic on my old blog (in German), which was, as I just noticed, inspired by an earlier article on Heise, about the same software as the one which inspired me to write this post.
I did not test the software yet: It needs at least 4 gig RAM, and it is not recommended to virtualize it - I simply have no machine to run it currently. But I do not want to doubt the quality of this software, as it sounds like they knew what they did, and it also sounds useful, and using virtualization as one of many security precautions is ok.
I just do not like the idea of using virtual machines as a primary security precaution.
- Limiting the network access
- Limiting the number of processes
- Limiting the amount of RAM
- Limiting the amount of disk space using quotas
- Limiting the access to files, especially device files
Of course, from time to time there are privilege escalations, but bugs are not the major problem, in my humble opinion: There is quite a lot of software that breaks the barriers provided by the kernel. X11 would be an example of a possibility to break through this barrier: Let two X-Clients connect to the same X-Display, and they can send keystrokes, etc., and this is not limited to one machine either. On the other hand, of course, in the case of GUIs, there is no easy way to do it differently, if one wants to be able to take screenshots and send special events to other applications. And this is not limited to X11, as the Win-API gives a possibility to send keystrokes, take screenshots and even change some captions, and I think the Cocoa-API of OS/X allowes something similar. And while taking screenshots is hard to forbid, there are possibilities to create additional barriers, like Xnest in the case of X11.
On the other hand, there are things like DBus which form an RPC-Mechanism that also may break barriers between users. And of course, there are nice things like the setuid-bit.
Still, all of these mechanisms remain safe if used with caution. The worse thing comes from software that forces the user to remove barriers.
While it is generally a good thing to make user directories only readable, writable and executable by the current user, a common configuration of Apache, using mod-userdir, requires user directories to be +rx for at least the group, such that the user can put its content into a subdirectory www-public of his home directory. This setup is so annoying, especially in large computer pools where I do not want every other user to be able to read my local configuration. And it does something dangerous: It motivates users to be sloppy about access control. I would prefer a setup that has separated directories, maybe in /var/users, that can be symlinked into the user-directory (to make it easier for the users to handle), but are not read from there.
In general, when a user's access to system ressources is limited far enough, there should be no problem for him to run arbitrary executables, and in fact, the major problem mostly lies in the executables they want to run rather than the configuration. Thus, while I can remember that older hosting-providers gave user accounts, most modern providers give you a VPS. Ok, this is what the technical evolution brought us, and a VPS is easier to use and secure than multiple user accounts. It is simple to use multiple software distributions on the same machine, and have strong barriers between them. Often, technical progress evolves differently than intended at first.
The real question is whether the same will not happen to architectures with many virtual machines. A sufficiently cooperative operating system can already degenerate into a runtime library with the right virtualization environment. With the first companies giving up on securing their software and putting them in sandboxes, it might be just a matter of time until putting every larger application into a sandbox becomes common - which causes problems: Think of a webbrowser - with its own filesystem, you cannot easily download files and open them externally, without punching holes. But punching holes means breaking barriers, and breaking barriers usually means lowering security. The simplest configuration, and possibly the only one that unexpierienced users would accept, would be to give the virtual machine full access to your home directory (as far as I remember, that is what VMWare Fusion does, but VMWare Fusion is not meant to provide security) which makes the sandbox almost useless for security: The user will have most of his important files in his home directory.
I already wrote an article on that topic on my old blog (in German), which was, as I just noticed, inspired by an earlier article on Heise, about the same software as the one which inspired me to write this post.
I did not test the software yet: It needs at least 4 gig RAM, and it is not recommended to virtualize it - I simply have no machine to run it currently. But I do not want to doubt the quality of this software, as it sounds like they knew what they did, and it also sounds useful, and using virtualization as one of many security precautions is ok.
I just do not like the idea of using virtual machines as a primary security precaution.