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.