Secure (regular) Scripts_

[Martin Weitzel]

In article <9100020 at m.cs.uiuc.edu> carey at m.cs.uiuc.edu writes:
>
>I have made a  guest login on one of our machines, for outside people
>to get access to some notesfiles and send mail to users and things like
>that.  It runs a shell script (bourne shell), which allows the guest
>user to choose from a menu of things to do.
>
>I want to keep people in this shell script, and not allow them to have
>access to a regular shell.  One thing I have tried to prevent is having
>people send interrupts and things like that to interrupt the shell
>script.
>

You should *very* strongly consider, to let those unprotected guest
logins run in a 'chroot'-ed environment. There were some recent
postings, explaining how this could be done without any programming,
if you place a '*' in the 'shell'-field of "/etc/passwd". (I did not
try it, but if it shouldn't work, it's not so hard to do what is
necessary by a small program you write yourself.)

Chroot is not so well documented in the most systems. Basically it
changes the 'root'-directory for a process and all its children.
This effectivly limits the accessible part of the file system to
a subtree of your choice - the subtree below the new root.

It requires a little bit of thinking, which commands should be
placed into the 'chroot'-ed environment, because clearly the
"/bin", "/usr/bin" -Directories would no longer be accessible,
from a new root, say "/usr/guestroot". But this thinking is
worth the effort, because then you can be sure of the worst
case that may happen, if you have overlooked a possibility,
how someone might get an interactive shell. My prefered
technique would be to place the new root on a separate
disk partition, because then an evil 'guest' would not have
the possibility to fill my other file systems.

>Another big problem is that many things, like notes, mail, and even editors,
>have "shell escapes" built into them.
>
>Is there any way to prevent people from using these shell escapes, or at least
>having them not be able to do anything once they have done it?  Do I have to 
>rewrite mail and editors, to disable the shell escapes?  I wanted to avoid
>using the "rsh" (restricted shell) since that is kind of an administrative 

Professionell software should obbey some environment variable (often
it is named SHELL) to decide, if a "shell escape" is allowed.
But please, do not depend on this or worse, rely on it: If you
don't have the source of the program, you can never decide if
there are some 'hidden' ways, the programmer has overlooked.
(There is many poor software out, that was not at all programmed
with security in mind. For obvious reasons, I'll not give any
examples here.)

If you yourself are a programming, you should read the book:
"UNIX System Security", by Kochan & Wood, which explains the
possible pitfalls in detail.

>hassle.  It would be better than rewriting editors.  The best thing would
>be some kind of trick to have them end up in a black hole somewhere when
>they do a shell escape.

If you use the 'chroot' approach, that I described above, it should
be easy to replace the shell by some 'black hole', if none of the
software that is used there, depends on "/bin/sh" beeing the 'real
bourne shell' - because "/bin/sh" is the file "sh" in the directory
"bin" below your *new* root!
-- 
Martin Weitzel, email: martin at mwtech.UUCP, voice: 49-(0)6151-6 56 83