Restricted shells (or how to keep awake at night)
Bruce Freeman
bjf at utcsstat.UUCP
Tue Jul 24 13:14:29 AEST 1984
Having battled restricted shells for the past year or so I can safely
agree that you can not make a restricted shell by hacking chunks of /bin/sh
out. Unless you want to try the University of Toronto approach ... We run
Amdahl UTS on an IBM 3033 for first year students and one of the requirements
was a restricted shell. It was made (you guessed it) by hacking /bin/sh. Well
the early versions were roughly equivalent to posting the superuser password
on every wall in the city. As more and more students poked holes in it
more holes were plugged until it was fairly stable. After about a year we
had a fairly solid restricted shell due to this stepwise refinement and
the downtime associated with it. Then about a year ago it was modified to
allow students to run programs in their own directories (previously they
submitted files to another 3033 which ran MVS). They use Turing that
does not allow access to UNIX(TM) system calls. The execute bit is a
dangerous thing. You must make sure that people can not write on files
with the execute bit on since most restricted shells allow as a feature
the ability to run shell files unrestricted as long as they are invoked
through the search path and not by an absolute filename. This was thought
to be fairly safe until it was discovered that by copying . students were
creating executable shell files (cp preserves modes and . has both the
write and execute bits on ...) Another hack to cp fixed this but you can
see where this leads. You are constantly plugging holes trying to make a
secure restricted shell. Lately this restricted shell has become closer
to the regular shell and the work required to maintain it has almost
disappeared. The only thing it does not allow are absolute paths but it
allows subdirectories and practically all shell built-ins except &. You
are much better off running the real shell and choosing good passwords
for root and users in group bin then relying on a "restricted" shell for
security. No doubt the present rsh has holes but we have not had any
security problems in well over 18 months. Proper passwords and elementary
security measures are much better security then the illusion of a restricted
shell.
--
Bruce Freeman University of Toronto {decvax|harpo|ihnp4}!utcsstat!bjf
More information about the Comp.unix.wizards
mailing list