>I haven't checked secure mode code recently so perhaps some of
>these backdoors have been walled.
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.)
No, No, No and No!!! I know X protocol is unsecure but the purpose of
secure mode is to let you run unsecure applications with immunity. The
goal is even if someone throws you a virus or learns the root password
he will unable to damage key files because:
a) he can't modify them in secure mode.
b) you don't start networking in unsecure mode (he can't connect).
c) You run unsecure mode only for system administration. So in this mode
you run only a limited set of commands you are sure of (because they are
in the same state you got them of the CDROM). So the virus is not
started.
This way you will be able to run that nice setuid-root SVGA game
without fear. That is when holes to secure mode will be plugged.
Of course I suppose the attacker cannot get physical access to the box
but no OS can protect you against that.
I have heard of some people are thinking of a new way to run X without
iopl. The iopl and ioperm system calls could be then be removed.
>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.
No for the same reasons. Mounting is normal activity. You are secure
mode so setuid programs cannot do damage. With the restriction I have
mentionned: if you are forced to do a full reboot then INIT cannot be
cheated into running programs from the overriding filesystem after
going unsecure.
>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.
--Jean Francois Martinez
Join the Free World side in the holy war against Microsoft's Evil Empire. (Ronald Reagan)