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