Updated gradm and paxctl packages

By cormander

The other day I went ahead and uploaded some new packages for gradm and paxctl. You can download this to your /etc/yum.repos.d/ directory:

http://rpm.cormander.com/repo/grsec/rouge-beret-grsec.repo

And then:

yum install gradm paxctl

This is a new version of gradm with the “grsecurity” dependency removed. No reason why you can’t install it on a non-grsec host, the command just won’t work. The version of paxctl is the same (no updates in a while), but has an upgraded paxtest, and the “pax-linux” dependency was removed.

Sometime soon I’ll create a rouge-beret-repo RPM package that has the yum .repo files for these repositories.

RBAC policy for centos 5

By cormander

So I’ve started working on a default RBAC policy for centos 5 servers. A secure default policy that works out of the box with the operating system is a big incentive to use the grsecurity kernel, and that is what I am aiming for.

To make things easier, it turns out that you can include policies from directories. This wasn’t indicated in the documentation that I’ve read, and the syntax is odd so I wasn’t able to figure it out on my own, but it goes like this:

include </etc/grsec/somedir>

Each file in the directory (if any) is parsed as a policy. This will make things easier for a distribution to drop in policy files for its applications.

I’m going to make an RPM for centos 5 for this, as part as my rouge-beret project. I’m thinking I’ll call the package rouge-beret-rbac and it’ll have the gradm package as a dependency. I’m going to do something like this at the end of my default policy configuration:

include </etc/grsec/default>
include </etc/grsec/domains>
include </etc/grsec/users>
include </etc/grsec/groups>

That way, you don’t have to edit the policy file and worry about edits getting stomped when the package updates.

In addition, my RPM with this policy will have an init script to automatically enable the RBAC policy at the completion of boot, which will happen depending on a value set in /etc/sysconfig/grsec-rbac.

If I’m lucky I’ll get this all put together by the end of this weekend. Here is a link to the git repo I created for this:

http://git.cormander.com/?p=rouge-beret-rbac.git;a=tree;f=etc/grsec

Restricting kernel version to the root user

By cormander

I just created a new tag: “moment of insanity”. I plan to have many of these in my lifetime.

This is one of them. The other night at about 11pm I thought:

“Hey, there isn’t a reason why non-root users should know what the kernel version is, so why not restrict it?”

So I wrote the following patch and sent it over to the grsecurity project:

diff --git a/arch/x86/kernel/sys_x86_64.c b/arch/x86/kernel/sys_x86_64.c
index eedcb8a..338ceda 100644
--- a/arch/x86/kernel/sys_x86_64.c
+++ b/arch/x86/kernel/sys_x86_64.c
@@ -230,10 +230,19 @@ bottomup:
 SYSCALL_DEFINE1(uname, struct new_utsname __user *, name)
 {
        int err;
+#ifdef CONFIG_GRKERNSEC_HIDE_VERSION
+       const struct cred *cred = current_cred();
+#endif
+
        down_read(&uts_sem);
        err = copy_to_user(name, utsname(), sizeof(*name));
        up_read(&uts_sem);
        if (personality(current->personality) == PER_LINUX32)
                err |= copy_to_user(&name->machine, "i686", 5);
+#ifdef CONFIG_GRKERNSEC_HIDE_VERSION
+       if (cred->uid != 0)
+               err |= copy_to_user(&name->release, "", 1);
+#endif
+
        return err ? -EFAULT : 0;
 }
diff --git a/grsecurity/Kconfig b/grsecurity/Kconfig
index f32b4f0..417e256 100644
--- a/grsecurity/Kconfig
+++ b/grsecurity/Kconfig
@@ -345,6 +345,17 @@ config GRKERNSEC_HIDESYM
          useful protection against local kernel exploitation of overflows
          and arbitrary read/write vulnerabilities.

+config GRKERNSEC_HIDE_VERSION
+       bool "Hide kernel version"
+       help
+         If you say Y here, calls to the uname syscall as a non-root user will
+         lack the kernel's version information. Note that to completly hide
+         the version of the kernel, other areas of the system must also be
+         hardened such as read access to the /boot/ and /lib/modules/
+         directories, the /proc/version file, and read access to the system's
+         package database (if you installed the grsecurity kernel via a pre-
+         compiled package).
+
 endmenu
 menu "Role Based Access Control Options"
 depends on GRKERNSEC
diff --git a/kernel/sys.c b/kernel/sys.c
index 7837305..ee5e180 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -1154,10 +1154,17 @@ DECLARE_RWSEM(uts_sem);
 SYSCALL_DEFINE1(newuname, struct new_utsname __user *, name)
 {
        int errno = 0;
+#ifdef CONFIG_GRKERNSEC_HIDE_VERSION
+       const struct cred *cred = current_cred();
+#endif

        down_read(&uts_sem);
        if (copy_to_user(name, utsname(), sizeof *name))
                errno = -EFAULT;
+#ifdef CONFIG_GRKERNSEC_HIDE_VERSION
+       if (cred->uid != 0)
+               errno |= copy_to_user(&name->release, "", 1);
+#endif
        up_read(&uts_sem);
        return errno;
 }

I knew the patch wasn’t complete, but I wanted to see what was said.

Needless to say, it was sent back with the “useless” label all over it. Bottom line, there are other ways to determine kernel version if you have a local user (what syscalls exist or not, for example). I knew that was still possible; the idea in my (sleep-deprived) head was it’ll prevent script kiddies from knowing the kernel version.

But that doesn’t stop them from trying every vulnerability in the book anyway.

A build system to save the (my) world

By cormander

The past week I’ve been talking about Hudson, and not just here. Quite frankly I think some of my buddies are sick of me talking about it. For this (and other) reasons, I exposed the build system at this URL:

http://build.cormander.com/

I granted anonymous view access to most of it. I currently have ravencore in there, and my grsecurity stack setup in there and building successfully. Pretty soon I’ll be putting rootsh and other projects I manage in there, as well as things like python26 for CentOS, Xen 3.4 for CentOS, and any other thing that comes to mind that I have built and made use of.

And as far as this saving my world goes, it’s because it reduces the amount of effort I have to put into this stuff, which means I can do more of it.

Building the Linux Kernel in Hudson

By cormander

So I decided that since Hudson is so cool that I’d try to build something as big as the linux kernel inside it. I put the rpmbuild command for my grsecurity kernel inside and watched my builds fail until I got it just right. I ended up with a small git repo to revision control the spec file, kernel config, and a new Makefile to tie it all together.

Long story short, I now have automated builds of my spec file which is now capable of building the grsecurity kernel, the PaX kernel, and the vanilla kernel, all depending on how you call it: make grsec, make pax, and make vanilla respectively. I have each setup with both 32bit and 64bit builds, each takes two hours to do. So I just commit a change to apply a new grescurity or kernel patch, and 12 hours later I have all the RPMs fresh out of hudson and I don’t have to so much as bat an eyelash for it. Unless, of course, a build fails. If one fails, they’re all liable to fail for the same reason. So I’m gonna need some more build slaves so it doesn’t take as long in the future.

I know, I know, I’m not “using hudson how it is intended” because hudson itself is a build system, and rpmbuild is a seperate build system, so I’m having a build system calling a build system so each build has to “take it from the top”. But I don’t care about what it was designed to do, I care about what it can do.

And it rocks.

A new yum repository

By cormander

For years I’ve built my own RPMs and have shared so few of them. This hasn’t been because I didn’t want to, just that I haven’t really had the resources (hosting space, a cluster of build machines, time). Well now I’ve finally got all of the above to some extent, and with some additional organization I put in this week, I have put together the Red Beret Yum Repository (http://rpm.cormander.com/repo/).

As of right now only the “testing” repository has anything in it, and only el5 for now, but it’s a work in progress. As soon as I feel that everything in there is ready to be pushed to the production repo I will. Moving forward I’ll have el4 in there, and then possibly start to build these packages for fedora as well.

You might also notice the “grsec” directory in there. I’ll be moving my grsecurity kernel packages into there from now on, and I’ll only be keeping up with the latest kernel (no more backports for 2.6.24, sorry guys, it just takes way too much time for one guy).

Introduction to gridnix

By cormander

For those of you that have been wondering, I’ve been spending a lot of my free time working with my good friend Tim Post working on a project called gridnix.

I’ll mostly be doing userspace applications and packaging, but so far my main contribution has been the kernel for the OS. I just recently posted all my patches to the kernel to a git tree:

http://git.ravencore.com/?p=kernel/linux-2.6.24.7-gridnix.git;a=summary

The tree is lacking config and build scripts at the moment, but it’ll build just fine as-is. A little later we’ll be adding those scripts to easilly build different kernel variants such as a xen dom0 kernel or a full fledged grsecurity kernel.

Status on my new build server

By cormander

So far things are going great. I have setup several different build chroots and created a solid build system that is growing in complexity. Basically I get a source RPM and run it through my scripts and it builds out RPMs for each distribution I have setup, which currently include:

CentOS 4 and 5, Fedora 8 and 9, all for both i386 and x86_64

At the end it informs me of whether or not it succeeded on each one, and saves all the rpmbuild output in a log file. Oh – and it autoinstalls RPM build dependencies from the source RPM into each chroot if they are missing, so I don’t get silly build failures.

Tonight I ran the latest grsecurity kernel through the build tree and I’ll run it through regression testing in the morning. Since this is the first time I’ve built a i686 kernel on a x86_64 machine I’m going to do a little more testing with it to make sure it’s good to go.

So far the gradm source RPM did pretty well on all 8 builds, but paxctl needs a little work. The pax guy was right – that sub-project is bleeding from many wounds, and has compile problems when you start dealing with cross-distribution builds. I’ll have to revamp the code if I can find the time in the near future.

Hopefully the grsecurity yum repo will be full of many more packages by this weekend.

Patching the Linux kernel till the cows come home

By cormander

A little while ago I made a post about RHEL and all those patches to their kernels. Since that post I started thinking about the patches, and started to experiment with the theory of back-porting.

I currently maintain a list of Linux CVE issues and this is where my experiment begun. If you really think about it – that isn’t a whole lot. Sure these are security specific issues, but I know for a fact that this isn’t a complete list of patches to security issues. But just security fixes asside – exactly how many patches that go into later versions could also apply to old ones?

Turns out, a lot. I mean a LOT. “Holy patches batman!” as Tim might say. About 40% of the 2.6.25 tree (including all patches except ones from release candidate 1) apply cleanly to the 2.6.24.7 kernel. A few reference data structures or functions that don’t exist in 2.6.24.7, and thus cause build errors, so those are removed during the build process. No interfaces change (because the bulk of those happen in the release canidate 1’s, which have thousands of patches in themselves, any anything after that is likely to fail to apply).

Anyway, that’s about 1400 patches! Regression tests with the Linux Test Project after it’s built show no problems. I’ve been running it since I first built it – haven’t seen any issues. Who knows how many potential security problems I just fixed?

So, I updated my grsecurity RPM yum repo 2.6.24.7 branch of the grsecurity kernel with these 1400 some odd patches. When the 2.6.26 linux kernel is released as stable, I’ll have a few thousand more to review. Luckily I have the bulk of it scripted.

I’m sure there are some patches that could still apply to the older kernel with a few tweaks – but I currently don’t have to resources to review each one of the 2100 patches manually for this purpose. I’m also quite certain that this kernel won’t build on arches other then x86 – but all you’d have to do to get it to build is determine which patch caused the build error, which is very easy to do, and reverse it. When I get a 64bit machine to play with, I’ll build the kernels for x86_64. Same goes for other arches – testing will happen when I have the hardware available.

And for version control – since this is the linux kernel we’re talking about – I’m using git. Here is the git repository for this project.

Linux CVE list since 2.6.18

By cormander

Here is a table I put together containing links to the National Vulnerability Database about various Common Vulnerabilities and Exposures (CVE) issues in the 2.6 Linux kernel from 2.6.18 and above:

Linux CVE List

I had originally posted it in here, but decided to make a “page” out of it since it’s something that’ll get updated for a long time.