Not long after I gave up on getting a MAC system in userspace, I had the thought that LSM functions in the kernel are all visible as kernel symbols, and already implemented mandatory access control systems use just those kernel functions to do their work. I already have a working module that hooks into kernel functions (tpe-lkm), so it isn’t such a far leap to think that using the same method, one could implement a kernel-based MAC system with some creative function hijacking.
So, I’m currently working on porting the AppArmor LSM to my tpe-lkm style kernel hijack code so that it can be used on a RHEL/CentOS kernel. So far so good, I have all the basics done, but in order to get things to work right I just need to figure out how to handle something. The kernel has a task->cred->security area on every process on the system, and on module load, I need to figure out how to safely convert that from the currently loaded LSM into an apparmor profile. Once I have that figured out and a basic policy working, I’ll publish the source to github.
Early this morning I got a bug report from someone that, when the full path to a file is sufficiently long enough, a denied execution of it will throw a NULL pointer exception in the kernel. This evening I researched the issue and coded in a fix. Basically, the error reporting tried to print out a NULL pointer under those conditions. How embarrassing for me to not notice this.
If you’re using the tpe-lkm module, you’ll want to update it. I’ve also bumped the version number.
I used to maintain a grsecurity kernel rpm repository, but haven’t kept it online due to lack of proper build infrastructure. The servers, the code, the effort in keeping everything working order – I admire what the CentOS guys have put together, and look forward to the possibility of them releasing their reimzul for everyone to use. Maybe one day I’ll do the repository thing again.
Anyway, I get asked occasionally about the rpms, if I still make them, and how they were made. So, in the absence of me pre-building the RPM files, here is my kernel-grsec rpm spec file that I used to build them. Hope you find it useful.
About a year ago, I posted about me coding a TPE module for distribution kernels. In that time I’ve added some features, fixed some bugs, and deployed it to all of my non-grsecurity systems. With the last known outstanding bug (that I know about) being fixed a little over two weeks ago (and tested) I’m excited to say that, you guessed it, tpe-lkm is ready for wider deployment.
It’s about time I post a detailed explanation about how my tpe-lkm module is able to enforce its security policy. This post is very technical, readers beware. Note that this writeup is based on the code as it was the latest commit, which was of this writing, was the one on Dec 10th, 2011. I’ll keep all the links relative to that date.
This evening I implemented the optional hardcoded_path feature for tpe-lkm. It’s a way to be very strict on what on the system can be executed. When set, anything outside of the given path can’t be executed, regardless of permissions or ownership. This includes shared libraries, so use this feature with caution. Read the entry in the FAQ about it.
Tonight I implemented a “lock” sysctl feature for tpe-lkm. When enabled, the sysctl entries for the tpe module can’t be changed. It’s only real useful if also combined with the modules_disabled option.
Since I already had my hands in the tpe-lkm code yesterday, I decided to spend my lunch break coding a feature I’ve been meaning to add in for a while now.
I added a new ps extras feature. Since it doesn’t have to do with the “trusted path”, I added it to the “extras” in the configuration. It’s similar to grsecurity’s “Proc restrictions” where “the permissions of the /proc filesystem will be altered to enhance system security and privacy”. Basically, non-root users won’t be able to view the processes they don’t own.
It also introduces a new sysctl entry, log_max, as to prevent logs from getting filled up horizontally. I set the default to 50, seemed high enough without giving an attacker too much leverage on spewing junk into the log file should they get the chance, yet low enough to catch the full process tree of you basic exploit attempt.