|  | The Honeypot procfshppfs 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:
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.
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 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.
 
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 
If you look at the proc directory now, you will see a bunch of new
entries:
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();
                   
                
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:
                  (although the actual hppfslib implementation of proc() currently has
the hppfs server execute 'cat /proc/<file>')
                    
"uptime" => proc("uptime"),
"interrupts" => proc("interrupts"),
"iomem" => proc("iomem"),
"ioports" => proc("ioports"),
"mounts" => remove_line("hppfs"),
"pid/mounts" => remove_line("hppfs"),
"version" => proc("version") );
                  
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.
 |