For the past two months, I’ve been working on this project:
This kernel modules implements Trusted Path Execution (TPE), a security feature that anyone who is looking for an easy, single solution that will prevent all kinds of exploits. The short of it is, a user can’t execute code that they can write to. Meaning, if they download, compile, or otherwise write a file on the system with executable code, they can not execute it. This single handedly closes the door on a whole range of system exploits.
After a few years of leeching answers from StackOverflow (arriving there from various google searches), I’ve finally decided to take the plunge and create an account there. Turns out, I really like the interface. It’s complete with voting systems, commenting, and achievement porn. Yes, I actually said it, achievement porn. Something not real that give you a high, and a craving for more.
You earn “badges” for doing various things, and I have quite a few already. Not because I wanted to get them, hell, I don’t even know what they all are. But they’re there, and I’m getting them. Woo hoo!
Following up on my previous post on the matter, here are some details on what the 4 grsec features I ported to a centos 5 kernel looks like.
First off, since I’m patching syscalls in heavy use, first try to insert might look like this:
[root@localhost ~]# ksplice-apply ksplice-grsec.tar.gz
Error applying Ksplice update grsec:
Ksplice has aborted the upgrade because it appears that the code that you are
trying to patch is continuously in use by the system. More specifically,
Ksplice has been unable to find a moment when one or more of the to-be-patched
functions is not on a thread's kernel stack.
Process klogd(pid 2060) is using the following symbols changed by update grsec:
So I finally got the official response from ksplice about my previous post on the topic:
“Ksplice does not provide support for the raw Ksplice utilities.”
This also means that they won’t be updating their git repository either. It is obvious to me that they have updated their code internally, but have no intention of releasing it to anyone else.
So for the time being, we are all SOL on the matter. Maybe they will change their mind in the future, but I doubt it. Can’t blame a business for wanting to keep things close to their chest.
As a rule, I try to keep my personal life off my blog. This post is evidence of my total failure to do that. While I consider the writing of my book part of my professional career, the reasons for this post are personal.
Today the StarCraft II “Heart of the Swarm” preview hit the web. I instantly jumped all over it and read every detail I could. If it isn’t already apparent, I’m nuts about that game. I play it almost daily, and am in the Diamond league (top 20 percentile of players).
Today I noticed that on my new virtual server, the time was in MSD (Moscow Daylight Time). I then tried to enter the system-config-date command. It was not available, which I thought was odd. I’ve always used that to change the timezone, and never bothered to look up the configuration file that it edits.
So I did a yum install. To my amazement, this is what I saw:
There are problems assosiated with upgrading a RHEL/CentOS 5 system so that it can properly build a recent linux kernel, due to it requiring a somewhat current build chain (binutils, gcc, etc). Rather than continue to back-port these RPM packages from fedora to my CentOS 5 machines, which is what I’ve done in the past, I have opted to just upgrade and use a new operating system.
As a proof of concept, I pulled 4 features from the grsecurity patch and back-ported them to the CentOS 5.6 kernel. I built the resulting patch with ksplice and inserted the resulting tarball into the kernel. The features work brilliantly. It’s been running on my server the past few days with no issues so far.
The features I did it with are: Trusted Path Execution (TPE), dmesg restrictions, TCP/UDP blackhole, and disabled privileged IO.
In light of me working on tpe-lkm, I’ve downloaded the source for the RHEL6 kernel. I noticed right away that there were no patches, that the entire kernel was already pre-patched. I did some googling, and found some others chattering about this, like this one:
A side-project I’ve been working on for enhanced security in distribution kernels. Trusted Path Execution (TPE) is a feature that basically denies users the ability to execute programs that are not owned by the root user, or that they can write to. This prevents all kinds of exploits that would have otherwise rooted your system.
You can find the source code for this work-in-progress here: