The fork attack shouldn't be possible. On SunOS, for example, when the
PIDs wrap, they wrap to 101, not 1. Doesn't Linux do something like
this? If it wraps to 1, this has to change -- conceptually, low PIDs
are a privileged resource, so access to them must be restricted.
>However, one thing which could be done fairly easily would be to (a)
>protect init from all attacks, making it immune to ptrace, kill -9
>etc; and (b) disable all direct kernel access (such as /dev/mem or
>loading new kernel modules) once securelev is sufficiently high.
It has to remain possible to signal init, at least at low
securelevels. Disabling ptrace on init is a good idea. I don't think
ptrace on init deserves a securelevel bit, as the only people who need
to do it are those writing init, and it's not hard to modify the kernel
to remove such a restriction.
Disabling module loading is an obvious thing to do with securelevel.
I'm not sure about /dev/mem -- I guess it makes sense to disable it, as
/proc now does most normal things that formerly required /dev/kmem.
/proc/pid/mem is trickier, as it has potential application as a way to
implement shared memory between arbitrary processes. Maybe just
/proc/1/mem should disappear. Or how about all of /proc/1?
-zefram