On Fri, Dec 19, 2003 at 10:44:39AM -0800, Liam Helmer wrote: > 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...
I'm working on a port to ck1, and I guess it will be available soon for vs1.3.x ... best, Herbert > Cheers, > Liam > > _______________________________________________ > Vserver mailing list > [EMAIL PROTECTED] > http://list.linux-vserver.org/mailman/listinfo/vserver _______________________________________________ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
