Path: utzoo!utgpu!watmath!clyde!att!osu-cis!killer!texbell!uhnix1!moray!siswat!buck
From: buck@siswat.UUCP (A. Lester Buck)
Newsgroups: comp.unix.wizards
Subject: Re: Restricted shell (was Re: rsh environment)
Summary: a restricted shell environment is more than just "sh -r"
Keywords: rsh .profile Kochan & Wood
Message-ID: <366@siswat.UUCP>
Date: 31 Dec 88 01:25:40 GMT
References: <1276@uwbull.uwbln.UUCP> <14640@cisunx.UUCP> <901@philmds.UUCP> <425@aurora.auvax.uucp>
Organization: Photon Graphics, Houston
Lines: 25

In article <425@aurora.auvax.uucp>, lyndon@auvax.uucp (Lyndon Nerenberg) writes:
[ ...deleted trivial demo that "sh -r" still lets one execute sh ]
> The only way to make this work properly is to modify sh to always run
> restricted mode, and make sure the users path has this version of
> sh in front of /bin/sh. You can also make sh a disabled 'builtin'
> command when you're running restricted. Either way, shell scripts
> start to act strange ...

No, the way to use rsh is to understand how it should be set up.
"Unix Shell Programming" by Kochan and Wood summarizes a sample
rsh environment, typically for a game user or a data entry clerk.
An rsh setup needs a .profile that sets a restricted path, say

PATH=/usr/rbin:/usr/restrict/bin

and set SHELL=/bin/rsh, then cd into /usr/restrict/bin.  If the user
trys to BREAK or DELETE out of the .profile at login, he is logged off.
/usr/rbin is suggested to contain *only* cat, echo, ls, mail, red,
and write.  /usr/restrict/bin might have all the games or whatever
application is to be run.  Even this setup is described as "not
really very secure."  We can all imagine some interesting attacks.
Just nothing as trivial as "$ sh".

-- 
A. Lester Buck		...!uhnix1!moray!siswat!buck