Message-ID: <41AA9E26.4070105@verizon.net>
Date: Sun, 28 Nov 2004 22:57:26 -0500
From: Jim Nelson <james4765@verizon.net>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922
MIME-Version: 1.0
To: linux-kernel@vger.kernel.org
Subject: Question about /dev/mem and /dev/kmem
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1318
Lines: 26

I was looking at some articles about rootkits on monolithic kernels, and had a 
thought.  Would a kernel config option to disable write access to /dev/mem and 
/dev/kmem be a workable idea?

I know it'll kill X (unless you're using the framebuffer X server), but would 
there be any other big problems?  SELinux has a finer-grained control over those 
files, but also involves a bit of administrative and system overhead.

I see this as an option that could be used in routers, web servers, firewalls and 
other systems that have a greater risk of exposure to rootkits.  Granted, it only 
makes sense with a monolithic kernel, but most people nowadays would only use 
monolithic kernels for security reasons.  You could also put a couple of 
printk()'s in to raise alarms if someone does try to open the device file for writing.

Am I speaking ex rectum?  Granted, I'm kinda new to this, but I can't see any 
reason not to offer the choice to someone compiling a kernel - and I think it 
could be done with a minimum of code bloat.

I offer this to the firing range ;)

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