I have blogged before about
the trials and travails of trying to set up user-mode-linux, but
the power of perseverance has changed things a bit. What has also
helped is that both
SELinux and UML are
getting incorporated in the mainline kernel, and I managed to
research a load of places to look for more recent patches and
fixes. To cut a long story short, I have created a recipe (see here for an
older version) to create your very own UML + SELinux setup,
complete with a root_fs. This is a recipe, rather than a
HOWTO, since it provides a step by step recipe that should work,
and does not pretend to be an answer in the general case — though I
hope it would still be a guide.
The reasons I embarked on this were manifold: firstly, I have
given up on strict policy for my laptop for the time being, too
many things have not yet been tuned for desktop machines. Maybe the
targeted policy would work out better, but that has yet to be
packaged (more on that later). Next, the packaged user-mode-linux
died on me, and refused to work on 2.6.x hosts. Furthermore, I
could no longer even build root file systems on my 2.6.x boxes — so
I decided to root around in mailing lists, find out the patches
floating around to make the whole shebang work, and to provide the
glue between the uml crowd and the SELinux crowd. This way, I can
continue my SELinux experiments in sane, controlled, UML
environments, play with policies and networks, all without
compromising my real machine.
One can set up a whole network of UML machines on a single host,
allowing for more complex attack vectors to be studied, as well as
prototyping MAC policies to defend against the simulated attacks.
The kernel can be debugged like any other process, profiled, run
under gdb; one may set up break points in system calls and do
analysis of kernel and security subsystems that would be impossible
on a real hosted system.
I am also thinking of running services (like bind, postfix,
sendmail) in a secure UML as opposed to semi-secure chroot jails
(which do not come close to the isolation provided by a virtual
machine running SELinux). Since the user-mode kernel is not running
directly on the hardware, it has no access to it unless you provide
it. This is important, since while mandatory access control
prevents a large number of exploits, it can’t protect against
kernel exploits (buffer overruns, etc).
One can run the uml with the original root file system
read-only, and an additional (initially empty) file that that gets
populated when things are written to disk (Copy-on-write ). This OW
file can be discarded, or merged with a copy of the original root
file system, as desired. So it is very easy to see any changes that
are taking place on the file system of the uml.
Using SKAS has several advantages: The UML kernel runs in an
entirely different host address space from its processes. This
solves the security and honeypot fingerprinting problems by making
the UML kernel totally inaccessible to UML processes. Their address
spaces are identical to what they would be on the host. This also
provides a noticable speedup by eliminating the signal delivery
that used to happen for every UML system call.
Once I had UML more or less working, along with a SELinux
enabled root_fs, I decided to more or less automate the process,
and document it, hence the web page you see above. At some point I
shall enhance it to provide an out of the box honeypot variant —
complete with tty logging (well, once that is supported again by
UML).
Since the logging is performed on the host system, the logging
would be invisible to any attacker. Just sniffing the network
doesn’t help since that traffic is encrypted. So, you need to
capture keystrokes by running something on the honeypot. This is
problematic since you have to assume that it has been thoroughly
compromised, so the logging mechanism may also have been
compromised.
UML solves this problem with a patch to the tty driver which
logs all traffic through tty devices out to the host. In contrast
to the physical honeypot logging mechanisms, this is undetectable
and unsubvertable. It causes no network traffic or anything else
which can be detected from within the honeypot. It’s also in the
UML kernel, which means it can’t be defeated by anything the
intruder might do.
That was also the impetus I needed to incorporate patches that
people had worked on to enable kernel-package
uml and xen images (incidentally, I need feedback about this new
functionality from xen and uml users).
