Introduction to User-Mode Linux

developerWorks writes "Ever wish you had a place to let your Linux applications play -- where they wouldn't hurt anything else? Do your killer apps spend too much time killing each other? Originally conceived as a kernel developer's tool, UML lets you set up multiple virtual machines that are isolated from each other and from the hardware. Now, you can test applications all the way to failure without breaking the host system -- or even requiring a reboot. Veteran administrator Carla Schroder shows you how in this tutorial."

Comments

Re:Register?

[MBCook]

This isn't an article, it's a free online educational course. That's why they want you to register. It's still free. Why don't you try LOOKING at things before you start to complain?

Bye bye karma :(...

More on UML

[jsse]

The link requires (free)registration. It has a guide for Debian installation too. For Gentoo users, you may also look at gentoo's guide on User-Mode Linux.

Re:Register?

[jsse]

Well said! In fact, IBM DeveloperWorks has a lot of free tutorials like you can find this one in Linux tutorial.

It's one of the site worth giving your email address to. The biggest spam you'd get from them is just a (bi?)weekly IBM DeveloperWorks newsletter which you can easily unsubscribe.

I'm by no mean associate with IBM, in case you wonder. :)

Re:Better

[CableModemSniper]

Um, UML is User-Mode Linux not User-Mode BeOS. And it doesn't emulate the processor. It provides virtualized instances of the OS, not an entire emulated virtual machine. You want UML Ultra5, you have to be on an Ultra5 machine in the first place. Ditto for RS/6000 or any other architecture.

Re:Also VMWare

[LarryRiedel]

Not sure what advantages user-mode Linux would have over VMWare or Bochs.

It lets the kernel run as a regular user process, and has been developed to interact with the host in that context.

http://user-mode-linux.sourceforge.net/uses.html

Larry

Re:what am i missing here?

[aridhol]

Theoretically, yes. However, there's always the chance that something will break. You may trigger a bug in the kernel that allows breakage. Or you may be developing the kernel itself. You run it in user space, and you have to trigger multiple bugs to break the host - a bug in the UML system and a (hopefully) different bug in the host system.

Re:could this be...

[Anonymous Coward]

Yes, this type of thing is used occasionally. I've seen people use VMWare for honey pots. It's also quite common to run various things in a chrooted environment, and FreeBSD provides an enhanced chrooted environment which allows you to pass specific IP traffic to a chrooted environment. Beware, though, that setting up a chrooted environment is a real PITA, especially if you don't have source to the intended program. Cute trick: you can give a chrooted environment controlled access to the real environment using hard links. See also this paper, which is probably one of the first honey pots. I would not recommend running a honey pot until you've written kernel modules and maintained production firewalls (requires programming, networking and sysadminy knowledge - honeypot by newbie = DDoS zombie/warez server/attack proxy).

As for your idea about deleting a virtual system and reproducing it - that's generally the way corporate desktop machines are managed. Either with some software tool like Norton Ghost, or with a dedicated hardware IDE drive duplicator (which is really nice since you can do a bunch of drives at once). You can also use "tar" or similar tools to make an image of a unix machine (I believe this is called a "backup" :). VMWare has a nice little feature in that its virtual disks are just files, so you can copy those around as you see fit, and it has a feature where changes to virtual disks do not persist across reboots, which is quite useful in Windows environments where you cannot easily monitor how some installation or patch modifies a production system.

Note though, that if your system is 0wned, you can't just restore a backup or re-image the drive. The hole which allowed it to be comprimised is still there, so you have to do a post-mortem to figure out how it was broken and patch it up. So this stuff doesn't make managing security a whole lot easier. It does make a lot of other management stuff easier (recovering from your own mistakes or from broken software).

It does give you certain benefits as it can separate access to data, but I don't know if this is such a big benefit anyways: if you actually have critical data that must remain confidential, it's easier to set up a chain of machines that have various access to the data (running different software and OSes each suited to the particular task) and set up strict firewalls between all of them (or, depending on time and needs, any level of access control between: process based (non-privileged daemons), filesystem based (chroot, virtual machines) or machine/network based (multiple machines, perhaps with custom network software that only exposes the minimum required access to the data as opposed to some general-purpose database interface)). Three reasons to spend time on security: protecting access to confidential data, ensuring integrity of critical data and keeping uptime for important services. Can get involved if you actually have to protect data instead of just keeping uptime: most people don't care and don't bother.

Re:could this be...

[Anonymous Coward]

In a similar vein, could somebody tell me why we don't have a concept of ExecAs( "$username-nobody" ) yet?

DIY (or, already been done, depending on how you look at it). What you want is accomplished in unix using setuid bits (usually only for escalating privileges) or setuid(2) (always for reducing privileges). This is how su and sudo work - look at their perms, and you'll see that su and sudo are setuid root. Root processes can also call setuid directly, so sudo goes becomes root on exec and can go to any user from there.

1. Set your umask to 022 or 027.
2. Create a new user (ramses-nobody)
3. Put user in your default group
4. Run command as new user. Processes run as new user will have read-only access to your files.

   A number of ways to do this:

   1. sudo -u ramses-nobody evil-command
   2. If your system doesn't have sudo (a problem which you should correct), su to root and then su ramses-nobody evil-command
   3. If you can't be bothered to type a password whenever you do this and this a single-user system, write a small C program which execs evil-command and then set it setuid ramses-nobody (setuid bit on scripts is ignored in modern systems, so it needs to be a C program). Entirety of program: #include <unistd.h>
      
      int main(int argc, char **argv)
      {
      argv[0] = "/path/to/evil-command";
      execv(argv[0], argv);
      return 1;
      } Compile, set permissions appropriately. Or, if evil-command is a binary and not a script, just change ownership of evil-command to ramses-nobody and slap on setuid bit.

If this is a multi-user system, the only practical method is (1): you can set up sudo so that regular user ramses can run anything as restricted user ramses-nobody. You can even tell it to not prompt for a password when going from ramses to ramses-nobody. If it's a big system, you set up scripts so it becomes part of the account creation process. OTOH, if it's an big multiuser system, you don't worry about any of this since you keep daily backups :)