Login | Register   
RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Ubuntu Eye for the Debian Guy: Running Linux on Linux : Page 5

Take a journey around the world of Ubuntu 7.10 without exiting from Debian. Along the way, you'll learn how to run multiple Linux-in-Linux instances for development and study.




Full Text Search: The Key to Better Natural Language Queries for NoSQL in Node.js

Enjoying the Full Ubuntu Experience
Remember that to this point I had built only the basic root filesystem for Ubuntu 7.10. To experience the typical Ubuntu desktop, I had to install it. Nothing has ever been easier because I was already connected to my LAN and I could just run the command:

apt-get install ubuntu-desktop

This operation took a long time to complete because it required the installation of many packages. It is also a memory-consuming process, so because the host system uses tmpfs abstraction, I had to make it 1GB large at least. I accomplished this by putting the following line in the host file:

tmpfs /tmp tmpfs size=5000M 0 2

In addition, I had to install Xnest X server because I needed a complete remote X session on the host:

apt-get install xnest

I also had to allow the remote X sessions on the host:

xhost +

And finally in the UML I ran these two commands:

Xnest :1 & gnome-session --display=:1 &

At this point, the Ubuntu desktop popped up in a window of my Debian host (see Figure 2).

Figure 2. UML Ubuntu Sessions Running: You can see the two UML Ubuntu sessions running under my Debian host system.

Playing in the Sandbox
The availability of a Linux kernel running in user space allows you to develop programs in complete safety, as well as hack and debug the kernel itself without any risk. In the past month, the vmsplice local root exploit alarmed the Linux community and they fixed it in kernel version Let's test this exploit with the code that was available in the community (see Listing 2.) What better place to try it than on a UML machine?

For this purpose, download and install a vulnerable kernel version (e.g., and compile a UML machine following the steps above with the following two additional settings for debugging purposes:

Kernel hacking ---> [*] Compile the kernel with debug info [*] Compile the kernel with frame pointers

Then boot it, access it as a normal user, compile, and run the code:

uml1-user@uml1:~$ gcc -g -o test proof-of-concept.c uml1-user@uml1:~$ ./test

UML will freeze, harmlessly with regard to your host system:

----------------------------------- Linux vmsplice Local Root Exploit By qaaz ----------------------------------- [+] mmap: 0x0 .. 0x1000 [+] page: 0x0 [+] page: 0x20 [+] mmap: 0x4000 .. 0x5000 [+] page: 0x4000 [+] page: 0x4020 [+] mmap: 0x1000 .. 0x2000 [+] page: 0x1000 [+] mmap: 0x40173000 .. 0x401a5000

You also can debug it from the host with gdb if you know the umid of the crashed UML. Find the pid of the UML in the filedirectory .uml/uml1-umid/pid and then run:

host-user@host:~$ gdb linux- pid_number (gdb) where #0 0xffffe410 in __kernel_vsyscall () #1 0xb7dcb2c9 in sigprocmask () from /lib/i686/cmov/libc.so.6 #2 0x080648c0 in change_sig (signal=11, on=1) at arch/um/os-linux/signal.c:186 #3 0x08066d1a in sig_handler_common_skas (sig=11, sc_ptr=0x81f4d24) at arch/um/os-Linux/skas/trap.c:38 #4 0x08064620 in sig_handler (sig=11, sc=0x81f4d24) at arch/um/os-Linux/signal.c:49 #5 0x0806478f in handle_signal (sig=136268828, sc=0x81f4d24) at arch/um/os-Linux/signal.c:136 #6 0x08065b07 in hard_handler (sig=11) at arch/um/os-Linux/sys-i386/signal.c:12 #7 <signal handler called> #8 0x080c01a8 in splice_to_pipe (pipe=0x27488600, spd=0x27e02ec8) at fs/splice.c:257 #9 0x080c14d4 in vmsplice_to_pipe (file=0x8f95360, iov=0x0, nr_segs=4096, flags=<value optimized out>) at fs/splice.c:1462 #10 0x00001000 in ?? ()

During and after the boot of UML, you might have noticed a lot of annoying messages coming from the console similar to this:

line_ioctl: tty0: unknown ioctl: 0x541e

Digging into the kernel source code in file arch/um/drivers/line.c, I found the piece of code that originates this kind of message:

if (i == ARRAY_SIZE(tty_ioctls)) { printk(KERN_ERR "%s: %s: unknown ioctl: 0x%x\n", __FUNCTION__, tty->name, cmd); }

It doesn't seem to be important, so comment out the code and see what happens.

This operation allowed me to investigate a piece of kernel code without the fear of crashing the host system—a demonstration of the benefit of having a Linux kernel running in user space.

Roberto Giorgetti is an IT manager and technical writer based in Italy. He is mainly interested in open source exploitation in business and industrial areas. Roberto holds a degree in Nuclear Engineering.
Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date