Xref: utzoo comp.sys.ibm.pc.misc:5008 comp.sys.novell:201
Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!rpi!uupsi!mstr!sa2.hgc.edu!craig
From: craig@sa2.hgc.edu (craig chaiken)
Newsgroups: comp.sys.ibm.pc.misc,comp.sys.novell
Subject: Re: shelling to Dos
Message-ID: <1990Dec25.233917.15240@mstr.hgc.edu>
Date: 25 Dec 90 23:39:17 GMT
References: <1990Dec24.012958.9228@magnus.ircc.ohio-state.edu>
Sender: Usenet@mstr.hgc.edu (Action News Central)
Reply-To: craig@sa2.hgc.edu.UUCP (craig chaiken)
Organization: The Hartford Graduate Center, Hartford CT.
Lines: 28
Nntp-Posting-Host: sa2.hgc.edu

In article <1990Dec24.012958.9228@magnus.ircc.ohio-state.edu> salter@magnus.ircc.ohio-state.edu (John E Salter) writes:
>
>How does one prevent an application from shelling to DOS?
>Particuarly applications running on a novell network
>which is started from a menu system.  Thank you.
>
The following is a list of ways to prevent an application from shelling out to
DOS:

1)	Rename COMMAND.COM just prior to executing the application, and restore
	it upon exit from the application.  (Dangerous if the machine crashes
	while COMMAND.COM is renamed).
2)	Fill up RAM with so many TSRs that insufficient RAM is available for
	shelling to DOS (I like this option).
3)	Patch the application, so as not to offer the DOS shell option.
4)	Write a TSR to capture the INT 21H EXEC function (AH=4BH).  Ignor any
	requests to run COMMAND.COM, and execute all other requests. (Actually,
	not that hard to program, but certainly not for beginners).
5)	If you run SHARE.EXE, you might be able to lock the COMMAND.COM
	file as WRITE-ONLY (I've never tried this).  You would have to do this
	from a TSR, in order to keep the file locked, though.

I hope at least one of these methods proves to be useful.

Craig Chaiken
(Author of "Blueprint of a LAN",
and soon to be released, "Beyond Blueprint of a LAN")
craig@mstr.hgc.edu