🚀 go-pugleaf

There's another problem with eliminating access to COMMAND.COM to
prevent shelling out.  Many programs not only allow you to shell out
to DOS, but also allow you to run any program.  If we just change
COMSPEC so that the shell fails, it isn't too difficult for a user to,
instead, run COMMAND.COM as a plain program, either from the root
directory, the C:\DOS directory, or the network directory.  If you
want to make the system impervious to all of these types of things,
there are only a few options (none of which are perfect).

1) Never use COMMAND.COM as such; always rename it to something else.
This eliminates the RUN COMMAND.COM approach.  

2) In order for DOS to boot, you need a SHELL= command now.   

3) Before running the application, reset COMSPEC to either a bogus
file or, as someone else suggested, to a short program that prints "No
shell allowed" and exits.  This prevents the "normal" SHELL option
from working.   This will fail if the application is big enough to
require a reloading of COMMAND.COM on exit, as I noted earlier.  

The big problem is that there is no way to prevent the user from
looking at the COMSPEC variable BEFORE starting the application.
Then, they could find out where the real shell is and run it as a
normal program.

Latching onto the exec interrupt and being really careful about what
calls you allow and what calls you don't might be the only guaranteed
method of disabling the shell out option without crippling the system.

~~~Steve
--
/*************************************************
 *
 *Steven Abrams             abrams@cs.columbia.edu
 *
 **************************************************/
#include <std/dumquote.h>
#include <std/disclaimer.h>