From: Liam Helmer (lhelmer_at_thevenue.org)
Date: Fri 19 Dec 2003 - 18:44:39 GMT
I've been working on getting the linux-vservers patch working with a ck
+ grsecurity patched kernel (maintained on this site:
http://www.plumlocosoft.com/kernel/). The CK patchset is a set of
patches for preemption, a new kernel scheduler (I believe a backport of
some of the stuff in 2.6, plus other extras, see the page), and some
patches for desktop boxes to make them run more smoothly. I've also put
on grsecurity, as I'm interested in a higher security box in general.
I had, just prior to this, worked on merging linux-vservers and
grsecurity successfully (although not really tested yet!), but I was
interested in incorporating the vserver patches as they're valuable to
the project I'm working on right now:
http://desktopappliances.org/index.php?module=pagemaster&PAGE_user_op=view_page&PAGE_id=6&MMN_position=8:4
So, here's where I got to so far:
Starting with kernel 2.4.23 + ck patchset + grsecurity 1.9.13 for ck
patchset, I started with the split out patches.
01-base -> worked acceptably, some minor changes necessary because
grsecurity touches some of the same files, mostly related to grsecurity.
New diff created.
02-syscall -> clean
03-switch -> clean
04-context -> problems in a bunch of files, mostly just with a different
ordering of include statements -> trivial changes. New diff created.
There were a couple of changes in kernel/signal.c, because of
grsecurity. For instance, in this section of kill_proc_info:
--
if (gr_handle_signal(p, sig))
error = -EPERM;
else
switch ((unsigned long)info) {
case 0:
if (vx_check(p->vx_id, VX_IDENT))
error = send_sig_info(sig, info, p);
break;
case 1:
error = send_sig_info(sig, info, p);
break;
default:
if ((info->si_code == SI_KERNEL)
|| vx_check(p->vx_id, VX_IDENT))
error = send_sig_info(sig, info, p);
break;
}
I had the signal first handled by grsecurity, and then passed onto
vserver's handling. I assume this is the safest way of doing this, as
grsecurity is going to be handling the signals in the specific case of
it hitting one of it's rules. It was also much simpler that way ;).
05-sched -> won't go in. Changes are too great in the sched.c and
timer.c -> for instance, they don't just use "weight" to determine
scheduline, there's very significant changes. I've skipped this patch
06-ili -> patches in with some fuzz. New diff created for good measure.
07-net -> patches in with some fuzz. Ditto.
08-vroot -> fs/Makefile failed because of grsecurity. Trivial change.
New diff created.
09-sysctl -> minor changes, except that I had to change the
include/linux/sysctl.h kernel name for KERN_VSHELPER to 61 (60 was taken
by the pre-emptive scheduler). New diff created.
So, my presumption is that the changes to sched.c and timer.c for
scheduling processes shouldn't create too much problem -> it just
reduces the security provided somewhat... although, given that the
pre-emptive scheduler improves the way the box deals with DOS attacks,
and the fact that you can enforce nice limits, etc, with grsecurity, it
shouldn't be too bad. Is there another part of the software that relies
on these patches to function properly?
Anyways, anyone with suggestions on how to merge in the sched functions,
etc? It's all welcome... I'm fairly new at kernel hacking, I'm just
doing this for fun right now <grin>.
Anyways, I'll get back to this one probably after Christmas, but if
anyone has ideas, let me know...
Cheers,
Liam
_______________________________________________
Vserver mailing list
Vserver_at_list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver