Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!cunixf.cc.columbia.edu!cs.columbia.edu!abrams From: abrams@cs.columbia.edu (Steven Abrams) Newsgroups: comp.sys.ibm.pc.misc Subject: Re: shelling to Dos Message-ID: Date: 26 Dec 90 22:22:44 GMT References: <1990Dec24.012958.9228@magnus.ircc.ohio-state.edu> <1990Dec25.024222.13265@xrtll.uucp> <52979@eerie.acsu.Buffalo.EDU> Sender: news@cs.columbia.edu (The Daily News) Followup-To: comp.sys.ibm.pc.misc Organization: Columbia University Department of Computer Science Lines: 38 In-Reply-To: cantie@acsu.buffalo.edu's message of 26 Dec 90 06:32:05 GMT 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 #include