"User Mode Linux allows you to run Linux kernels as user mode processes under a host Linux kernel, giving you a simple way to run several independent virtual machines on a single piece of physical hardware. Let's take a look at UML and how it can give you more bang for the hardware buck, or make it easier to debug the kernel."
Post a Comment
Member since:
2005-10-22
Fans: 0
Member since:2005-07-02
Fans: 23
Member since:2006-08-25
Fans: 0
Member since:2006-03-23
Fans: 0
Member since:
2005-07-09
Fans: 12
Member since:2005-07-01
Fans: 0
You mean Matryoshka?
http://en.wikipedia.org/wiki/Matryoshka_doll :]
Member since:
2006-02-06
Fans: 0
I am no expert in virtualization and emulation, so I'd like to ask something:
Can this be used to insulate a potentially dangerous application like a web browser or any other network based application in a diferent virtual machine, and then run them side by side, the host holding the local documents and projects and most work the user has, with the emulated virtual system executing everything web-related (browsers, im and all that stuff) ?
I don't know if it would be feasible, since it would probably waste a lot of disk space and memory running things like this but... is it possible ?
Member since:2007-01-12
Fans: 0
I had the same idea. Step one is to build a minimal rootfs/chroot environment. A lot of that is done with symlinks into the outside filesystem, for example /usr/bin, so it will not "waste a lot of disk space". Also, you don't need as many libraries, applications, etc. to run selected applications like Firefox.
One also has to symlink some X11 Unix domain sockets (located in /tmp) into your chroot environment so that X applications can be launched. One may have to allow connections to the X server from the chroot environment, which may seem to be a "external machine" (xhost +127.0.0.1).
What UML adds over and above the chroot protection is the ability to capture an attempt to remount, for example, /dev/hda1 in order to break out of the chroot jail. So, the chroot environment built in step 1 is the input to step 2 where you run the same rootfs in UML. I ran Firefox, Opera, etc. in a chroot so I feel like with this could be done with a few hours of learning UML configuration.
You are correct that the security of $HOME is a neglected topic; sometimes attacks are launched to get the information in $HOME and not to try to "own" the box. This does go against the dogma that no one cares what happens to a users directory/information on a *NIX box.
Member since:2005-12-02
Fans: 0
"You are correct that the security of $HOME is a neglected topic; sometimes attacks are launched to get the information in $HOME and not to try to "own" the box. This does go against the dogma that no one cares what happens to a users directory/information on a *NIX box."
Well said. The users directory is the most important part of the box, since that is where the data is. Unfortunately very few people seem to understand that. Owning the box is bad, but the loss of data is much worse. On the other hand, if someone owns the box they can compromise ALL of the home directories, instead of possibly just that of the 1 user that does something stupid.
Member since:2005-11-11
Fans: 1
Well said. The users directory is the most important part of the box, since that is where the data is.
If the box is serving webpages or SQL or something there need be no user directory to speak of. For a desktop box, the user directory is important, but let's be honest: the desktop is just not linux's strong point right now. (I use it on my desktop exclusively, but that just means I know exactly how few people are ready to).
Member since:2005-12-02
Fans: 0
"If the box is serving webpages or SQL or something there need be no user directory to speak of. For a desktop box, the user directory is important, but let's be honest: the desktop is just not linux's strong point right now. (I use it on my desktop exclusively, but that just means I know exactly how few people are ready to)."
True enough, but is all how the box is set up. Some of mine server web pages, and they do so from a user directory so I leave the system partitions intact. For an ISP, most of the web pages are served from user directories. Want a customer ticked off? Tell them that their home directory was lost.
Member since:
2005-11-28
Fans: 0
>>Can this be used to insulate a potentially dangerous application like a web browser or any other network based application in a diferent virtual machine, and then run them side by side, the host holding the local documents and projects and most work the user has, with the emulated virtual system executing everything web-related (browsers, im and all that stuff) ?<<
>>I don't know if it would be feasible, since it would probably waste a lot of disk space and memory running things like this but... is it possible ?<<
This is overkill for this type of thing, depending on which OS you are using there are things that already do this, examples are 'Jails' or 'Chroot' ing applications.
If you want a reasonably technical view of how this works with applications http://www.openbsd.org/faq/faq10.html#httpdchroot is a good example. It describes how Apache HTTPD on OpenBSD is isolated from the rest of the system and how you as an operator have to work with it. Even if you don't use OpenBSD it is a good primer to the concepts and how they affect the operation of the rest of the system.
You can run virtual servers to contain applications you wish to isolate but for many applications there are tools to isolate them safely already, there are always exceptions to the rules. Sometimes there may be an application that ties into so many aspects of the server and was so deeply integrated that it is not possible or practical to isolate it and that is where virtualisation can be useful.
In an ideal world there would be no need to run something you don't trust, sometimes circumstances dictate that you have to.
Before people start flaming about trustworthy applications, HTTPd is a trustworthy server, infact the most popular HTTP server on the net (sources Netcraft, but this time I think they are about right 
) the OpenBSD team chrooted it after a spate of vulnerabilities a long time ago, but it does make sense for a hostile Internet facing server.
Anyway I only wanted to post the link then got distracted...