[gentoo-hardened] kernel-guard

[gentoo-hardened] kernel-guard

[Daniel Struck]

Hi,


"*Kernel-Guard:* It is a sort of rootkit, that prevent anyone include
the root from loading or unloading modules...."

Is it wise to run this "kernel-guard"
(http://www.informatik.uni-freiburg.de/~alsbiha/code.htm)?

Amir Alsbih, who found out how to write a rootkit for the 2.6 series of
the Linux kernel, now proposes a module, which uses the same method to
prevent any other module to load into memory.


Greetings,
soulwarrior

-- 
gentoo-hardened@gentoo.org mailing list

Re: [gentoo-hardened] kernel-guard

[Alex Efros]

Hi!

On Fri, Feb 24, 2006 at 11:37:08AM +0100, Daniel Struck wrote:
> "*Kernel-Guard:* It is a sort of rootkit, that prevent anyone include
> the root from loading or unloading modules...."
> 
> Is it wise to run this "kernel-guard"
> (http://www.informatik.uni-freiburg.de/~alsbiha/code.htm)?
> 
> Amir Alsbih, who found out how to write a rootkit for the 2.6 series of
> the Linux kernel, now proposes a module, which uses the same method to
> prevent any other module to load into memory.

Last version of hardened-sources has GrSecurity option for this:

---cut---
  Runtime module disabling (GRKERNSEC_MODSTOP) [N/y/?] (NEW) ?

If you say Y here, you will be able to disable the ability to (un)load
modules at runtime.  This feature is useful if you need the ability
to load kernel modules at boot time, but do not want to allow an
attacker to load a rootkit kernel module into the system, or to remove
a loaded kernel module important to system functioning.  You should
enable the /dev/mem protection feature as well, since rootkits can be
inserted into the kernel via other methods than kernel modules.  Since
an untrusted module could still be loaded by modifying init scripts and
rebooting the system, it is also recommended that you enable the RBAC
system.  If you enable this option, a sysctl option with name
"disable_modules" will be created.  Setting this option to "1" disables
module loading.  After this option is set, no further writes to it are
allowed until the system is rebooted.
---cut---

-- 
			WBR, Alex.
-- 
gentoo-hardened@gentoo.org mailing list

Re: [gentoo-hardened] kernel-guard

[Peter Meier]

>> Amir Alsbih, who found out how to write a rootkit for the 2.6 series of
>> the Linux kernel, now proposes a module, which uses the same method to
>> prevent any other module to load into memory.
>
> Last version of hardened-sources has GrSecurity option for this:

in general for servers it is a good idea to disable the function of 
loading modules in the kernel. this means that you have to compile all 
in your kernel, but never have the problems of such rootkits.

greets pete
-- 
gentoo-hardened@gentoo.org mailing list

Re: [gentoo-hardened] kernel-guard

[René Rhéaume]

Does genkernel has a feature that builds a temporary kernel, reboots
the computer, performs hardware auto-detection (similar to LiveCDs)
with the temporary kernel and rebuild a monolithic kernel based on
auto-detection results?

I am a bit unconfortable on building monolithic kernels.

-- 
gentoo-hardened@gentoo.org mailing list

Re: [gentoo-hardened] kernel-guard

[Kumba]

René Rhéaume wrote:
> Does genkernel has a feature that builds a temporary kernel, reboots
> the computer, performs hardware auto-detection (similar to LiveCDs)
> with the temporary kernel and rebuild a monolithic kernel based on
> auto-detection results?

Genkernel lacked support for building monolithic kernels up until 3.3.11 when a 
--static flag was added for some livecd-building purposes (for the mips arch 
mainly).

The rest of the features it doesn't currently do.  Though, genkernel-4 is to be 
more modular, so writing and adding this feature should be easier if so desired.


> I am a bit unconfortable on building monolithic kernels.

It's not too difficult.  x86 systems don't really have a kernel memory limit 
afaik, so as long as you know what hardware is in your system, and maybe what 
future hardware you may add within the next 3-5 months; building a decent 
monolithic kernel is rather easy.

Easiest way probably is configure a modular kernel the normal way, then once 
everything is selected, disable loadable module support.  All the menuconfig 
items selected for modules will get selected to be built-in monolithically.


--Kumba

-- 
Gentoo/MIPS Team Lead
Gentoo Foundation Board of Trustees

"Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere."  --Elrond
-- 
gentoo-hardened@gentoo.org mailing list

Re: [gentoo-hardened] kernel-guard

[Daniel Struck]

> Last version of hardened-sources has GrSecurity option for this:
> 
> ---cut---
>   Runtime module disabling (GRKERNSEC_MODSTOP) [N/y/?] (NEW) ?
> 

Thanks, I didn't know grsecurity already includes this feature.
Indeed I have already compiled this feature in the kernel but didn't
know about the sysctl switch "/proc/sys/kernel/grsecurity/disable_modules".

Greetings,
soulwarrior

-- 
gentoo-hardened@gentoo.org mailing list

Re: [gentoo-hardened] kernel-guard

[Dale Pontius]

Daniel Struck wrote:
>> Last version of hardened-sources has GrSecurity option for this:
>>
>> ---cut---
>>   Runtime module disabling (GRKERNSEC_MODSTOP) [N/y/?] (NEW) ?
>>
> 
> Thanks, I didn't know grsecurity already includes this feature.
> Indeed I have already compiled this feature in the kernel but didn't
> know about the sysctl switch "/proc/sys/kernel/grsecurity/disable_modules".
> 
Doesn't prevent rootkits, only raises the bar. From what I've read on
the kernel list, there are still ways to get code into a running kernel,
even with modules disabled. It's just harder

Dale Pontius

-- 
gentoo-hardened@gentoo.org mailing list

Re: [gentoo-hardened] kernel-guard

[pageexec]

On 24 Feb 2006 at 13:18, Dale Pontius wrote:
> Doesn't prevent rootkits, only raises the bar. From what I've read on
> the kernel list, there are still ways to get code into a running kernel,

such as?

-- 
gentoo-hardened@gentoo.org mailing list

Re: [gentoo-hardened] kernel-guard

[pietro ferrari]

On 2/24/06, pageexec@freemail.hu <pageexec@freemail.hu> wrote:
> On 24 Feb 2006 at 13:18, Dale Pontius wrote:
> > Doesn't prevent rootkits, only raises the bar. From what I've read on
> > the kernel list, there are still ways to get code into a running kernel,
>
> such as?

writting directly to /dev/mem

pietro.

-- 
gentoo-hardened@gentoo.org mailing list

Re: [gentoo-hardened] kernel-guard

[pageexec]

On 24 Feb 2006 at 17:00, pietro ferrari wrote:
> On 2/24/06, pageexec@freemail.hu <pageexec@freemail.hu> wrote:
> > On 24 Feb 2006 at 13:18, Dale Pontius wrote:
> > > Doesn't prevent rootkits, only raises the bar. From what I've read on
> > > the kernel list, there are still ways to get code into a running kernel,
> >
> > such as?
> 
> writting directly to /dev/mem

quote from an earlier post in the thread:

------------------------------------------------------------------------
You should
enable the /dev/mem protection feature as well, since rootkits can be
inserted into the kernel via other methods than kernel modules.
------------------------------------------------------------------------

this feature (among many others) has existed in grsec for many years
now.

-- 
gentoo-hardened@gentoo.org mailing list