Skip to contentSkip to conversation

Kconfig: Make config Filter access to /dev/mem default y

PATCH In review [email protected] 6 participants 13 messages Apr 13, 2010 – Apr 15, 2010 x86

lore
Share & tools
lore

[email protected]

author
#0 lore raw

PATCH 1/1 Kconfig: Make config Filter access to /dev/mem default y

Recently, most company start use >=2.6.31 kernels to replace redhat kernels. But the config "Filter access to /dev/mem" is "default n", that allows kernel rootkit using /dev/mem again. it could access all kernel memory default. Most administrator don't known the "Filter access to /dev/mem" is "defult N", when he compiles the kernel, it's easily to be attacked by rootkit.

Signed-off-by Zhitong Wang <[email protected]>
---
 arch/x86/Kconfig.debug            |    3 ++-
 arch/x86/configs/i386_defconfig   |    2 +-
 arch/x86/configs/x86_64_defconfig |    2 +-
 3 files changed, 4 insertions(+), 3 deletions(-)
arch/x86/Kconfig.debug +2 -1
index bc01e3e..733aea6 100644
@@ -7,6 +7,7 @@ source "lib/Kconfig.debug"
 
 config STRICT_DEVMEM
 	bool "Filter access to /dev/mem"
+	default y
 	---help---
 	  If this option is disabled, you allow userspace (root) access to all
 	  of memory, including kernel and userspace memory. Accidental

@@ -20,7 +21,7 @@ config STRICT_DEVMEM
 	  This is sufficient for dosemu and X and all common users of
 	  /dev/mem.
 
-	  If in doubt, say Y.
+	  If in doubt, say N.
 
 config X86_VERBOSE_BOOTUP
 	bool "Enable verbose x86 bootup info messages"
arch/x86/configs/i386_defconfig +1 -1
index d28fad1..95c85a8 100644
@@ -2386,7 +2386,7 @@ CONFIG_PROVIDE_OHCI1394_DMA_INIT=y
 # CONFIG_SAMPLES is not set
 CONFIG_HAVE_ARCH_KGDB=y
 # CONFIG_KGDB is not set
-# CONFIG_STRICT_DEVMEM is not set
+CONFIG_STRICT_DEVMEM=y
 CONFIG_X86_VERBOSE_BOOTUP=y
 CONFIG_EARLY_PRINTK=y
 CONFIG_EARLY_PRINTK_DBGP=y
arch/x86/configs/x86_64_defconfig +1 -1
index 6c86acd..659bfe7 100644
@@ -2360,7 +2360,7 @@ CONFIG_PROVIDE_OHCI1394_DMA_INIT=y
 # CONFIG_SAMPLES is not set
 CONFIG_HAVE_ARCH_KGDB=y
 # CONFIG_KGDB is not set
-# CONFIG_STRICT_DEVMEM is not set
+CONFIG_STRICT_DEVMEM=y
 CONFIG_X86_VERBOSE_BOOTUP=y
 CONFIG_EARLY_PRINTK=y
 CONFIG_EARLY_PRINTK_DBGP=y
Signature · 1 line
1.6.5.3
#1 lore raw
Quoted 5 lines · On Tue, Apr 13, 2010 at 10:52 AM, <[email protected]> wrote:

Recently, most company start use >=2.6.31 kernels to replace redhat kernels. But the config "Filter access to /dev/mem" is "default n", that allows kernel rootkit using /dev/mem again. it could access all kernel memory default. Most administrator don't known the "Filter access to /dev/mem" is "defult N", when he compiles the kernel, it's easily to be attacked by rootkit.

Have you ever successfully attack by this way? If CONFIG_STRICT_DEVMEM is not set, the /dev/mem access is filtered in pat code.

Quoted 65 lines
Signed-off-by Zhitong Wang <[email protected]>

---
 arch/x86/Kconfig.debug            |    3 ++-
 arch/x86/configs/i386_defconfig   |    2 +-
 arch/x86/configs/x86_64_defconfig |    2 +-

 3 files changed, 4 insertions(+), 3 deletions(-)
arch/x86/Kconfig.debug +0 -0
index bc01e3e..733aea6 100644
@@ -7,6 +7,7 @@ source "lib/Kconfig.debug"

 config STRICT_DEVMEM
       bool "Filter access to /dev/mem"
+       default y
       ---help---
         If this option is disabled, you allow userspace (root) access to all of memory, including kernel and userspace memory. Accidental

arch/x86/Kconfig.debug +0 -0
@@ -20,7 +21,7 @@ config STRICT_DEVMEM

         This is sufficient for dosemu and X and all common users of /dev/mem.

-         If in doubt, say Y.
+         If in doubt, say N.

 config X86_VERBOSE_BOOTUP
       bool "Enable verbose x86 bootup info messages"

arch/x86/configs/i386_defconfig +0 -0
index d28fad1..95c85a8 100644
@@ -2386,7 +2386,7 @@ CONFIG_PROVIDE_OHCI1394_DMA_INIT=y
  # CONFIG_SAMPLES is not set

 CONFIG_HAVE_ARCH_KGDB=y
 # CONFIG_KGDB is not set

arch/x86/configs/i386_defconfig +1 -1
-# CONFIG_STRICT_DEVMEM is not set
+CONFIG_STRICT_DEVMEM=y

 CONFIG_X86_VERBOSE_BOOTUP=y
 CONFIG_EARLY_PRINTK=y
 CONFIG_EARLY_PRINTK_DBGP=y

arch/x86/configs/x86_64_defconfig +0 -0
index 6c86acd..659bfe7 100644
@@ -2360,7 +2360,7 @@ CONFIG_PROVIDE_OHCI1394_DMA_INIT=y
  # CONFIG_SAMPLES is not set

 CONFIG_HAVE_ARCH_KGDB=y
 # CONFIG_KGDB is not set

arch/x86/configs/x86_64_defconfig +1 -1
-# CONFIG_STRICT_DEVMEM is not set
+CONFIG_STRICT_DEVMEM=y

 CONFIG_X86_VERBOSE_BOOTUP=y
 CONFIG_EARLY_PRINTK=y
 CONFIG_EARLY_PRINTK_DBGP=y
--
1.6.5.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

author
#2 lore raw
Quoted 8 lines · Xiaotian Feng
Quoted 5 lines · On Tue, Apr 13, 2010 at 10:52 AM,  <[email protected]> wrote:

Recently, most company start use >=2.6.31 kernels to replace redhat kernels. But the config "Filter access to /dev/mem" is "default n", that allows kernel rootkit using /dev/mem again. it could access all kernel memory default. Most administrator don't known the "Filter access to /dev/mem" is "defult N", when he compiles the kernel, it's easily to be attacked by rootkit.

Have you ever successfully attack by this way?

[root@localhost zealot]# ./zealot

[+] Found HISTSIZE.                             [SAFE]
[+] Check md5 values.                           [SAFE]
[+] eth0 was not set promsic.                   [SAFE]
[+] Not found raw socket.                       [SAFE]

system_call addr changed to 0xc04028a0,sys_call_table addr changed to 0xc0675130,Found dr rootkit!,system call sys_execve addr changed to 0xc0401582,system call sys_olduname addr changed to 0xc0405989,system call sys_fork addr changed to 0xc0407bbb

It's a host ids i wrote, it could search all kernel memory using /dev/mem. ok?

some of the code here:
static void *kmap(unsigned long off, unsigned long count)

{
        int fd;
        void *p;

        fd = open(DEV_MEM, O_RDWR);
        if (fd < 3) {
                DbgPrint("open %s failed.\n", DEV_MEM);
                dup2(fd, 3);
                close(fd);
                fd = 3;
        }

        p = mmap(NULL, ALIGNUP(count + 4097), PROT_READ | PROT_WRITE,
                MAP_SHARED, fd, ALIGNDOWN(off) & 0x0fffffff);
        if (p == MAP_FAILED)
        {
                mem_support_flag = 1;
                fprintf(stdout, "[-] /dev/mem cannot be read or write.\n");

                DbgPrint("mmap failture, errno %d\n", errno);
                close(fd);
                return NULL;
        }

        close(fd);
        return p;
}
Quoted 2 lines

If CONFIG_STRICT_DEVMEM
is not set, the /dev/mem access is filtered in pat code.

please point it, thanks.

Quoted 66 lines
Quoted 65 lines
Signed-off-by Zhitong Wang <[email protected]>

---
 arch/x86/Kconfig.debug            |    3 ++-
 arch/x86/configs/i386_defconfig   |    2 +-
 arch/x86/configs/x86_64_defconfig |    2 +-

 3 files changed, 4 insertions(+), 3 deletions(-)
arch/x86/Kconfig.debug +0 -0
index bc01e3e..733aea6 100644
@@ -7,6 +7,7 @@ source "lib/Kconfig.debug"

 config STRICT_DEVMEM
       bool "Filter access to /dev/mem"
+       default y
       ---help---
         If this option is disabled, you allow userspace (root) access to all of memory, including kernel and userspace memory. Accidental

arch/x86/Kconfig.debug +0 -0
@@ -20,7 +21,7 @@ config STRICT_DEVMEM

         This is sufficient for dosemu and X and all common users of /dev/mem.

-         If in doubt, say Y.
+         If in doubt, say N.

 config X86_VERBOSE_BOOTUP
       bool "Enable verbose x86 bootup info messages"

arch/x86/configs/i386_defconfig +0 -0
index d28fad1..95c85a8 100644
@@ -2386,7 +2386,7 @@ CONFIG_PROVIDE_OHCI1394_DMA_INIT=y
  # CONFIG_SAMPLES is not set

 CONFIG_HAVE_ARCH_KGDB=y
 # CONFIG_KGDB is not set

arch/x86/configs/i386_defconfig +1 -1
-# CONFIG_STRICT_DEVMEM is not set
+CONFIG_STRICT_DEVMEM=y

 CONFIG_X86_VERBOSE_BOOTUP=y
 CONFIG_EARLY_PRINTK=y
 CONFIG_EARLY_PRINTK_DBGP=y

arch/x86/configs/x86_64_defconfig +0 -0
index 6c86acd..659bfe7 100644
@@ -2360,7 +2360,7 @@ CONFIG_PROVIDE_OHCI1394_DMA_INIT=y
  # CONFIG_SAMPLES is not set

 CONFIG_HAVE_ARCH_KGDB=y
 # CONFIG_KGDB is not set

arch/x86/configs/x86_64_defconfig +1 -1
-# CONFIG_STRICT_DEVMEM is not set
+CONFIG_STRICT_DEVMEM=y

 CONFIG_X86_VERBOSE_BOOTUP=y
 CONFIG_EARLY_PRINTK=y
 CONFIG_EARLY_PRINTK_DBGP=y
--
1.6.5.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

#3 lore raw
Quoted 11 lines · wzt wzt
Quoted 8 lines · Xiaotian Feng
Quoted 5 lines · On Tue, Apr 13, 2010 at 10:52 AM,  <[email protected]> wrote:

Recently, most company start use >=2.6.31 kernels to replace redhat kernels. But the config "Filter access to /dev/mem" is "default n", that allows kernel rootkit using /dev/mem again. it could access all kernel memory default. Most administrator don't known the "Filter access to /dev/mem" is "defult N", when he compiles the kernel, it's easily to be attacked by rootkit.

Have you ever successfully attack by this way?

[root@localhost zealot]# ./zealot

so you're running rootkit as a root user?

Quoted 37 lines

[+] Found HISTSIZE.                             [SAFE]
[+] Check md5 values.                           [SAFE]
[+] eth0 was not set promsic.                   [SAFE]
[+] Not found raw socket.                       [SAFE] system_call addr changed to 0xc04028a0,sys_call_table addr changed to 0xc0675130,Found dr rootkit!,system call sys_execve addr changed to 0xc0401582,system call sys_olduname addr changed to 0xc0405989,system call sys_fork addr changed to 0xc0407bbb

It's a host ids i wrote,  it could search all kernel memory using /dev/mem. ok?

some of the code here:
static void *kmap(unsigned long off, unsigned long count) {
       int fd;
       void *p;

       fd = open(DEV_MEM, O_RDWR);
       if (fd < 3) {
               DbgPrint("open %s failed.\n", DEV_MEM); dup2(fd, 3);
               close(fd);
               fd = 3;
       }

       p = mmap(NULL, ALIGNUP(count + 4097), PROT_READ | PROT_WRITE, MAP_SHARED, fd, ALIGNDOWN(off) & 0x0fffffff); if (p == MAP_FAILED)
       {
               mem_support_flag = 1;
               fprintf(stdout, "[-] /dev/mem cannot be read or write.\n");

               DbgPrint("mmap failture, errno %d\n", errno); close(fd);
               return NULL;
       }

Quoted 8 lines

       close(fd);
       return p;
}

Quoted 2 lines

If CONFIG_STRICT_DEVMEM
is not set, the /dev/mem access is filtered in pat code.

please point it, thanks.

Years ago, someone sent the same patch.
check http://lkml.org/lkml/2008/11/7/361

Quoted 67 lines
Quoted 66 lines
Quoted 65 lines
Signed-off-by Zhitong Wang <[email protected]>

---
 arch/x86/Kconfig.debug            |    3 ++-
 arch/x86/configs/i386_defconfig   |    2 +-
 arch/x86/configs/x86_64_defconfig |    2 +-

 3 files changed, 4 insertions(+), 3 deletions(-)
arch/x86/Kconfig.debug +0 -0
index bc01e3e..733aea6 100644
@@ -7,6 +7,7 @@ source "lib/Kconfig.debug"

 config STRICT_DEVMEM
       bool "Filter access to /dev/mem"
+       default y
       ---help---
         If this option is disabled, you allow userspace (root) access to all of memory, including kernel and userspace memory. Accidental

arch/x86/Kconfig.debug +0 -0
@@ -20,7 +21,7 @@ config STRICT_DEVMEM

         This is sufficient for dosemu and X and all common users of /dev/mem.

-         If in doubt, say Y.
+         If in doubt, say N.

 config X86_VERBOSE_BOOTUP
       bool "Enable verbose x86 bootup info messages"

arch/x86/configs/i386_defconfig +0 -0
index d28fad1..95c85a8 100644
@@ -2386,7 +2386,7 @@ CONFIG_PROVIDE_OHCI1394_DMA_INIT=y
  # CONFIG_SAMPLES is not set

 CONFIG_HAVE_ARCH_KGDB=y
 # CONFIG_KGDB is not set

arch/x86/configs/i386_defconfig +1 -1
-# CONFIG_STRICT_DEVMEM is not set
+CONFIG_STRICT_DEVMEM=y

 CONFIG_X86_VERBOSE_BOOTUP=y
 CONFIG_EARLY_PRINTK=y
 CONFIG_EARLY_PRINTK_DBGP=y

arch/x86/configs/x86_64_defconfig +0 -0
index 6c86acd..659bfe7 100644
@@ -2360,7 +2360,7 @@ CONFIG_PROVIDE_OHCI1394_DMA_INIT=y
  # CONFIG_SAMPLES is not set

 CONFIG_HAVE_ARCH_KGDB=y
 # CONFIG_KGDB is not set

arch/x86/configs/x86_64_defconfig +1 -1
-# CONFIG_STRICT_DEVMEM is not set
+CONFIG_STRICT_DEVMEM=y

 CONFIG_X86_VERBOSE_BOOTUP=y
 CONFIG_EARLY_PRINTK=y
 CONFIG_EARLY_PRINTK_DBGP=y
--
1.6.5.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

author
#4 lore raw
Quoted 2 lines

so you're running rootkit as a root user?

rootkit always run as a root user.

Quoted 2 lines

Years ago, someone sent the same patch.
check http://lkml.org/lkml/2008/11/7/361

thanks, i read it. But nowadays >= 2.6.26 kernel became more popular, more people start use it. When they compile the kernel, they don't change KERNEL_HACKING option, becasue they are not kernel prgramer.

#5 lore raw
In reply to wzt wzt
Quoted 9 lines · wzt wzt
Quoted 8 lines · Xiaotian Feng
Quoted 5 lines · On Tue, Apr 13, 2010 at 10:52 AM,  <[email protected]> wrote:

Recently, most company start use >=2.6.31 kernels to replace redhat kernels. But the config "Filter access to /dev/mem" is "default n", that allows kernel rootkit using /dev/mem again. it could access all kernel memory default. Most administrator don't known the "Filter access to /dev/mem" is "defult N", when he compiles the kernel, it's easily to be attacked by rootkit.

Have you ever successfully attack by this way?

I'm curious about the result if you open this option to yes.

Quoted 27 lines

[root@localhost zealot]# ./zealot
[+] Found HISTSIZE.                             [SAFE]
[+] Check md5 values.                           [SAFE]
[+] eth0 was not set promsic.                   [SAFE]
[+] Not found raw socket.                       [SAFE] system_call addr changed to 0xc04028a0,sys_call_table addr changed to 0xc0675130,Found dr rootkit!,system call sys_execve addr changed to 0xc0401582,system call sys_olduname addr changed to 0xc0405989,system call sys_fork addr changed to 0xc0407bbb

It's a host ids i wrote,  it could search all kernel memory using /dev/mem. ok?

some of the code here:
static void *kmap(unsigned long off, unsigned long count) {
       int fd;
       void *p;

       fd = open(DEV_MEM, O_RDWR);
       if (fd < 3) {
               DbgPrint("open %s failed.\n", DEV_MEM); dup2(fd, 3);
               close(fd);
               fd = 3;
       }

Quoted 2 lines

       p = mmap(NULL, ALIGNUP(count + 4097), PROT_READ | PROT_WRITE, MAP_SHARED, fd, ALIGNDOWN(off) & 0x0fffffff);

mmap_mem in drivers/char/mem.c

        if (!range_is_allowed(vma->vm_pgoff, size))
                return -EPERM;

        if (!phys_mem_access_prot_allowed(file, vma->vm_pgoff, size,
                                                &vma->vm_page_prot))
                return -EINVAL;

If kernel is not set CONFIG_STRICT_DEVMEM, range_is_allowed will return 1 always, and phys_mem_access_prot_allowed is defined as weak.

In arch/x86/mm/pat.c, phys_mem_access_prot_allowed is defined, and range_is_allowed is declared to check the mem access w/o CONFIG_STRICT_DEVMEM, so it looks like the same as kernel w/ CONFIG_STRICT_DEVMEM.

What's the result for kernel w/ CONFIG_STRICT_DEVMEM ? does it prevent your rootkit?

Quoted 85 lines

       if (p == MAP_FAILED)
       {
               mem_support_flag = 1;
               fprintf(stdout, "[-] /dev/mem cannot be read or write.\n");

               DbgPrint("mmap failture, errno %d\n", errno); close(fd);
               return NULL;
       }

       close(fd);
       return p;
}

Quoted 2 lines

If CONFIG_STRICT_DEVMEM
is not set, the /dev/mem access is filtered in pat code.

please point it, thanks.

Quoted 66 lines
Quoted 65 lines
Signed-off-by Zhitong Wang <[email protected]>

---
 arch/x86/Kconfig.debug            |    3 ++-
 arch/x86/configs/i386_defconfig   |    2 +-
 arch/x86/configs/x86_64_defconfig |    2 +-

 3 files changed, 4 insertions(+), 3 deletions(-)
arch/x86/Kconfig.debug +0 -0
index bc01e3e..733aea6 100644
@@ -7,6 +7,7 @@ source "lib/Kconfig.debug"

 config STRICT_DEVMEM
       bool "Filter access to /dev/mem"
+       default y
       ---help---
         If this option is disabled, you allow userspace (root) access to all of memory, including kernel and userspace memory. Accidental

arch/x86/Kconfig.debug +0 -0
@@ -20,7 +21,7 @@ config STRICT_DEVMEM

         This is sufficient for dosemu and X and all common users of /dev/mem.

-         If in doubt, say Y.
+         If in doubt, say N.

 config X86_VERBOSE_BOOTUP
       bool "Enable verbose x86 bootup info messages"

arch/x86/configs/i386_defconfig +0 -0
index d28fad1..95c85a8 100644
@@ -2386,7 +2386,7 @@ CONFIG_PROVIDE_OHCI1394_DMA_INIT=y
  # CONFIG_SAMPLES is not set

 CONFIG_HAVE_ARCH_KGDB=y
 # CONFIG_KGDB is not set

arch/x86/configs/i386_defconfig +1 -1
-# CONFIG_STRICT_DEVMEM is not set
+CONFIG_STRICT_DEVMEM=y

 CONFIG_X86_VERBOSE_BOOTUP=y
 CONFIG_EARLY_PRINTK=y
 CONFIG_EARLY_PRINTK_DBGP=y

arch/x86/configs/x86_64_defconfig +0 -0
index 6c86acd..659bfe7 100644
@@ -2360,7 +2360,7 @@ CONFIG_PROVIDE_OHCI1394_DMA_INIT=y
  # CONFIG_SAMPLES is not set

 CONFIG_HAVE_ARCH_KGDB=y
 # CONFIG_KGDB is not set

arch/x86/configs/x86_64_defconfig +1 -1
-# CONFIG_STRICT_DEVMEM is not set
+CONFIG_STRICT_DEVMEM=y

 CONFIG_X86_VERBOSE_BOOTUP=y
 CONFIG_EARLY_PRINTK=y
 CONFIG_EARLY_PRINTK_DBGP=y
--
1.6.5.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

author
#6 lore raw
Quoted 1 line

I'm curious about the result if you open this option to yes.

here is the result you want see:

Program zealot tried to access /dev/mem between 407000->409000.

my ids can't work around.

Quoted 2 lines

What's the result for kernel w/ CONFIG_STRICT_DEVMEM ? does it prevent your rootkit?

my program is not a rootkit, if you want to see some backdoors, please read the Mood-nt2.3 or suckit source code, have fun.

#7 lore raw
In reply to Xiaotian Feng
Quoted 2 lines · Xiaotian Feng

Have you ever successfully attack by this way? If CONFIG_STRICT_DEVMEM is not set, the /dev/mem access is filtered in pat code.

If that option doesn't add any protection, what's it good for?

#8 lore raw
Quoted 4 lines · Michal Svoboda
Quoted 2 lines

Have you ever successfully attack by this way? If CONFIG_STRICT_DEVMEM is not set, the /dev/mem access is filtered in pat code.

If that option doesn't add any protection, what's it good for?

Access to /dev/mem being filtered in PAT obviously applies only to x86.

Architectures which don't do such filtering in their respective phys_mem_access_prot_allowed() still need this option.

Signature · 2 lines
Jiri Kosina
SUSE Labs, Novell Inc.
#9 lore raw
Quoted 4 lines · Jiri Kosina

Access to /dev/mem being filtered in PAT obviously applies only to x86.

Architectures which don't do such filtering in their respective phys_mem_access_prot_allowed() still need this option.

So why not use it for all archs uniformly? Is PAT filtering better in some ways?

Michal Svoboda

#10 lore raw
Quoted 8 lines · On Thu, 15 Apr 2010 15:41:53 +0200 Michal Svoboda…
Quoted 4 lines · Jiri Kosina

Access to /dev/mem being filtered in PAT obviously applies only to x86.

Architectures which don't do such filtering in their respective phys_mem_access_prot_allowed() still need this option.

So why not use it for all archs uniformly? Is PAT filtering better in some ways?

PAT is an x86 specific hardware feature. The x86 processors can set per page caching properties as with some other CPU designs. In the x86 case all references to the page must have the same cache settings so the PAT implementation has to filter /dev/mem access to avoid machine check errors.

It's not implemented as a security feature, its a side effect of the hardware requirements on that CPU range.

Alan

#11 lore raw
In reply to Michal Svoboda
Quoted 5 lines · On Thu, 15 Apr 2010 08:36:26 +0200 Michal Svoboda…
Quoted 2 lines · Xiaotian Feng

Have you ever successfully attack by this way? If CONFIG_STRICT_DEVMEM is not set, the /dev/mem access is filtered in pat code.

If that option doesn't add any protection, what's it good for?

PAT is x86 specific

#12 lore raw
In reply to [email protected]
Quoted 9 lines

config STRICT_DEVMEM

arch/x86/Kconfig.debug +1 -0
 	bool "Filter access to /dev/mem"
+	default y
 	---help---
 	  If this option is disabled, you allow userspace (root) access to all
 	  of memory, including kernel and userspace memory. Accidental

arch/x86/Kconfig.debug config STRICT_DEVMEM · line 25

Quoted 6 lines
arch/x86/Kconfig.debug +1 -1
@@ -20,7 +21,7 @@ config STRICT_DEVMEM
 	  This is sufficient for dosemu and X and all common users of
 	  /dev/mem.
 
-	  If in doubt, say Y.
+	  If in doubt, say N.

Eek.

So... what is it?

Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html