Re: another kconfig target for building monolithic kernel (for security) ?

Re: another kconfig target for building monolithic kernel (for security) ?

[devzero]

hello !

thanks for help -  i found that there seems another way for securing /dev/{k}mem (at least in recent kernels) - the docomentation for the "BSD Secure Levels Linux Security Module" (at  Documentation/seclvl.txt) tells:

Level 1 (Default):
- /dev/mem and /dev/kmem are read-only
- IMMUTABLE and APPEND extended attributes, if set, may not be unset
- Cannot load or unload kernel modules
- Cannot write directly to a mounted block device
- Cannot perform raw I/O operations
- Cannot perform network administrative tasks
- Cannot setuid any file

so - no need for compiling a static/monolithic kernel anymore !?

regards
roland





> -----Ursprüngliche Nachricht-----
> Von: Nix <nix@esperi.org.uk>
> Gesendet: 30.04.06 12:57:49
> An: Arjan van de Ven <arjan@infradead.org>
> CC: davej@redhat.com, linux-kernel@vger.kernel.org
> Betreff: Re: another kconfig target for building monolithic kernel (for security) ?


> On 29 Apr 2006, Arjan van de Ven prattled cheerily:
> > On Sat, 2006-04-29 at 12:43 -0400, Dave Jones wrote:
> >> On Sat, Apr 29, 2006 at 03:03:55PM +0200, devzero@web.de wrote:
> >> 
> >>  > i want to harden a linux system (dedicated root server on the internet) by recompiling the kernel without support for lkm (to prevent installation of lkm based rootkits etc)
> >> 
> >> Loading modules via /dev/kmem is trivial thanks to a bunch of tutorials and
> >> examples on the web, so this alone doesn't make life that much more difficult for attackers.
> > 
> > /dev/kmem should be a config option too though
> 
> Yeah, but in practice this should work (somewhat old patch, should still
> apply):
> 
> diff -durN 2.6.14-seal-orig/include/linux/capability.h 2.6.14-seal/include/linux/capability.h
> --- 2.6.14-seal-orig/include/linux/capability.h	2005-10-29 15:15:00.000000000 +0100
> +++ 2.6.14-seal/include/linux/capability.h	2005-10-29 15:25:48.000000000 +0100
> @@ -311,7 +311,7 @@
>  
>  #define CAP_EMPTY_SET       to_cap_t(0)
>  #define CAP_FULL_SET        to_cap_t(~0)
> -#define CAP_INIT_EFF_SET    to_cap_t(~0 & ~CAP_TO_MASK(CAP_SETPCAP))
> +#define CAP_INIT_EFF_SET    to_cap_t(~0 & ~CAP_TO_MASK(CAP_SETPCAP) & ~CAP_TO_MASK(CAP_SYS_RAWIO))
>  #define CAP_INIT_INH_SET    to_cap_t(0)
>  
>  #define CAP_TO_MASK(x) (1 << (x))
> 
> > (and /dev/mem should get the filter patch that fedora has ;-) 
> 
> Agreed.
> 
> -- 
> `On a scale of 1-10, X's "brokenness rating" is 1.1, but that's only
>  because bringing Windows into the picture rescaled "brokenness" by
>  a factor of 10.' --- Peter da Silva


_______________________________________________________________
SMS schreiben mit WEB.DE FreeMail - einfach, schnell und
kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192

Re: another kconfig target for building monolithic kernel (for security) ?

[devzero]

hello !

"Unfortunately, disabling /dev/mem will break many things, including X and potentially many other user-space programs"
(-> http://lwn.net/2001/0419/security.php3 )

"The /dev/mem and /dev/kmem character special files provide access to a pseudo device driver that allows read and write access to system memory or I/O address space. Typically, these special files are used by operating system utilities and commands (such as sar, iostat, and vmstat) to obtain status and statistical information about the system" (ok, this is for AIX, does this apply for linux, too? -> http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.doc/files/aixfiles/mem.htm )


mhhh - while studying this i`m getting unsure if disabling /dev/mem and /dev/kmem is a really good idea - i can live without X 
on my server, but what else also gets broken? i think i cannot live without important monitoring utilities like vmstat or sar on my server(s).

there is a nice article at LWN at http://lwn.net/Articles/147901/

maybe there is a more comprehensive list of applications which need /dev/{k}mem for proper operation or there is a method  to determine this in a reliable way (e.g. by scanning all binaries on mystem somehow) ?

regards
roland



> -----Ursprüngliche Nachricht-----
> Von: Nix <nix@esperi.org.uk>
> Gesendet: 30.04.06 12:57:49
> An: Arjan van de Ven <arjan@infradead.org>
> CC: davej@redhat.com, linux-kernel@vger.kernel.org
> Betreff: Re: another kconfig target for building monolithic kernel (for security) ?


> On 29 Apr 2006, Arjan van de Ven prattled cheerily:
> > On Sat, 2006-04-29 at 12:43 -0400, Dave Jones wrote:
> >> On Sat, Apr 29, 2006 at 03:03:55PM +0200, devzero@web.de wrote:
> >> 
> >>  > i want to harden a linux system (dedicated root server on the internet) by recompiling the kernel without support for lkm (to prevent installation of lkm based rootkits etc)
> >> 
> >> Loading modules via /dev/kmem is trivial thanks to a bunch of tutorials and
> >> examples on the web, so this alone doesn't make life that much more difficult for attackers.
> > 
> > /dev/kmem should be a config option too though
> 
> Yeah, but in practice this should work (somewhat old patch, should still
> apply):
> 
> diff -durN 2.6.14-seal-orig/include/linux/capability.h 2.6.14-seal/include/linux/capability.h
> --- 2.6.14-seal-orig/include/linux/capability.h	2005-10-29 15:15:00.000000000 +0100
> +++ 2.6.14-seal/include/linux/capability.h	2005-10-29 15:25:48.000000000 +0100
> @@ -311,7 +311,7 @@
>  
>  #define CAP_EMPTY_SET       to_cap_t(0)
>  #define CAP_FULL_SET        to_cap_t(~0)
> -#define CAP_INIT_EFF_SET    to_cap_t(~0 & ~CAP_TO_MASK(CAP_SETPCAP))
> +#define CAP_INIT_EFF_SET    to_cap_t(~0 & ~CAP_TO_MASK(CAP_SETPCAP) & ~CAP_TO_MASK(CAP_SYS_RAWIO))
>  #define CAP_INIT_INH_SET    to_cap_t(0)
>  
>  #define CAP_TO_MASK(x) (1 << (x))
> 
> > (and /dev/mem should get the filter patch that fedora has ;-) 
> 
> Agreed.
> 
> -- 
> `On a scale of 1-10, X's "brokenness rating" is 1.1, but that's only
>  because bringing Windows into the picture rescaled "brokenness" by
>  a factor of 10.' --- Peter da Silva


_______________________________________________________________
SMS schreiben mit WEB.DE FreeMail - einfach, schnell und
kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192

Re: another kconfig target for building monolithic kernel (for security) ?

[Arjan van de Ven]

On Sun, 2006-04-30 at 14:31 +0200, devzero@web.de wrote:
> hello !
> 
> "Unfortunately, disabling /dev/mem will break many things, including X and potentially many other user-space programs"
> (-> http://lwn.net/2001/0419/security.php3 )

not if you do it carefully like we did for Fedora...

> 
> "The /dev/mem and /dev/kmem character special files provide access to a pseudo device driver that allows read and write access to system memory or I/O address space. Typically, these special files are used by operating system utilities and commands (such as sar, iostat, and vmstat) to obtain status and statistical information about the system" (ok, this is for AIX, does this apply for linux, too? -> http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.doc/files/aixfiles/mem.htm )


/dev/kmem isn't used by much of anything except debugging, so having
that a config option is reasonable. for /dev/mem it's enough to disable
all access to 'what the kernel sees as RAM' with the lower 1Mb as
exception..

Re: another kconfig target for building monolithic kernel (for security) ?

[devzero]

hello !

do we need to have write access to /dev/kmem - especially on a server without X ?
iirc, write access can be disabled, for example with addons like grsecurity.
(don`t know what will be broken besides X, though)

regards
roland

> -----Ursprüngliche Nachricht-----
> Von: Dave Jones <davej@redhat.com>
> Gesendet: 29.04.06 18:43:41
> An: devzero@web.de
> CC: linux-kernel@vger.kernel.org
> Betreff: Re: another kconfig target for building monolithic kernel (for security) ?


> On Sat, Apr 29, 2006 at 03:03:55PM +0200, devzero@web.de wrote:
> 
>  > i want to harden a linux system (dedicated root server on the internet) by recompiling the kernel without support for lkm (to prevent installation of lkm based rootkits etc)
> 
> Loading modules via /dev/kmem is trivial thanks to a bunch of tutorials and
> examples on the web, so this alone doesn't make life that much more difficult for attackers.
> 
> 		Dave
> 
> -- 
> http://www.codemonkey.org.uk


_______________________________________________________________
SMS schreiben mit WEB.DE FreeMail - einfach, schnell und
kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192

another kconfig target for building monolithic kernel (for security) ?

[devzero]

Hello !

i want to harden a linux system (dedicated root server on the internet) by recompiling the kernel without support for lkm (to prevent installation of lkm based rootkits etc)

since the "minimalistic" approach (removing complexity) is always a good strategy for security , it seems that it generally isn`t a trivial task to "strip down" the running kernel with xconfig/menuconfig, i.e. to turn the running kernel into an minimalistic monolithic version which "just fits" to the current hardware and contains the absolutely necessary. 

especially when you have no physical access to the machine, there is some danger that the system doesn`t boot and needs some operator resetting it and boot into working configuration again.

what i assume what could be needed is something like a build-target "make hardened-config-based-on-running-kernel" which does the following

- look at the running kernel which components/modules are loaded/used/active
- make  a .config based on that information (i.e. remove all unneded and turn this into monolithic version)
- probably tell the user what will be disabled in the monolitic kernel 

if this doesn`t sound too dumb (comments?) - maybe there is some sort of "receipe" or project how to do this in a more comfortable way (i.e. without working through the whole .config and without in-depth knowledge of all .config params) ?

regards
roland k.
systems engineer




_______________________________________________________________
SMS schreiben mit WEB.DE FreeMail - einfach, schnell und
kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192

Re: another kconfig target for building monolithic kernel (for security) ?

[Dave Jones]

On Sat, Apr 29, 2006 at 03:03:55PM +0200, devzero@web.de wrote:

 > i want to harden a linux system (dedicated root server on the internet) by recompiling the kernel without support for lkm (to prevent installation of lkm based rootkits etc)

Loading modules via /dev/kmem is trivial thanks to a bunch of tutorials and
examples on the web, so this alone doesn't make life that much more difficult for attackers.

		Dave

-- 
http://www.codemonkey.org.uk

Re: another kconfig target for building monolithic kernel (for security) ?

[Arjan van de Ven]

On Sat, 2006-04-29 at 12:43 -0400, Dave Jones wrote:
> On Sat, Apr 29, 2006 at 03:03:55PM +0200, devzero@web.de wrote:
> 
>  > i want to harden a linux system (dedicated root server on the internet) by recompiling the kernel without support for lkm (to prevent installation of lkm based rootkits etc)
> 
> Loading modules via /dev/kmem is trivial thanks to a bunch of tutorials and
> examples on the web, so this alone doesn't make life that much more difficult for attackers.

/dev/kmem should be a config option too though

(and /dev/mem should get the filter patch that fedora has ;-) 

Re: another kconfig target for building monolithic kernel (for security) ?

[Nix]

On 29 Apr 2006, Arjan van de Ven prattled cheerily:
> On Sat, 2006-04-29 at 12:43 -0400, Dave Jones wrote:
>> On Sat, Apr 29, 2006 at 03:03:55PM +0200, devzero@web.de wrote:
>> 
>>  > i want to harden a linux system (dedicated root server on the internet) by recompiling the kernel without support for lkm (to prevent installation of lkm based rootkits etc)
>> 
>> Loading modules via /dev/kmem is trivial thanks to a bunch of tutorials and
>> examples on the web, so this alone doesn't make life that much more difficult for attackers.
> 
> /dev/kmem should be a config option too though

Yeah, but in practice this should work (somewhat old patch, should still
apply):

diff -durN 2.6.14-seal-orig/include/linux/capability.h 2.6.14-seal/include/linux/capability.h
--- 2.6.14-seal-orig/include/linux/capability.h	2005-10-29 15:15:00.000000000 +0100
+++ 2.6.14-seal/include/linux/capability.h	2005-10-29 15:25:48.000000000 +0100
@@ -311,7 +311,7 @@
 
 #define CAP_EMPTY_SET       to_cap_t(0)
 #define CAP_FULL_SET        to_cap_t(~0)
-#define CAP_INIT_EFF_SET    to_cap_t(~0 & ~CAP_TO_MASK(CAP_SETPCAP))
+#define CAP_INIT_EFF_SET    to_cap_t(~0 & ~CAP_TO_MASK(CAP_SETPCAP) & ~CAP_TO_MASK(CAP_SYS_RAWIO))
 #define CAP_INIT_INH_SET    to_cap_t(0)
 
 #define CAP_TO_MASK(x) (1 << (x))

> (and /dev/mem should get the filter patch that fedora has ;-) 

Agreed.

-- 
`On a scale of 1-10, X's "brokenness rating" is 1.1, but that's only
 because bringing Windows into the picture rescaled "brokenness" by
 a factor of 10.' --- Peter da Silva