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.
Continue reading Added “ps” extras feature to tpe-lkm
I have committed a fix to the tpe-lkm project that fixes a DoS condition I previously noted.
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.
Continue reading tpe-lkm DoS condition fixed
I’ve discovered my first denial-of-service bug in the linux kernel. I’m a bit teary eyed, not because the bug was in my own code, but it marks the first bug I’ve found in linux kernel code.
Not worth of a CVE or anything, because I still haven’t declared the code stable, and I don’t imagine many people use this thing just yet. But in the interest of full disclosure, here is information about the bug.
Continue reading Recursive function causes DoS in tpe-lkm
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.
Continue reading Trusted Path Execution – an unorthodox kernel module
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:
Continue reading ksplice-grsec for centos 5
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.
Continue reading Applying (part of) the grsecurity patch with Ksplice
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:
Continue reading Trusted Path Execution (TPE) Linux Kernel Module