[552] in linux-security and linux-alert archive
Re: about chroot.
daemon@ATHENA.MIT.EDU (Joseph S. D. Yao)
Fri Jan 5 17:24:56 1996
Date: Thu, 4 Jan 1996 13:31:30 -0500
From: "Joseph S. D. Yao" <jsdy@cais.cais.com>
To: alex@bach.cis.temple.edu, luka@mhv.net
Cc: BIG-LINUX@NETSPACE.ORG, linux-security@tarsier.cv.nrao.edu
I once had to set up a group of users in a "chroot"ed area, long ago on
a planet not very far away.
Yes, you do have to copy virtually everything in a raw Unix / Linux /
POSIX system, to get a normal user environment - except, of course, the
programs, data, services, etc. to which you're not giving those users
access. Since the latter will probably be very few things, the amount
of stuff copied will use a lot of disk space. Be warned. You then
have to add back in anything that is specially installed on your
system, such as applications. Do you only have a license to install
one copy of the application? Is your license manager file-based rather
than network-based, so that you can't properly manage licenses on both
top-level and lower-level areas? Look out. Do you need to do some
file initialization on boot-up in the chroot'ed area, that just always
gets done by default from your /etc/rc* or /etc/rc*/* files in the
top-level area? Such as clearing the utmp file? You'd better make
sure that it gets done.
You should give chroot'ed accounts to any support people that will have
to try and figure out why "X" doesn't work in the chroot'ed area, when
it is working just fine in the top-level area.
We had one account to which people had to log in, which chroot'ed to
the restricted area and then ran 'login' again. The second login read
in the information from the restricted /etc/passwd! If you don't do
this, then the passwords and other information set by the users in the
restricted area will not be reflected in the top-level passwd file!
There may have been other reasons for doing it this way, but that's one
that jumps out at me.
This was done with all the releases of System V that were available for
the VAX-11/78X systems. One thing I remember doing was incorporating
TCP/IP networking. The version we used was based on files in /dev/.
After I fixed a lot of things, it worked perfectly with other BSD-based
systems. However, we didn't move the /dev/net* files to the restricted
area, so networking was unavailable - a plus in this instance! With
modern systems, BSD-based sockets are used: I don't know how you'd keep
the users off the network, in that case. Perhaps chroot'ed processes
should also be allowed to bear flags that tells whether the various
network services are available to them. But this requires mods to the
kernel and all systems utilities that use the modified structures. I
could do that back then; but it's not so easy, these days. (Unless
you're only responsible for a single system, the users are docile, and
it's a Linux system. Not necessarily easy even then.)
Also, in System V, the 'lp' program communicated with the 'lpd' daemon
via a FIFO. I had to set up a system that passed data from the FIFO in
the restricted area back up to the top-level area, with some transla-
tion (e.g., when printing a file named /home/joe/file, change it to
/restricted/home/joe/file) and some local interpretation. In most
modern systems, BSD-based 'lpr' systems are used, which communicate via
sockets. As mentioned in the last paragraph, this may be an advantage
or a disadvantage, depending on whether you wanted to restrict access
or not.
Mail also communicated via FIFOs. Again, I set up a system to pass
data up to the mail daemon top-level. I also had to set up something
to put mail in the restricted level, using proper file locking (the
definition of which seems to have changed with each implementation of a
mail system that I've seen) to avoid conflicts with people reading
mail, while not blocking and holding up other incoming mail. I know I
had to change this a few times to accommodate unforeseen problems, but
my memory is fuzzy on details. Also again, on BSD-based systems mail
uses sockets, so outgoing mail is not restricted by 'chroot'; but you
will still have to worry about incoming mail for restricted users, and
mail between the restricted and top-level users on the same system.
There may have been some other subsystems that required special-purpose
programs to pass data between the levels; but my memory is a bit hazy
on that by now.
In general, if you set up a data flow diagram for all programs on your
system (a massive undertaking!), you may be able to see what programs
might need special treatment to work properly. More practically, if
you look at the dozen programs your users are likely to use all the
time, and analyze those, you should be mostly OK. If anything breaks
after people start using the restricted area, you can do a normal fire
drill to get it fixed.
Another consideration: think about whether, for your purposes, you
should have a top-level "shadow" home directory for each of your users
in the restricted area, or whether you should just list them in your
/etc/passwd file as having home directories /restricted/home/joe
(e.g.). The problem with the latter is with system programs that read
files in the home directory: file names in those files will (typically)
NOT point to the restricted file system! This will make some things
break for the restricted users; it's also a way for them to
surreptitiously gain access (indirectly) to the top-level file system.
The problem with the former comes when people try to access files in
(e.g.) ~joe: this would refer to the "shadow" directory, instead of the
real directory. On the whole, I consider that less of a problem.
Yet another consideration, and then I should stop and get back to my
paid work. Consider the collection of data for both accounting and
security purposes. Programs running wholly in the restricted area
won't be able to log anything to the top-level area. Again, "syslog"
these days is mostly socket-based; but what about shell accounting?
What about those clever shell scripts you call from /etc/profile?
(Assuming that you use the Korn shell: the C shell doesn't seem to have
a consistently-named equivalent across implementations.) I embedded a
few lines of code in the Korn shell so that all accounting information
and some security information went up via, yes, another FIFO. I didn't
allow use of any other shell, monster that I am. (The only other shell
then available on S5 was the Bourne shell, unless I took the time and
trouble to compile csh for them, which I didn't, since there was no
demand for it.) I'm not sure that we worried completely about keeping
utmp and wtmp updated on the top-level system: this may be a concern
for you.
X-based GUIs, being network-based, may pose a problem to you that I
didn't even consider back then.
I hope this helps. I know that this reply is also addressed to a
couple of mailing lists; so the list administrators will determine
whether this is on-topic. I just felt that you all should know that
there's more to setting up a restricted environment that just tossing a
'chroot' in somewhere.
Joe Yao jsdy@cais.com - Joseph S. D. Yao
