From: Geoff T. <ge...@ge...> - 2003-05-29 15:33:49
|
Hi Jeff et al, I have done work recently on mangling the mandrake 9.1 kernel SRPM for a clean insertion of SKAS3. This is "done", though subject to various improvements as/when I get some time. It is obviously of interest to me to see if this kind of thing can come pre-packaged in future releases of kernel RPMs, as it would no doubt be for users of other distributions. The problem is that going with a vanilla kernel installation risks throwing all sorts of other distribution-related installation details out of whack (eg. screwing up the functioning of admin tools for hardware management, breaking various assumptions about kernel modules and builtin support, etc). Therefore, if the "approved" kernel RPM doesn't support SKAS3, many sys-architects and admins will have great difficulty getting a SKAS3-enabled server approved, and this in turn throws the whole argument for using UMLs off the radar for many people (because I think tt mode raises too many other issues that argue against using UML). I had to pick through and adjust the skas3 patch (the ptrace-adjusted one) to play nice with the grsecurity patch that mandrake bundle (it's there for building conditionally compiled grsecurity functionality - in general it's not compiled in but the presence of the code is enough to throw off the skas3 patch). At the time I was surfing through the code, I wondered whether it would be feasible to make the SKAS functionality switchable via a kernel boot parameter, and looking at proc_mm.c, it seems like this should be the case. If /proc/mm was instead handled via devfs, this could be handled (I guess) by devfsd configuration alone, but with the eventual switch to an ioctl (for 2.6 kernels?) I'm guessing /proc/mm is unlikely to be changed in the mean time. So ... Jeff - would it be possible perhaps to release an updated skas3 patch where the initcall hook to register "mm" with procfs was conditional upon a boot parameter? If so, this would make it easier to make an argument for having SKAS functionality built in to distributed kernels but disabled by default (ie. you need the boot parameter to turn it on). It seems to me that if "mm" isn't registered into procfs, the remaining changes from the SKAS3 patch will be passive - ie. booting a skas3-enabled kernel without the parameter to turn it on should be functionally equivalent to a kernel without the skas3 patch. Is my understanding correct? Any other thoughts about this approach to getting SKAS present in distribution kernels? Cheers, Geoff -- Geoff Thorpe ge...@ge... http://www.geoffthorpe.net/ |
From: Christopher S. A. <ca...@th...> - 2003-05-31 02:42:31
|
> Hi Jeff et al, Hello > I have done work recently on mangling the mandrake 9.1 kernel SRPM for a > clean insertion of SKAS3. This is "done", though subject to various > improvements as/when I get some time. You might be interested in Roger Binns's mod_skas, skas3 as a kernel module. The module requires you have the source tree of the kernel you plan on using the module with to compile it. http://www.rogerbinns.com/modskas3/ I'm unaware if the module has disadvantages compared to native skas (other than being a module, that is). But, it's perfect for what you're asking. Just insmod skas to install, and rmmod to remove! Also, you'll need to add the one line "dumpable" ptrace fix fix: *** ../mod-skas3/proc_mm.c 2002-12-18 04:01:35.000000000 -0500 --- proc_mm.c 2003-05-28 00:32:25.000000000 -0400 *************** static int open_proc_mm(struct inode *in *** 136,137 **** --- 136,138 ---- + mm->dumpable = 1; spin_lock(&mmlist_lock); -Chris |