Site Home Page
The UML Wiki
UML Community Site
The UML roadmap
What it's good for
Case Studies
Kernel Capabilities
Downloading it
Running it
Skas Mode
Incremental Patches
Test Suite
Host memory use
Building filesystems
User Contributions
Related Links
The HOWTO (html)
The HOWTO (text)
Host file access
Device inputs
Sharing filesystems
Creating filesystems
Resizing filesystems
Virtual Networking
Management Console
Kernel Debugging
UML Honeypots
gprof and gcov
Running X
Diagnosing problems
Installing Slackware
Porting UML
IO memory emulation
UML on 2G/2G hosts
Adding a UML system call
Running nested UMLs
How you can help
Kernel projects
A virtual network
An X session
A login session
A debugging session
Slackware installation
Kernel switches
Slackware README
ALS 2000 paper (html)
ALS 2000 paper (TeX)
ALS 2000 slides
LCA 2001 slides
OLS 2001 paper (html)
OLS 2001 paper (TeX)
ALS 2001 paper (html)
ALS 2001 paper (TeX)
UML security (html)
LCA 2002 (html)
WVU 2002 (html)
Security Roundtable (html)
OLS 2002 slides
LWE 2005 slides
Fun and Games
Kernel Hangman
Disaster of the Month

The Honeypot procfs

hppfs reads a proc hierarchy in the current working directory on the host of the UML. When a UML process accesses a /proc entry, hppfs consults the corresponding entry in this hierarchy to decide what to do. This entry is a directory which contains a file which describes what to do with that entry. The possibilities are as follows:
  • No entry on the host - hppfs passes the operation on to the UML /proc - effectively this means that entry is unmodified. Most /proc entries contain no information about whether the machine is a UML, so these can be left alone.
  • The host entry is a normal file or symlink - the contents of this file (or target of the link) will replace the UML /proc entry. This is appropriate for /proc entries, such as /proc/cmdline, which can be replaced by the corresponding /proc entry on the host. It is also appropriate for entries which must be changed, but which are static. In this case, you'd drop the static file into the host proc hierarchy for that UML.
  • The host entry is a directory and contains
    • "remove" (a normal file) - this causes the entry to disappear from the UML /proc. This can be used to remove things which don't exist on physical machines, such as /proc/exitcode and /proc/mconsole.
    • "r" (a unix socket) - this causes the entry to be generated on demand by the process attached to the socket. This is useful for entries which must be dynamically generated, but can be generated from scratch on the host.
    • "rw" (a unix socket) - this is similar to "r", except that the current UML /proc contents of that entry are written to the socket before the new contents are read. This allows the host process to filter the UML /proc data. This is useful when data must be removed from a UML /proc entry.
The files inside /proc/pid need slightly special handling because you can't know on the host what pids are going to be present inside UML. UML looks in the pid subdirectory of the host's shadow proc for all modifications of UML /proc/pid entries.

The uml_utilities tarball (under honeypot/) contains a few things to simplify the disguising of a UML's /proc:

  • - A perl module which acts as a server for any dynamic proc entries that need to be generated.
  • - A library which contains a set of utilities for constructing a fake proc environment.
  • - A sample driver for and which overrides a number of UML /proc entries in various ways.
Here is an example of setting up a customized UML /proc using hppfs.

First, boot a UML with hppfs enabled ('grep hppfs /proc/filesystems' to check). Login in and mount hppfs over /proc:

UML# mount none /proc -t hppfs
ls /proc and notice that it doesn't seem any different than before:
usermode:~# ls /proc
1    130  137  7        devices      interrupts  loadavg  mtd         swaps
100  131  140  8        dma          iomem       locks    net         sys
104  132  2    93       driver       ioports     meminfo  partitions  sysvipc
109  133  3    95       execdomains  irq         misc     scsi        tty
121  134  4    bus      exitcode     kcore       mm       self        uptime
126  135  5    cmdline  filesystems  kmsg        modules  slabinfo    version
129  136  6    cpuinfo  fs           ksyms       mounts   stat

Create a proc directory in the current working directory of the UML
host% mkdir proc
Now, put something into proc/cmdline
host% echo 'hi there' > proc/cmdline
and look at the UML's /proc/cmdline
usermode#~: cat /proc/cmdline 
hi there

This should give you a good idea of how to make simple modifications to the UML's /proc. A more realistic example would be to make /proc/cmdline the same as on the host. You can do this by copying the host's /proc/cmdline into proc, but a symbolic link will work, too:
host% ln -s /proc/cmdline proc/cmdline
usermode:~# cat /proc/cmdline 
auto BOOT_IMAGE=2.4.19 ro root=306 BOOT_FILE=/boot/vmlinuz

With that step, you removed one way for an intruder to fingerprint the machine as a UML. There are a bunch of others, and it would be nice to automate the creation of realistic, fake data for them as well.

Grab the uml_utilities tarball, unpack it, and cd into honeypot/. Run with the current directory of UML as an argument:

host% perl ./ ~/linux/2.4/um/ asks the hppfs module to
  • create the directory:
    my $hppfs = hppfs->new($dir);
  • initialize its contents:
    $hppfs->add("devices" => remove_line("ubd"),
    	    "uptime" => proc("uptime"),
    	    "exitcode" => "remove",
    	    "filesystems" => remove_line("hppfs"),
    	    "interrupts" => proc("interrupts"),
    	    "iomem" => proc("iomem"),
    	    "ioports" => proc("ioports"),
    	    "mounts" => remove_line("hppfs"),
    	    "pid/mounts" => remove_line("hppfs"),
    	    "version" => proc("version") );
  • call the hppfs server main loop, which will service requests from the hppfs client inside UML for dynamic proc entries:
If you look at the proc directory now, you will see a bunch of new entries:
host% ls ~/linux/2.4/um/proc/
devices   filesystems  iomem    mounts  uptime
exitcode  interrupts   ioports  pid     version

These all need some sort of manipulation.
  • Removal - /proc/exitcode is specific to UML; writing to it allows the exit code of UML on the host to be changed. This obviously can't be present in a honeypot, so the argument
    "exitcode" => "remove",
    to hppfs::add causes it to create an exitcode directory in proc on the host:
    host% ls -al ~/linux/2.4/um/proc/exitcode
    total 8
    drwxrw-rw-    2 jdike    jdike        4096 Dec 18 14:43 .
    drwxrw-rw-   11 jdike    jdike        4096 Dec 18 14:43 ..
    -rw-rw-rw-    1 jdike    jdike           0 Dec 18 14:43 remove
    The 'remove' entry tells hppfs to hide the UML /proc 'exitcode' file, and 'ls /proc' inside the UML shows that it is indeed gone.
  • Fabrication - we've already seen an example of fabricating a proc entry from scratch. Dropping a static file into proc will cause it to replace the corresponding UML /proc entry. However, lots of /proc files are dynamic, so looking at it twice and seeing exactly the same data would be a tip-off that something's wrong. If the host's /proc entry is usable, then a symbolic link from the shadow proc to /proc will be fine. This is what these arguments to hppfs::add do:
    "uptime" => proc("uptime"),
    "interrupts" => proc("interrupts"),
    "iomem" => proc("iomem"),
    "ioports" => proc("ioports"),
    "mounts" => remove_line("hppfs"),
    "pid/mounts" => remove_line("hppfs"),
    "version" => proc("version") );
  • (although the actual hppfslib implementation of proc() currently has the hppfs server execute 'cat /proc/<file>')
  • Filtering - sometimes the host's /proc or anything else we can generate on the host won't be right. Instead, we might want to take the UML /proc file contents and manipulate them somehow. An example is /proc/filesystems. In this honeypot, it contains an entry for hppfs, which can't be allowed to remain. So, this argument to hppfs::add causes that one line to be removed, leaving everything else the same:
    "filesystems" => remove_line("hppfs"),
  • Note the "pid/mounts" entry. That covers all references to any /proc/pid/mounts file inside UML.
Hosted at SourceForge Logo