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

Register?

[*xpenguin*]

How can a tutorial that requires registration get accepted?

Re:Register?

[josephgrossberg]

Even worse, the story was submitted by the people who want you to register -- developerWorks.

Hey timothy ... if you guys were mixing in advertising with real stories ... like portals do with "search results" ... you'd let us know, right? Right?

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 :(...

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. :)

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.

Also VMWare

[Permission Denied]

VMWare is also useful for stuff like this. Set up a few VMWare virtual machines and you're good to go.

A couple of years ago, I went on vacation with no net access and only my laptop. I wanted to do network programming during my vacation. I set up four VMWare virtual machines running FreeBSD and did my little program (user-mode NFS server). Got a lot done in a short time (probably due to the lack of net access - had all the necessary docs saved ahead of time). I chose FreeBSD because it was much easier to cut down to a tiny image than any Linux distro (even Slackware, my favorite).

VMWare is also useful if you want to do OS-level programming (eg, write a kernel). This is one of my spare time projects (haven't touched it in years, though). I'd imagine user-mode Linux can't let you mess with the low-level stuff, but it could be useful for high-level stuff like scheduling algorithms and so forth (useful because it's a real PITA to boot up a machine whenever you change a line of code and user-mode Linux might give you some better debugging options than a serial cable).

You might be able to do this with Bochs nowadays, but Bochs was nowhere near useful back then. Seems to have come a long way in a short time.

Not sure what advantages user-mode Linux would have over VMWare or Bochs. Perhaps some karma whore would like to register and post the contents of the article :)?

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: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.

More Dual Mode Acronyms for us techies:

[xagon7]

UML.. User Mode Linux or Unified Modeling Language?

BSD.. Berkley Source Distrobution or Blue Screen of Death

sheesh

all we need now is Xylophone Medical Laproscopy, Super Qualatative Logon, and our hype acronym heaven will be complete! "MWAHAHAHAHAHAHA"

could this be...

[zogger]

...could this be a possible way to have "more" security while running and hooked to the net? Is there any angle here to make the virtual OS that's connected be totally locked away from the actual OS that runs everything, so that in the event of a major "owning" you could delete that virtual system, then reproduce it easily from a "spare" OS with it's set of apps that's already installed and clean? Sort of like the knoppix idea?

Re:could this be...

[AlXtreme]

Hmm, nice point, working in that direction on Morphix. The whole point is that it consists of different compressed filesystems, each one with a single purpose, in order to increase reusablility and lessen effects of attacks.

I was playing around with the idea of making chroot-ed jails for a server-based module, but using UML might be the way to go. I'm still working out the installing-procedure, trying to make up my mind if i want a regular debian-distro after an install or a setup like what you are describing.

And yes, it is based on KNOPPIX. well, the 33MB base module is :o)

Re:could this be...

[Ramses0]

In a similar vein, could somebody tell me why we don't have a concept of ExecAs( "$username-nobody" ) yet? It would just seem to make sense that you would want to give regular users the ability to Exec a program (sudo) as their very own non-entity (for me, that'd be "rames-nobody"). It would certainly make interacting with the internet / outlook / evolution style apps a lot more safe.

With linux, and using Debian, I'm at the point where I can say "Screw everything except what's in /etc and /home". But my /home directory is vitally important, and the *last* thing I would want a worm / virus to take out. The first time a buffer overflow in the Macromedia flash plugin takes out 50% of linux user's home directories is the only time people will pay attention to this problem (unfortunately)!

--Robert

Re:could this be...

[zogger]

--I bookmarked the page and will check it out later. Right now it won't display properly for me, but I'll try it again.

Yes, what you said, something like that. There's no real reason that the "core" install needs to have access to the net, when a virtual system can take the chances, and still "do the work". It makes by far the best sense to me yet of all the various security schema. It would also make upgrading better as you wouldn't be afraid of hosing your mission critical stuff while it's running.

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 :)

UML

[zelphi]

Before someone starts modeling OOP with this tool, they should get a new acronym. Why is it so hard to think of something original?

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.

poor man's solution

[zogger]

--the only thing I've done along these lines is to have a "spare" old hard drive with a basic system installed, that isn't plugged in to anything, but it's mounted in the drive bay. If I get a bad fubar, I'll more or less know what the last thing that happened was, so with the spare drive installed I can avoid that problem whatever it was before going online. But ya, it would sucketh to lose all the data and updates. I don't trust my level of expertise to make a backup dump or raid system all that valuable, as more or less I am as likely to just "backup" the virus or trojan should it become installed. I'm just a casual home user, not having to defend expensive server farms, etc, so the requirements aren't as great, but it still would be nice to have an easier to use method that what's available now, which is to become a security guru in your spare time. A virtual system that ran completely in a jail would be a good idea. I tried knoppix but it has some features I don't like (primarily I'm a gnome not a kde guy) and I couldn't make it dial out), but still, it's a step in the right direction and it ran surprisingly fast, much faster than I thought it would.

To get back to the subject, YES, an additional layer of "permissions" to access the system. Two stage isn't enough, you should be able to do an instant "create on demand" full system, use it for a session then trash it, thereby eliminating anything nasty that might have occurred to you, and that temporary system could be an additional step-->out away from the actual root or user level. There should be a "this is vulnerable being online so it can't do much and nothing permanent without jumping through hoops" temp-user level. A temporary trip wire action would help, and then the system would force you to go offline and compare audits before anything was 'saved' to the disk in either a users directory or at root level. It would be saved in the virtual OSs ram cache or on swap (a "virtual swap" inside the real swap as well?), examined, if it passes, THEN it can slide downhill into normal user-space. And the box needs it's own built in battery to keep ram cache intact in case of catstrophic outside failure, so that very important but still unexamined data is not lost. I've had UPSs fail, but when a laptop was plugged in, it didn't matter, I didn't lose anything or suffer file system damage, the built in battery concept is ideal for this, and I have no idea why it isn't just common on desktops as well. They are already big and heavy, a small battery is not that much more weight or space.