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.
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.
Wish me luck.
I previously talked about wrapping glibc functions and the possibility of doing a mandatory control system out of it. Well, the short version is, it doesn’t work right on multi-arch systems, which is pretty much a deal breaker for me. So unless you want this error spat out on every single command that is ran:
ERROR: ld.so: object '/usr/lib/glguard.so' from /etc/ld.so.preload
cannot be preloaded: ignored.
Then you’re SOL. Oh well, it was worth a try. On to other things!
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.
Many thanks to Panos Sakkos for the bug report!
The other day I came across an old forum post about logging exec calls to syslog without modifying code anywhere. I was intrigued; I didn’t know you could hook into glibc function calls like this. I wonder how far can this go? Naturally, I decided to take a quick whack at it myself, and I ended up coding a very basic implementation of Trusted Path Execution with it. I got good (although puzzling) results:
Every spring my yard is visited by wild ducks:
This morning, my front yard was visited by a dead duck. It’s likely that is was the same one in the above picture, as it was taken just last week. What an appropriate start to April Fool’s Day – having to grab the shovel and find a dumpster. We were all sad.
Oh and, I didn’t take a picture of it dead, that would be morbid and just plain gross.
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.
…you’ve played 6000 games of minesweeper, and won the vast majority of them: