Tales from the Gryphon/ categories/ software/

Tales from the Gryphon

Blog postings about SELinux and security software

Manoj's hackergotchi
RSS Atom Add a new post titled:
Monday 02 January
2006
Link: Securing Debian: SELinux integration into Etch

Posted early Monday morning, January 2nd, 2006

License: GPL

Securing Debian: SELinux integration into Etch

Well, yes, that sounds somewhat pompous. But I do think this is a worthwhile release goal; from where I stand I think that hard-hat security is a critical option for any OS to remain viable in the current security conscious environment, and Debian, after a period of being well ahead of the curve (thanks to Russell Coker, Colin Walters, Brian May, and others), has fallen well behind entities like Red Hat and Gentoo when it comes to providing a hardened, secure platform.

So, along with a few other people (Greg T. Norris, Lorenzo Garcia-Heirro), I have started a mini project to bring Debian's SELinux patched packages back in sync with the latest upstream and the latest SELinux patches, and to make it easier for Debian developers to access SELinux patches. The only package that is ready to go is coreutils, and that is thanks to Greg.

I've just come back from the Se-Linux symposium, followed by the Central Pennsylvania LUG Security conference, which was a lot of fun. I also managed to get myself talked into upgrading to the X Org server, which is to be 3expected after spending two days sitting Next to Jim Gettys at a conference watching the neat gizmos.

And, if I get through this key signing process, I may get my key connectivity ranking up again (also thanks to getting it signed by Russell Coker). Of course, due to my weird key signing protocol this is more tedious than the norm, but hey, that's what you get for trying to add value to your signature.

Manoj

Monday 02 January
2006
Link: The SELinux UML page updated

Posted early Monday morning, January 2nd, 2006

License: GPL

The SELinux UML page updated

I finally got around to updating the SELinux UML recipe page to the latest 2.6.11.2 kernel. Of course, the new linux UML kernel expects a newer version of SELinux policy (19) than I had in my root_fs, so I'll have to rebuild a new root file system. I wanted to get the newest version of the SELinux tools into Sid, but I seem to be coming down with a flu like thing. Since I would like to see Etch be SELinux capable, it is important that the barrier of entry be low for people wanting to play around with it.

Manoj

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

Posted early Monday morning, January 2nd, 2006

License: GPL

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: in the wee hours of Friday night, May 31st, 2014
Last edited in the wee hours of Friday night, May 31st, 2014