Restricted shell (was Re: rsh environment)

[Lyndon Nerenberg]

In article <193 at becker.UUCP> bdb at becker.UUCP (Bruce Becker) writes:
>
>	In some versions of 'sh/rsh', the environment variable
>	"$SHELL" is special - if it ends with the string 'rsh',
>	then the restrictions are in force no matter whether one
>	entered as 'sh' or 'rsh'. "$SHELL" becomes readonly as well.

[ Alright already! The example I posted was a bit trivial :-) ]

The above example is true for the SVR3 sh. I haven't seen it (working)
in any version prior to that.

The point is, most implementations of the restricted Bourne
shell can be broken with not much more work than the example
I gave.

The SVR3 version takes more care in enforcing restriction. Anything
that grabs a subshell via popen or system will stay within the rsh
environment. As another poster mention, though, IFS can still be played
with to interesting advantage, and if the user has write access to a
directory, and the ability to generate a binary executable file (not
necessarily using cc; emacs works just fine) he's got you via exec(2).

The problem with rsh isn't really rsh, it's the wide variety of uses
the standard Unix tools can be used for. Who needs cat when dd is there?
as is redundent in the face of emacs (remember the definition of a
wizard? :-) If rsh is used to provide a restricted news environment,
you generally need to give the user an editor of some sort to compose
articles with. How many of these editors check with the shell to determine
if the save path specified is "allowed?" Etc.

Wrapping the environment inside a chroot(2) helps, but it also increases
administration headaches somewhat. I guess it's up to you to determine
if your time is better spent monitoring the restricted environment versus
writing an application wrapper to provide *only* the functions necessary
for the job.

-- 
Lyndon Nerenberg   Computing Services   Athabasca University
{alberta, attvcr, ncc}!auvax!lyndon  ||  lyndon at nexus.ca