Messages in this thread |  | | Date | Thu, 5 Sep 1996 23:52:10 +0200 | From | JF Martinez <> | Subject | Five backdoors in secure mode |
| |
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
|  |