[547] in linux-security and linux-alert archive
about chroot.
daemon@ATHENA.MIT.EDU (owner-linux-security@tarsier.cv.nr)
Thu Jan 4 04:26:46 1996
From: owner-linux-security@tarsier.cv.nrao.edu
Date: Wed, 3 Jan 1996 18:54:14 -0500 (EST)
To: luka <luka@mhv.net>
cc: BIG-LINUX@NETSPACE.ORG,
Linux Security Mailing List <linux-security@tarsier.cv.nrao.edu>
In-Reply-To: <9601032252.AA04916@mhv.net>
[I am CC'ing this to linux-security mailing list. -- Alex]
> Umm.. there are no users on a system without the programs. Are you saying
> you can't chroot his shell? You have to fiddle a bit, and it is not as
> 'secure' as it could be, but chroot will work. If modifying some scripts and
> variables, chrooting a coupla programs, etc.. Is not enough, then you
> obviously have a user on your hands that should not be on the system.
That is obviously incorrect. The function of chroot is to changes
the entire environment. That environment consists of all the parts of the
tree that can be accessed by that process. In Linux as in most of modern
UNIX systems majority of binaries are compiled with shared libraries that
are locted in /lib /usr/lib /usr/X11R6/lib etc etc etc. The number
of programs that are compiled statically and do not require access to
anything in system directories (that is directories above the user's
home) is very small.
This means that unless one can provide an environment where entire system
tree is being cloned below user's home directory, majority of programs
won't work. One of programs that won't work is ls, because it requires
ability to extract uid/gid information from /etc/passwd and /etc/group
files that are located above user's directory.
There are two ways to clone a filestructure. They could be cloned below
users directory:
/
/dev
/usr
/lib
/var/CHROOTED/user <---- chroot'ed process
|
\--> /usr \
/dev | cloned in chroot'ed environment
/lib |
/var /
This is the case where cloning entire system does not seem to be a
good idea. First of all due to the fact that by cloning filesystem
*below* user's owned directory, system administrator creates
interruptable paths (i.e. whole parts of the tree would be controlled by
a user which would allow him/her to perform all kind of operations that
could alter the chroot environment).
The second possible way is to make both user's home and s system clone
subdirectories of one directory and then chroot into that directory. In
that case there is no difference that I can see between a normal
non-restricted environment with / as the root of the tree and such
chroot'ed environment.
If you want to lock out a user from the ability to execute all commands
but a specific set, the better solution would be to create a special
group, make that user a member of it; make everybody else a member of a
group "users"; make all directories that contain binaries that should not
be executed by restricted user owned
root:users 750
and finally create a directory of "allowed" commands with protecting mode
root:root 755
It is important to protect directories and not files because you still
want to correctly working setgid programs.
> > I believe what you want is the chroot command. (man chroot..)
> Wrong. it is a lot harder to restrict a user into a directory than to
> restric a running program. Basically, it is usually not worth the time...
Best wishes,
Alex
============================================================================
Alexander O. Yuriev Email: alex@bach.cis.temple.edu
CIS Labs, TEMPLE UNIVERSITY WWW: http://bach.cis.temple.edu/personal/alex
Philadelphia, PA, USA
KeyID: 1024/D62D4489 Key Fingerprint: AE84534377CCC4E2 37B13C4D8CD3D501
Unless otherwise stated, everything above is my personal opinion and not an
opinion of any organisation affiliated with me.
=============================================================================
