> 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
/dev/kmem.
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.
Chris
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 :-)