The one thing that baffles me is chroot.... I understand that it's a jail to protect files' data.

Examples...
/mnt/sysimage (for rescue CD recovery)
/var/named/chroot/etc (for named script)
/var/named/chroot/var/named (for named zone files)

I see links in /var/named and /etc directories. How would those hide the files if I can read the links' paths? Or...what's the concept behind the chroot directories?

Tom D.

Chroot is used to move a user's basepoint in the file tree to a different directory. The intention behind the chroot command was not necessarily to provide a security tool. Many people use chroot as part of an enhanced security setup but in itself chroot is far from foolproof.

chroot won't hide the files in your example. You have to put a fair bit of thought to how your file tree is configured to make a security scheme which includes chroot foolproof.

---------------------
Steve Stites

chroot is "change root"; temporarily making the system use another directory as the root file system. It has many uses, such as doing maintenance on a remote system or to set up a 32 bit subsystem on a 64 bit computer. I've used it a couple of times to repair my system's bootloader from a live cd. Live cd's usually create a virtual root directory in ram, so I have to chroot into the "real" root directory on the hard disk before I can run grub and fix the problem.

Here's the scenario... one possible scenario, at least ...

Let's say that you are in the process of building and testing programs that will need to run correctly on an entirely-new Linux installation that you are in the process of building. These programs, when they are used in ordinary day-to-day operations, will run in an environment that is obviously different from the one that exists when the programs are being compiled and tested.

You are logged-in as joecool, so the program files in question are living in /home/joecool/projects/mylinux_5_08/, and within that directory you've set-up an entire directory-structure that matches the one that these programs will expect to see as their root "/" directory.

As you build and test these new programs, you need to test them in an environment where the entire /home/joecool/projects/mylinux_5_08/ directory structure doesn't exist. You need for the programs to "see" nothing else except what lives in that directory. In other words, to them, whatever's in /home/joecool/projects/mylinux_5_08/ is "the root directory," and nothing-at-all outside of that directory even exists.

That's what chroot does.

When you use this command, you enter a "padded cell" that very-closely mimics exactly this situation. It allows you to reliably build-and-test software in an environment where inadvertant references to "anything outside of 'the box'" will cleanly result in an error... as they would in "real life."

OK, what would be the idea behind setting up DNS in /var/etc/chroot? What benefits would I have by having the zone files, DNS scripts, etc. in chroot?

That makes sense. I will need to recompile the kernel for one of my boxes as it has a "possible rootkit". I'm sure that I'll have questions as I build this kernel. I'm not ready to rebuild that box yet....that's another story.

As I asked another user, what would be the benefits of having DNS zone files in a padded area?

Thanks, all!

Tom D.

You either have or do not have a rootkit. I suggest you open a new thread in this forum, post the machines kernel and distribution version, the version of the application spitting out those warnings and its related loglines. I can't guarantee it but I'm pretty sure we can chalk whatever it is up as a false positive.

For anyone wondering, chroot is for "faking" switching your system root folder (AKA the "/" directory since that's where it's mounted). I think really its main purpose is for fixing up hosed systems - you can get into the drive and take a look at what's going wrong when the install is hosed enough that you can't get to a point where you can look at what's causing a given error. For me I've used it before back in the day, I hosed lilo (I think by saving the config, and then rebooting without running the lilo command) and used it to clean that up from a rescue disk.

As far as having a rootkit. . . well, I don't know a ton about rootkits, but I do know that they're not all that easy to get. It's not like a Windows virus really - it's something that usually either gets put in manually (either on purpose or by ill-placed trust in an installer or program) or exploits the vulnerability of another program to weasel its way into the system, and tricking the system to believing it's a system file (say, for example, the bash shell) and mimics the normal activity of said program to make the user also not notice its presence. Often login shells (bash, sh, etc) are used since some form of one of these is used by many users, or is run at system startup.

If you keep your system up-to-date with the latest patches and fixes, you should be fairly safe from others giving you a rootkit, since usually any vulnerability big enough to do such a thing is patched fairly quickly. The only other way for it to get on there depends on your security practices - so long as you practice a decent level of skepticism installing new things on your computer, and don't give others your password (or use one simple enough to guess or crack fairly easily) you should be pretty set.

If this is a server for your company, or is otherwise a very important box, you might want to set up some antirootkit and antivirus software still, just to be safe.