I’ve always wanted to try it … and now I’ve actually started to work on it:
I certainly could use some help, though! Splicing a complex security framework into a running system isn’t exactly shell scripting
I will post updates as I reach certain milestones.
I am mentoring the develop a kpatch delivery mechanism for the CentOS Google Summer of Code (GSoC) project. Per my recent “office hours” email to the CentOS GSoC, I’ll be online from 10pm to 11pm US Mountain time on weekdays in the #centos-gsoc and #centos-devel chat rooms on irc.freenode.net
I’ve decided that I’ll keep these hours even after the project ends. If anyone wants to get in touch with me outside of email, just drop me a chat during those hours. My username is cormander.
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 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.
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 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.
…when your screen name was your online identity. There was no expectation that you give your real name, though you could if you wanted to. This nostalgic feeling rushed into me as the response to my centos wiki edit permissions request came back stating that I needed my name as the username, not my online alias.
As if my online screen name identifies me any less than my actual name?