Tales from the Gryphon/ archives/ 2004/

Tales from the Gryphon

Archives for 2004/10

Manoj's hackergotchi
Add a new post titled:
Monday 02 January
2006
Link: A test suite for Devotee

Posted early Monday morning, January 2nd, 2006

A test suite for Devotee

I have been thinking about informally going through NM (perhaps with an AM who wants some practice) for a while now (and have been procrastinating about it like many real-life DD candidates :-). I have planned on using Devotee (DEbian VOTe EnginE) as the package I use to get through NM. So, pursuant to packaging Devotee, I am trying to add a test suite to the package. In order to run a decent test, I need a set of ballots -- signed ballots -- at least some of which are signed by keys in the Debian key-ring. I have put together a dummy vote on my own box, with the topic being voted upon being What is your favorite color of the rainbow?. Here is the ballot. Please note that any emailed ballot is likely to end up in a GPL'd package, open for all the world to see, so please consider that before voting. Oh, and the interesting stats are here.

So, why am I embarking on this strange course of going through NM even though I am already a Debian developer? Well, I've been in the project since well before there was a new maintainer process. I just felt like contributing, and, one day, just emailed the devel list, and I was in. No checks, no key signatures required (not even a key was needed, unless my memory is failing me). I have a theoretical knowledge of what NM entails, but no real gut feeling for what the various stages feel like, nor how hard they are to get through.

I have always wanted to contribute to the NM effort, but I have never felt comfortable with trying to change -- or even participate as an account manager -- with so little understanding of what an applicant is going through.

One of the concerns with me trying to go through NM is that I would be taking valuable resources away from the list of real candidates who are stuck in the queue, and mostly for my own selfish reasons. However, I have been assured by current AM's that adding another candidate to their list would not significantly alter their workload, so I have decided to proceed.

So please, do help develop a test suite for Devotee by voting for your favorite color. Pretty soon I shall be looking for a sponsor for Devotee, and an advocate.

Manoj

Monday 02 January
2006
Link: Using SELinux UMLs: A recipe

Posted early Monday morning, January 2nd, 2006

Using SELinux UMLs: A recipe

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).

Manoj


Webmaster <webmaster@golden-gryphon.com>
Last commit: terribly early Sunday morning, June 8th, 2014
Last edited terribly early Sunday morning, June 8th, 2014