Five backdoors in secure mode

JF Martinez (jfm@sidney.remcomp.fr)
Thu, 5 Sep 1996 23:52:10 +0200

I haven't checked secure mode code recently so perhaps some of
these backdoors have been walled.

1) Modules. Obvious. Unless the kernel can wheck it is a not
modifiable file, module loading should not be allowed in secure mode.

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.

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.

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.

5) Debuggers. If you are allowed to debug init and init is allowed to
switch to unsecure mode then this a breach. 

-- 


			Jean Francois Martinez