Re: [SLUG] lock users to their home directories on a telnet?

[Roland Turner <raz@xxxxxxxxxxxxxx>]

Andrew Reilly wrote:

> I don't have it on my system, but how could a different login shell
> stop you from starting a /bin/sh with, say, a vi shell escape?
> (... or just typing /bin/sh and being done with it.)

In the former case, 'vi -S' (for nvi, other vis have different means,
some even look at the SHELL environment variable to work out whether
they are in a restricted shell environment). In the latter case, a
restricted shell will refuse to execure any command containing a '/' or
any attempt to manipulate environment variables. Needless to say, the
security of a restricted shell depends upon correct configuration by the
admin. The more facilities that you offer, the more holes that you open.

> If you're providing some sort of public hosting service, then there
> are chroot-like options, but that's effectively creating a virtual
> machine for each of your users, rather than just limiting what your
> users can generally do.

Generally speaking, if you absolutely must give shell access to multiple
users whom you don't trust to play fair (e.g. those who you would not
give superuser access to), chroot is the better path. It is (far) more
complex and resource intensive to set up, but a lot tighter. Beware
services listening on TCP ports. Loopback mounts are useful for the
users' /usr (which will be quite different to the real /usr).

> If you're providing a traditional multi-user time sharing system,
> then what harm is letting your users see the publically readable
> parts of the system going to do?

This begs the question that George didn't answer.

George: What is your situation? What are you trying to achieve? Who are
your users? Which threat(s) are you aiming to counter?

- Raz