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 Compiling Installation Skas Mode Incremental Patches Test Suite Host memory use Building filesystems Troubles User Contributions Related Links The ToDo list Projects Diary Thanks Contacts
Tutorials 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 Configuration Installing Slackware Porting UML IO memory emulation UML on 2G/2G hosts Adding a UML system call Running nested UMLs
How you can help Overview Documentation Utilities Kernel bugs Kernel projects
Screenshots A virtual network An X session
Transcripts A login session A debugging session Slackware installation
Reference Kernel switches Slackware README
Papers 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:

- hppfs.pm - A perl module which acts as a server for any dynamic proc entries that need to be generated.
- hppfslib.pm - A library which contains a set of utilities for constructing a fake proc environment.
- honeypot.pl - A sample driver for hppfs.pm and hppfslib.pm which overrides a number of UML /proc entries in various ways.

Example

> 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 honeypot.pl with the current directory of UML as an argument:

> > `host% perl ./honeypot.pl ~/linux/2.4/um/`

> honeypot.pl 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: `

>       $hppfs->handler();

>   `
> 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