It recently came to my attention that RHEL/CentOS 7 kernels started support for the ftrace system as of version 7.2. This is an in-kernel system to instrument kernel functions in a safe and clean way.
Since using ftrace basically meant a rewrite of most of the tpe-lkm code, and dropping of support of older kernels, this new release has bumped the major version from 1 to 2.
New features in this release include:
* guaranteed safety of kernel function hooking
* better long-term support from future kernels
* added harden_ptrace to tpe.extras
* added hide_uname to tpe.extras
* ability to soften certain TPE checks with filesystem attributes
* default mmap whitelist to allow Gnome Desktop to boot properly
* better logging options
As always, you can download it from the tpe-lkm github project page, or install via yum from elrepo.org.
Additionally, the availability for this in-tree method of hooking kernel functions has wider implications for implementing security features in distribution kernels. For more information, read the following whitepaper I drafted:
Distribution Kernel Security Hardening.
A few weeks ago I go an email that tpe-lkm didn’t build on EL7. To be honest, I didn’t even know that EL7 had been released, I’ve been so disconnected from things outside of family and work the past few years.
Anyway, I got back to work and now everything is nice and ready for release. You can download it from the tpe-lkm github project page. It has a few new features as well.
Just under two weeks ago I gave a talk at LinuxCon 2012 in San Diego. It was a great experience, and I hope to do it again in the future. Too bad I could only stay for one day, as I could only break away from work for a short amount of time. Here is a link to my time slot.
The title of the presentation was “Distribution Kernel Hardening”. It talked about kprobes, ksplice, and my tpe-lkm kernel module.
I have uploaded my presentation slides and my speaker notes if you would like to have a look, since my session wasn’t recorded. Enjoy!
I recently sent an abstract to LinuxCon / Kernel Security Summit, and the other day I heard back from one of the panel members. As I mentioned my thoughts on implementing AppArmor on CentOS/RHEL via LKM, he replied about a project that he threw together called AKARI. It’s a fork of TOMOYO, and inserts into the linux kernel in a very similar way to how I was planning on doing AppArmor, and have been recently been toying with in tpe-lkm.
All I can say is, that’s a whole lot of code I won’t have to figure out He’s already solved some of the problems I’ve been facing. I haven’t used TOMOYO before so I haven’t given this module a test yet beyond inserting it into one of my test systems, but so far it appears to work as advertised. As my time permits I’ll throw up a git repo called kmod-apparmor, which contains some of this code, and continue my work on it.
I previously talked about hijacking linux kernel pointers as an alternative method of implementing security features. At that point I had only tested it on my Ubuntu machine (linux-3.2.0) but I’ve since tested it on EL6 (2.6.32) and EL5 (2.6.18). While there weren’t any problems on EL6, EL5 had some problems and today I committed a bunch of fixes to address them. It looks like it’s stable now.
I’d like to have some other people test it though, and I’d like to expand on the regression testing some more. Once I’m confident that this other way to implement TPE won’t cause any issues, I’ll merge it into the main branch and cut a 2.0 release.
This week I have been toying around with the idea of hijacking the linux kernel pointers, instead of overwriting functions, to implement security features. Well, tonight I pushed a big commit to tpe-lkm that implements all the features entirely with this new method. It’s currently in a “dev” branch, as it’s not been fully tested. So far, however, the method seems promising.
I’ve started to version my tpe-lkm project as it’s stable now, and today I released version 1.0.3. You can download the files from sourceforge.net or from github. This release contains some code cleanup, and a few bug fixes.
As for the meaning of the version number goes, the 3rd # is for bugfixes, a 2nd # is if new features are added, and if I ever increment the first #, it’ll be a major rewrite of the code. I may do that some day.
Anyway, happy TPE’ing!
Today I installed Ubuntu 12.04 LTS on my laptop to give the Linux Desktop another go. So far I’m very impressed with it, they’ve done a very good job.
Anyway, I spent some time this evening and got tpe-lkm ported to the 3.x linux kernel. The code is now messier with more if/else kernel version statements, but that’s the way it is. It’ll be interesting to see what applications don’t work on a desktop with TPE enabled – so far I haven’t noticed anything broken.
This evening I pushed a commit for tpe-lkm that checks if the symbol is already hijacked. If it is, it doesn’t bother to hijack it, and spits out an error. This check was a side-effect of my thinking of implementation details for a kernel integrity check module. The basic idea; continually check certain “vital” areas of kernel memory for suspicious activity, and take predefined action upon discovery. Kind of an anti-rootkit kernel module. As I get some more time in the coming weeks, and after some google searches on the subject, I’ll give more details, and hopefully some code to go with it.
So I’ve decided to see if I can get a speaking slot at LinuxCon in San Diego this year. Here is the abstract that I sent them. Wish me luck!
I will talk about hooking into pre-compiled distribution linux kernels to add security hardening. This allows for certain security frameworks to be used on kernels that are either 1) too old, 2) don’t have certain config flags set, or 3) don’t use non-mainline security patches. The primary example I’ll be discussing is my implementation of “Trusted Path Execution” as a linux kernel module, the source code of which is here: https://github.com/cormander/tpe-lkm . I may also demo installing AppArmor on a RHEL6 system via a kernel module, if I get the module stable before July.
The audience would be system administrators and developers who manage systems that they can not change the kernel on, or don’t want to manage custom kernel builds. This is important because it allows access to kernel hardening to a lot of people who have their hands tied either by policy or lack of experience.