Re: [cobalt-users] Telnet users see all

[Jens Kristian Søgaard <jens@xxxxxxxxxxxxxxxxxxxx>]

Hi Jeff,

> If you figure out how to chroot telnet on a RaQ; in fact if you figure
> out how to reliably chroot telnet on any linux system at all, please let
> us all know (all meaning the entire linux community).

Ehm, I have built chroot jails before ?!?!

It's really not that hard.

The problem is:

    1. You need to figure out what files you want to give each customer
access to (this includes program and standard commands).

    2. You need to figure out the dependencies for these files (libraries,
configfiles, etc.).

These two aren't showstoppers, but this last thing certainly is:

    3. You need to _copy_ all this files to a special directory for the
user.

This means that every telnet users would need a lot of disk space just for
setting up his account.

When using this strategy on RaQs, you also need to take care of some other
things:

    1. Restricting user access through FTP (easy)
    2. Any user that can execute CGI-scripts using the standard installation
of Apache, can also use that to login (and effectively bypassing your neat
chroot jail). This means you also have to chroot apache.

> So you ask, why can't I just write a copy of bash (for example) that
> can't cd down pas the login directory?  Actually you can.  But remember,
> linux/unix is made up of lots of small files.

No, you can't. You can't just use your own special version of bash -- you
need to chroot it!!

If you just wrote a bash that were "locked down" so you couldn't cd out of
your homedirectory, that would then prevent the user from downloading a new
bash binary and running that command from his locked down shell (effectively
giving him a full open shell).

> Linux/unix are NOT designed to be secure operating systems.

Oh, yes they are. Designers have just had to make some decisions - security,
cost and usuability. A system could be made very secure, it would however
also be very non-userfriendly. You can't have all.

Linux is designed to be reasonably secure.

It is however not designed to be secure for users that can't be bothered to
actually set their permissions right on their files (and then you might
argue that this is required because you want apache to serve files, but
that's a different issue).

Try reading Bruce Schneier's new book - Secrets and Lies. It's a very good
non-technical introduction to security.

--
Jens Kristian Søgaard, Mermaid Consulting I/S,
jens@xxxxxxxxxxxxxxxxxxxx,
http://www.mermaidconsulting.com/