Chroot notes

From Helpful
(Redirected from Chroot)
Jump to: navigation, search
This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)
These are primarily notes
It won't be complete in any sense.
It exists to contain fragments of useful information.

See also SSH_-_SSH_jails

tl;dr:

  • chroot changes the filesystem's apparent root
  • chroot is mainly a development tool
  • chroot is not a security tool against those with ill will, yet certainly better than nothing against side effects of bugs


What

chroot changes a process's apparent filesystem-root directory to a given path, after which path resolution only resolves within that subtree.

It does not affect open file descriptors (files, pipes, sockets, etc.), it does not affect hardlinks to outside, and there is often little restriction imposed on (non-path) system calls.


As such, chroot is mostly useful for things that themselves want to run in an isolated environment.

And less useful against people trying to break out of that environment. (It might work against the unwashed masses, but not against hackers. In various chroot implementations (yes, details vary), if a user in the jailed environment has the ability to chroot, they can break out of it) That said, there are some variations/extensions of the chroot idea that are security-oriented.


Example uses:

  • The best example of its use is testing/debugging, for example testing some newly compiled libraries without installing them system-wide.
  • Different OS environment, e.g. from the one you have booted from
You could boot from a liveCD to then chroot to your installed OS (for example to fix it, in particular if what is wrong is its ability to boot).
One way of installing gentoo is taking over a disk this way [1]
  • Jailed daemon
For example, you could chroot a web server or file server (with the content they serve) so that if someone finds an exploit that gives them read access to the filesystem (and not security elevation), this still only means 'any file inside that jail'.
This is mostly so that the filesystem accesses that are implied by web accesses or the scripts will not go outside the jail. When exploits allow remote code execution, a jail may only be an additional hurdle.
  • Jailed login
Usually to the user's home directory (because that's easier to organize)
An actually restrictive chroot jail is surprisingly hard to set up, if only because it's too easy to see chroot as ad trust it's restrictive -- but chroot is not a security tool. Implementations vary, so all chroot is guaranteed to do is change the way typical path resolution works.
For hackers this may be a temporary hurdle to further access (though further access may amount to nothing more than "the full filesystem as the user would see without chroot, and nothing more", which is no less secure than not using chroot -- but also no better).


Details

jail account / working environment

After you chroot, you need an environment that works.


To run anything nontrivial, and in particular daemons, you'll probably need /usr, /bin, /etc with things like resolv.conf, and a /lib with dozens of libraries, and quite possibly bind-mounted /dev, sys, and /tmp, mount /proc, and whatnot. You'll pretty much find out. At some point point virtualization becomes the easier option.


In one case, I wanted an account to support making SSH tunnels. This means it's fine if the account itself can do essentially nothing.

For even just
bash
and
ls
you'll probably need most of the above-mentioned directory structure and a dozen libraries present. (verify)

In general, restricted accounts are best kept as minimal as possible, largely because various not-yet-particularly-fancy commands do things that are not restricted by chroot, and in some cases they can be used to break out of the jail.


There are utilities that help you create such a chroot environment from scratch, such as jk_init.


On links

Hardlinks work fine, because they are not links, they point directly to an inode. They're only called hardlinks to point out multiple file entries point to the same inode. Keep in mind that wrong permissions inside the jail will let users clobber files (that you probably consider as really being) outside the jail.

Symlinks will be resolved within the chroot, so most won't work as you probably intend. Some issues this introduces can be worked around with bind-mounting.


See also