User Tools

Site Tools


ironpenguin:start

IronPenguin is a set of modifications to recent Linux kernels aimed at implementing both stronger and more versatile security functionality in Linux systems.

IronPenguin is a quick hack that grew considerably in scope as time went on and it became clear just how much could be gained with a few well-considered small changes in the kernel.

The objective of IronPenguin is to allow for improved and more flexible security in a Linux system without resorting to SELinux (DLL Hell for the 21st century!)

This includes general purpose features and extremely light weight server virtualization, both for fulll virtual servers with independant administration and for running services inside hardened chroot jails.

The two are closely related primarily because this approach to virtualization requires a thorough audit of kernel security and a few modifications, both of which hilite existing weaknesses and suggest small changes that lead to large improvements.

The Linux Vserver project is related in the virtualization goal, but appears to have a very different implementation philosophy.

A primary design goal of IronPenguin is to locate the 'inflection points' in the kernel to make the actual modifications as small as possible while still achieving the objective. This has proven to be surprisingly effective. For example, hardening the pty driver to prevent jailed processes from snooping user terminals adds only 11 lines of code to the kernel, 6 of which are #ifdef and #endif

Perpaps even more startling, adding file capabilities (so a program which would otherwise be setuid-root can instead grant only the capabilities actually needed) adds only 19 actual lines of code to the kernel!

Another important goal is to steer clear of 'hot' paths in the code. The less the extra code is actually executed, the less performance impact it can possibly have. For example, the chroot and bind hardening code affects the file open path but stays completly out of the file I/O path. The best performance will be obtained by making sure a 'dangerous' condition cannot happen in the first place rather than checking for it where it can happen.

Thus, for hardening chroot, the patch touches fchdir and the branch of do_lookup used by the new *at file syscalls but doesn't touch do_lookup in the case of CWD reletive paths or absolute paths. The much less commonly called fchdir function makes sure a CWD reletive path is always safe in the first place (that and having sys_chroot call chdir as well).

By contrast, the vserver project implements a much more complex and invasive set of modifications to the capaable function (used to decide if a needed capability is present), the addition of a special chroot marker, and an extended concept of user domains to accomplish about the same effect.

These two objectives can be summed up as “less is more”.

In addition to making analysis of correctness and debugging MUCH less effort, it also bodes well for future maintainability of the patch set. The smaller the patch, the smaller the odds of the vanilla kernel changing something out from under it. As it turns out, much of the patchset is in functions that haven't changed significantly since at least version 2.6.12.

This just in

The good news is that the Linux kernel as of 2.6.24-rc2 has filesystem based capabilities. The bad news is that this means IronPenguin needs to make a few adjustments to avoid becoming a significant fork in Linux with very different security models.

The differences are outlined in capabilities.

IronPenguin is composed of several related but logically seperable modifications to the kernel:

capabilities (capability notes)
capceiling
jail_syscall
open questions
prerequisits
admin_tools

ironpenguin/start.txt · Last modified: 2010/04/15 21:18 (external edit)