Here's how to stop shell escapes from vi

[Martin Weitzel]

In article <1990Sep21.040106.14873 at looking.on.ca> brad at looking.on.ca (Brad Templeton) writes:
>Pretty drastic to forbid certain characters like :! in vi.
(And it isn't sufficient, as I pointed out in another article.)
>
>I once set up my system with a special subdirectory that had a mini
>root filesystem on it.
>
>I then created a login shell that chroot'd the users into that directory
>and started up their shell there.

Many systems today support an asterix in the login-shell field of
/etc/passwd. In this case, the standard-login chroot-s to the home
directory and re-executes itself. Ie. you can simply place /etc and /bin
below the new root. Effectively, login becomes a two-step procedure now:
First you must login to the chroot-environment (password controlled by
standard /etc/passwd), then you login to your account within the mini-root
(password controlled by the /etc/passwd *there*).

>They can play there all they want, and it is safe.  As long as you keep
>permissions clean on the main subdirectories (ie. don't leave /etc and
>/dev and its important files unprotected) you are fine.  You link in
>the files and binaries you want to give them.

Despite the duplicated disk space I would rather copy files, as this
makes them a bit more protected against infecting them with viruses,
if - by accident - the permissions for the executable are not set right.

>There are a few problems, of course:

>a) Unless you have symlinks, you can't link in files that are on a
>different filesystem.  In general, you either want to create this mini
>system on the root FS (so you can link in stuff from /bin and /usr) or
>you have to waste a lot of disk space copying those binaries.

See above.

>b) Users can't change their passwords, unless you make some special
>program that looks at their fake password file and copies up passwords,
>which is risky.

With the method describe in the beginning, users can't change the password
for login to the mini-root, but hey *can* change the password for login
into their account there!

>c) Unless the news spool happens to be inside the protected subtree, as
>well as the news library, users can't read news.  *but*, you can run
>NNTP on the machine, the server running in the real world and the client
>in the protected world.

Similar schemes could be set-up for other purposes. Eg. "rn" could
be split in a "server" and a "client", which communicate through named
pipes. The client is started from the protected subtree, the server sits
on the other side in the normal environment. As data-transfer through
named pipes can be considered reliable and doesn't involve all the
nastynesses of transmission lines, an RPC-scheme could become amazingly
simple (you need not provide for asynchronous events or lost or garbled
messages).

What would be necessary were to identify all the operations (esp.
opening, reading and writing files) which must be executed in the
original root (not the protrected sub-tree) and map them into calls to
the server. It should suffice to copy a unique ID for the called function
plus the unchanged parameters "upstream" to the server, read what comes
back "downstream" and reassemble it as it would normally appear when the
specific functions returns. The server could also be kept very simple:
It must switch to the called function using the uniq ID, then assemble
the bytes that come upstream from the client as function parameters, call
the function, gather the result and copy it downstream to the client.

>Chroot plus symlinks would create the perfect secure mini-environment.
>You are fully protected unless the pesky users can figure out how to
>become root.   Most tricks for doing this involve greek horses or fiddling
>with files used by suid programs.  But this rarely works if all you have
>access to is the subdir.

Agreed. Breaking out from a chrooted environment would at least afford
to become super-user and still isn't simple then - besides much knowledge
about the specific system at least an editor for binary files were required.
-- 
Martin Weitzel, email: martin at mwtech.UUCP, voice: 49-(0)6151-6 56 83