Subject: vserver + grsec implementation
From: "Rik Bobbaers" <rik@enzoverder.be>
Date: Mon, 22 Nov 2010 12:30:42 +0100 (CET)

Some info on how to get to the vserver+grsec patches.
might be of interest to others too...

Rik Bobbaers

-- http://harry.enzoverder.be
linux/unix/system/network/security/hardware admin
infrastructure architect


---------------------------- Original Message ----------------------------
Subject: Re: [vserver] Vserver + grsec thoughts
From:    "Rik Bobbaers" <rik@enzoverder.be>
Date:    Fri, November 12, 2010 09:55
To:      "Ed W" <lists@wildgooses.com>
--------------------------------------------------------------------------

Hey Ed,

For the patches, i just thought: just do the fucking thing! It's always
easy to complain about "no time", but there is always time :)
So I created the patch anyway ;)

I'll try to explain a bit how i handle this project (now, because i've
been doing this for... a long time so i don't know how it all started and
why i made certain decisions.

Let's start on how the work starts:
First: check which version of grsec/linux-vserver is the latest.
I download the (latest) kernel from a kernel.org mirror (faster ;))
then download the patches for grsecurity
then for linux-vserver
unpack the kernel to the <kernel>-g-v directory
apply grsec patch (should be smooooooooth ;))
then apply the linux-vserver patch (will be HELL)
==> redirect the output of this patch to a file... we'll need it later on.

If you have ever done this, you'll see some rejects, some offsets with a
fuzz and some offsets.
Most of these offsets are pretty OK and are just because grsecurity
patches cause it.
The offsets with a fuzz are mostly OK as well, it's just grsecurity that
does changes in the same area.
the rejects are not done of course, those have to be looked at by hand,
see what exactly it is they do and apply manually.

After this, you end up with a very buggy kernel still. Why? that's where
the "experience" comes in. During the last X years, i've encountered bugs
and so on, that i had to fix manually afterwards. Most noticeable is the
refcount bug.
Anyway... after correcting all this you end up with a proper kernel
(normally). Just to be sure, it's always wise (certainly with major
version changes) to recheck the rejects/fuzz/offset patches. Also grep the
linux-vserver code for new uses of the atomic values that
change/changed/got added.

After that, diff the new and old kernel, test and you've got yourself a
patch!

Then , how i created the "mypatch" things? this is what i use to not do
all the work all the time again. I take a vanilla kernel tree with
-g-v-orig at the end, patch grsec, patch vserver remove all .orig and .rej
files and diff that with my <kerneltree>-g-v tree. This gives all the
changes i did on all the files to make both "just play along" ;)

Now, why do you have to look out for even the "offset" values? In mypatch
files, you'll see linux-2.6.36-g-v/kernel/ptrace.c patch. If you look in
the patch output, you'll see, all of a sudden, a "leap" in the patch. This
happens because grsecurity patches the "SYSCALL_DEFINE4" call and
linux-vserver too. The problem is, since grsecurity already patches it,
patch goes looking for the same code in the rest of the patch. And it
finds it... in "compat_sys_ptrace" so you get a patch with a "bigger"
offset... which is wrong of course. So we have to fix that.

the "capable_nolog" function does not exist in vanilla kernel. It's added
by grsecurity. But linux-vserver changes the behaviour of the "capable"
function. Since this is needed for linux-vserver (why, ask bertl ;)), we
also need to modify the capable_nolog function, created by grsec
All the Kconfig changes are just to make some options (that break
linux-vserver) of grsec unavailable when you use linux-vserver.

and so on...

In your next mail, you put some questions, well.. mostly it's related to
this kind of problem. I'll go over your questions on those and answer
inline.

So you see... it's not particularly difficult, but you need to keep your
head to it and make sure you don't forget stuff or look over stuff. Of
course, i'm not perfect either, I too make mistakes, but ... i try to keep
it to a minimum ;)

Rik Bobbaers

-- http://harry.enzoverder.be
linux/unix/system/network/security/hardware admin
infrastructure architect

> Hi Rik (offlist, but reply onlist if you like)
>
> Thanks tremendously for this.  Couple of questions:
>
> - Given that I might end up at least assisting in this maintenance,
> could you comment on how your actual process to maintain this ongoing
> patch please?  eg do you look at grsec diffs and maintain your "combo
> diff" as a separate process?  Or perhaps you just manually merge each
> time and get used to the extra steps needed?
>
> - I'm in Grand Canarias at the moment on a dodgy wifi connection, so not
> easy to properly evaluate code.  However, do you think you might
> consider creating a pax patch plus combo diff please?  This is more for
> me so that I can learn which bits you are changing?
>
> - I have now setup a nightly scrape of the pax site - is this something
> you do/use in order to help keep up on the combo merge?
>
> - Ever tried to leverage git/bzr/quilt/etc to try and automate this
> merging?
>
>
> Thanks for maintaining this Rik - thoughts on future direction very
> welcome?  Please feel free to reply to the list also if you think useful?
>
> Cheers
>
> Ed W