"chroot - run command or interactive shell with special root directory"
(man chroot) This doesn't sound very inspiring, does it? Go read "A How
To on Creating a chroot Environment" by Tom Newsom and you will find
chroot to be one of the most exciting commands in your Linux box:

http://slackworld.berlios.de/2007/chroot_howto.html

At least, we hope so :-)

--
The Slack World Team

Mikhail Zotov wrote:

> http://slackworld.berlios.de/2007/chroot_howto.html

With all due respect to the author, the main drawback of this document,
in my opinion, is that it fails to describe realistic uses of a chroot()
environment. ("fun"?!?) It leaves me asking, "why would I want to
setup a copy of my OS in a separate environment?" and "how is this used
in the real world of computer services?"

Running a parallel OS installation has its uses (particularly for
testing *new* versions of the operating system, software upgrades or
different configurations where the difference need not be in the kernel
configuration, though neither of these uses are mentioned, let alone
expanded upon), but the primary use of a chroot() environment is to
be able to provide a limitted *subset* of the system, within a system,
not a full duplicate installation as is demonstrated in the above-linked
document.

You might want to run a web server within a chroot() environment, for
example, providing only the very minimum of support packages and device
files that are required for the web server to operate. Doing so would
seriously reduce the possible damage if, for example, the web server is
compromised (by way of an errant PHP script, for example).

Lack of setuid/setgid files (or very carefully selected and prepared
setuid/setgid files) within the chroot() environment would reduce the
possibility that such a compromise could result in the intruder gaining
elevated privileges and impose further damage to the system. This is
just an example, of course.

In previous lifetimes, prior to shadow files for password databases,
my colleagues and I would provide chroot() environments for processes
that might have been coerced into spitting out copies of the system
password file. Perhaps as an example this is now obsolete, but it
hopefully demonstrates how a chroot() environment can be worth setting up.

The reader can completely forget the idea of running a different
kernel under the chroot(), as processes running inside the chroot()
run under the kernel which the system was booted with, only with a
different concept of their "root" directory. This is not the same as
a Qemu/VmWare environment, where the system hosts one or more virtual
systems, each running their own kernels.

Note also that providing a full copy of /proc and /dev "bound" under the
chroot is most certainly not the way to provide the sort of separation
that would be considered secure for chrooting a network service (though it
might be appropriate when testing configurations of a system, or software
upgrades, etc.) The document linked to above is perhaps useful as an
introduction to chroot(), but I would hesitate to recommend it for someone
meaning to setup a chroot() environment to protect a production service.

--
----------------------------------------------------------------------
Sylvain Robitaille syl@alcor.concordia.ca

Systems and Network analyst Concordia University
Instructional & Information Technology Montreal, Quebec, Canada
----------------------------------------------------------------------

On Wed, 21 Feb 2007 04:40:12 +0000 (UTC)
Sylvain Robitaille <syl@alcor.concordia.ca> wrote:

> Mikhail Zotov wrote:
>
> > http://slackworld.berlios.de/2007/chroot_howto.html
>
> With all due respect to the author, the main drawback of this document,
> in my opinion, is that it fails to describe realistic uses of a chroot()
> environment. ("fun"?!?) It leaves me asking, "why would I want to
> setup a copy of my OS in a separate environment?" and "how is this used
> in the real world of computer services?"
>
> Running a parallel OS installation has its uses (particularly for
> testing *new* versions of the operating system, software upgrades or
> different configurations where the difference need not be in the kernel
> configuration

I think, this is not as few as it may look. Personally, I like the
possibility to test new software, including window managers, without
touching the production environment.

After studying the howto I realised a chroot environment can also help
me to maintain an *old* version of the operating system. Specifically,
I am running a server with an old version of Slackware, with not a single
compiler installed for the sake of security. In order to be able to
compile programs for the server, I had to have the same version of Slack
installed on a separate partition of my main machine, and to reboot
(twice!) every time I needed to compile a program. The howto gave me
an idea how I can easily avoid the (boring) procedure of rebooting
my "production" machine.

> ... The document linked to above is perhaps useful as an
> introduction to chroot(), but I would hesitate to recommend it for someone
> meaning to setup a chroot() environment to protect a production service.

I think, the author didn't stated such a goal. Interestingly,
there are quite a lot of howtos in the Net devoted to protecting
a service in a chroot environment but I have failed to find any
describing its possible "everyday use".


Regards,
Mikhail

Mikhail Zotov <invalid_muxaul@lenta.ru> wrote:
> Personally, I like the possibility to test new software, including
> window managers, without touching the production environment.

> Specifically, I am running a server with an old version of Slackware,
> with not a single compiler installed for the sake of security. In order
> to be able to compile programs for the server, I had to have the same
> version of Slack installed on a separate partition of my main machine,
> and to reboot (twice!) every time I needed to compile a program.

One solution to these two problems would be to use a program like qemu
which emulates a computer. For this emulated computer you can create
different disk images containing different OS installations. Instead of
rebooting the entire machine to run another OS installation you simply
start the emulator program instead.

The images contianing OS installations can easily be copied from images
containing reference installations and if you want to try something
"dangerous" on an OS installation you know that if you don't like it you
can simply remove that image and start again from a fresh copy of your
reference installation. Qemu even has a "snapshot" mode which means that
no changes are saved to the image.

regards Henrik
--
The address in the header is only to prevent spam. My real address is:
hc1(at)poolhem.se Examples of addresses which go to spammers:
root@localhost postmaster@localhost

On Fri, 23 Feb 2007 08:21:15 +0100
Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> wrote:

> Mikhail Zotov <invalid_muxaul@lenta.ru> wrote:
> > Personally, I like the possibility to test new software, including
> > window managers, without touching the production environment.
>
> > Specifically, I am running a server with an old version of Slackware,
> > with not a single compiler installed for the sake of security.
....
>
> One solution to these two problems would be to use a program like qemu
> which emulates a computer. For this emulated computer you can create
> different disk images containing different OS installations. Instead of
> rebooting the entire machine to run another OS installation you simply
> start the emulator program instead.

Thank you for the idea, Henrik. IIRC, I have read that qemu is pretty
greedy for resources. Is this correct?

Mikhail

Mikhail Zotov <invalid_muxaul@lenta.ru> wrote:
> Thank you for the idea, Henrik. IIRC, I have read that qemu is pretty
> greedy for resources. Is this correct?

Of course it needs rather much RAM as you need RAM both for your host
computer running other applications and RAM for the emulated computer. On
the command line you can specify how much RAM you want to assign to the
emulated computer. A small amount means more RAM for running other
applications on your host computer but a less powerful emulated machine.

Also, runing an emulated system in qemu is not as fast as running on real
hardware. It is possible to speed up qemu by using a closed source kernel
module. Also, the 2.6.20 Linux kernel has support for something called kvm
which is supposed to speed up a patched version of qemu on the right
hardware, however, I haven't tried kvm myself.

Even though it is true that applications and other tasks like compiling
programs will run faster on a dual boot system I still prefer to do such
things in qemu instead of dual boot.

regards Henrik
--
The address in the header is only to prevent spam. My real address is:
hc1(at)poolhem.se Examples of addresses which go to spammers:
root@localhost postmaster@localhost

On Sun, 25 Feb 2007 21:13:55 +0100, Henrik Carlqvist wrote:

> Mikhail Zotov <invalid_muxaul@lenta.ru> wrote:
>> Thank you for the idea, Henrik. IIRC, I have read that qemu is pretty
>> greedy for resources. Is this correct?
>
> Of course it needs rather much RAM as you need RAM both for your host
> computer running other applications and RAM for the emulated computer.
> On the command line you can specify how much RAM you want to assign to
> the emulated computer. A small amount means more RAM for running other
> applications on your host computer but a less powerful emulated machine.
>
> Also, runing an emulated system in qemu is not as fast as running on
> real hardware. It is possible to speed up qemu by using a closed source
> kernel module.

I'm very happy to add that the module I believe you're talking about
has, quite recently, changed its status from 'free but not public' to
fully GPL OpenSource, please check the site :

(News)
---------
Feb 6, 2007
The QEMU Accelerator version 1.3.0pre11 is available (Changelog) in Open
Source under the GNU General Public License. A detailed technical
specification and API description is available.
---------

And the 'POV from the maker' is here:
http://fabrice.bellard.free.fr/qemu/license.html

> Even though it is true that applications and other tasks like compiling
> programs will run faster on a dual boot system I still prefer to do such
> things in qemu instead of dual boot.

I certainly agree with you to this point, although my benches of
"pure perfs", lately, were quite shaky I'm still standing }+~)