Most of these have been discussed already. As far as I know, though,
very little has actually been done to the securelevel code since then.
(securelevel STILL isn't used as a bitfield????)
>1) Modules. Obvious. Unless the kernel can wheck it is a not
>modifiable file, module loading should not be allowed in secure mode.
The consensus seems to be that module loading should be disabled
entirely when the securelevel is sufficiently high[1]. The mechanism
that would be needed to make files sufficiently unmodifiable for this
would be prohinitively complex -- very un-Unix-like and too easy to
accidentally introduce security holes in.
>2) Special files. If you can use the device file to modify the files
>in it then secure mode is useless. In secure mode you shouldn't be able
>to open block special files for writing. Only mounting them.
Exactly. And mounting should also probably be disabled at a
sufficiently high[1] securelevel.
>3) Ports. A setuid-root program can drive the disk by accessing the
>ports. Not easy to plug for now because needed for X. Fortunately
>hard to use.
Disable iopl() at a sufficiently high securelevel. You shouldn't be
running X at all if you want to be secure. (Conflict of interest here:
I'm probably the only person on this list that doesn't use X anyway.)
>4) Letting init pass to unsecure mode. The problem is: a setuid-root
>program mounts a filesystem over a directory in the path. Then tells
>init to go unsecure mode. INIT executes now the new startup scripts
>but the programs executed are those of the overriding filesystem.
>IMHO going unsecure better should require a full reboot.
If init is to be allowed to decrease securelevel, it will have to be
*very* carefully written to avoid this problem. An init could quite
simply not have any facility to decrease securelevel, and there would
be no problem. Alternatively, decreasing of securelevel could be
forbidden, either at a sufficiently high[1] securelevel or entirely --
the idea is that you `go secure' at some point during booting, and
should never need to decrease the securelevel (or change it at all)
thereafter.
>5) Debuggers. If you are allowed to debug init and init is allowed to
>switch to unsecure mode then this a breach.
Disable ptracing, either of process 1 or of all processes, at a
sufficiently high securelevel. Similarly disable /proc/1 or
/proc/[1-9]*. I don't think any of this has been implemented yet. As
a temporary kludge, having init ptrace itself might work -- I haven't
looked into it.
-zefram
[1] Sufficiently high: with the current mechanism, greater than some
arbitrary number. When securelevel becomes a bitfield, having some bit
set.