Re: Anyone working on 2.0.pre31-3?

Chris Evans (
Mon, 4 Aug 1997 19:01:30 +0100 (BST)

On Mon, 4 Aug 1997, Tall cool one wrote:

> The dealing with raw devices is something I will probably work on in the
> future, since it bothers me still that just anyone can still screw with my
> FS at will, and I don't see anyone else wanting to deal with it.

I'd be interested in helping you with a patch relative to 2.1.x. It seems
all the hard work is done, and all that is needed is a few strategically
placed "if (securelevel) return -EPERM" or similar. Or maybe I'm being
hideously naive. What do we need to protect? Here's a thought or two..

1) /dev/mem (or whatever its called), maybe other /dev's that are
"special", /dev/port, /dev/kmem, /dev/mem?

2) /proc/kcore

3) Loading of modules - deny at syscall level

4) iopl() call

5) ioperm() -- ouch, could break X, yet another good reason for GGI :)

6) mmap() usage. But see 1). Will also break X which expects to mmap a
chunk of physical RAM (video framebuffer, also possibly accel region) via

7) securelevel itself (done..?)

8) Attempts to mess around with init process, especially via ptrace and
related system calls, and /proc/1

9) Raw block devices. Do we limit this to "non-removable" media? (to avoid
breaking mcopy et al)

Note however that all this is probably treading on the toes of the
linux-privs project, who have reimplemented securelevel. I sincerely hope
to see their work in 2.1.x.

Just a few thoughts.

PS While on the topic of kernel security enhancements, what happened to
the ext2 ACL patches that were 'just about ready for alpha release' a
while back? Gimme, gimme :-)