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?
From: Christopher S. Aker <caker@th...> - 2003-05-31 02:42:31
> 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.
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.
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;