You always hear about running services in “chroot” environment will help securing those services. Ever asked, how and why?
Lets understand how a “chrooted” environment for a service help admins to limit the scope of attack or control.
All those who had done RH333 of RHCSS knows that you had been taught to run BIND under /var/named/chroot/ and then all the configuration files of BIND are found under /var/named/chroot like the /var/named/chroot/etc/named.caching-nameserver.conf, then you have zones files also under the same directory tree, /var/named/chroot/var/named/forward.zone and so on.
We can store those files directly under / like /etc/named.caching-nameserver.conf and zones files under /var/named/forward.zone and still the BIND will work.
So why we store it under a more complicated or longer path. Reason is ONE – its more secure.
Lets see how?
One of our most important threat models is that of the hijacked daemon: if a malicious user manages to take over and effectively “become” a process on our system, he will assume the privileges on our system that that process has.
However, it’s equally important to mitigate the risk of potential daemon vulnerabilities, i.e., vulnerabilities that might be unknown to anyone but the “bad guys.” There are two primary means of doing so: running the process with as low a set of privileges as possible and running the process in a chroot jail.
Normally, a process can see and interact with as much of a system’s filesystem as the user account under which the process runs. Since most of the typical Linux host’s filesystem is world-readable, that amounts to a lot of play ground to them (good for bad guy, bad for good guy).
The chroot system call functionally transposes a process into a subset of the filesystem effectively redefining the / directory for that process to a small subdirectory under the real root.
NOW take a look at the attached picture for your reference, then read further.
For most processes and users, configuration files are found in /etc, commands are found in /usr/bin, and various “volatile” files such as logs are found in /var. However, we don’t want our DNS daemon, named, to “see” the entire filesystem, so we run it chrooted to /var/named.
Thus, from named’s perspective
/var/named/etc is /etc,
/var/named/usr/bin is /usr/bin,
/var/named/var appears as /var.
This isn’t a foolproof method of containment, but it helps.
So in this case if my BIND got compromised the attacker will be able to see only the subset of the filesystem, thus I save my original /etc/ and other original locations like /usr etc to get exposed to him.
chroot is not an absolute control: a chroot jail can be subverted via techniques such as using a hard link that points outside of the chroot jail or by using mknod to access the hard disk directly. However, since none of these techniques is very easy to execute without root privileges, chroot is a useful tool for hindering an
attacker who has not yet achieved root privileges.
Now I hope you understand the purpose of running services in chroot environment.