6 ms·

Wait, are there people who really think chroot offers security? I mean, at least read the man page before making assumptions? http://man7.org/linux/man-pages/

Wait, are there people who really think chroot offers security? I mean, at least read the man page before making assumptions? http://man7.org/linux/man-pages/man2/chroot.2.html http://man7.org/linux/man-pages/man2/chroot.2.html > This call changes an ingredient in the pathname resolution process and does nothing else. > It is not intended to be used for any kind of security purpose, neither to fully sandbox a process nor to restrict filesystem system calls. > In particular, the superuser can escape from a "chroot jail" by doing: mkdir foo; chroot foo; cd .. > However, if a folder is moved out of the chroot directory, an attacker can exploit that to get out of the chroot directory as well. The easiest way to do that is to chdir(2) to the to-be-moved directory, wait for it to be moved out, then open a path like ../../../etc/passwd. EDIT: Fixed link to a more up-to-date man page. They explicitly call this out as not being a security feature in the updated man page.

pjmlp 7y ago
The same that keep writing security critical code in C, without any kind of static analysers and code fuzzing as part of their build.
johnchristopher 7y ago
But isn't chroot typically used by normal users anyway ?
- cyphar 7y ago
  chroot(2) requires privileges (CAP_SYS_CHROOT on Linux). Otherwise you could trick setuid binaries into doing some pretty bad things.
- antpls 7y ago
  Maybe were you thinking about fakeroot ? "fakeroot runs a command in an environment wherein it appears to have root privileges for file manipulation. This is useful for allowing users to create archives (tar, ar, .deb etc.) with files in them with root permissions/ownership." https://man.cx/fakeroot(1) https://man.cx/fakeroot(1)
mercora 7y ago
i often wondered how exactly one can escape from a chroot but never really tried or read that man page until now. I tried the above and it did not work as described. I tried both changing to the parent directory directly after chroot and chrooting inside the chroot and doing it then. Edit: Now that i really read that page i realized 2 things, first this page is about the syscall and not the command and second it says the syscall itself does not change the current directory to the provided path. I guess the chroot command does just that and this is why it did not work as described. The example given literally still does not work as advertised.
- cyphar 7y ago
  This is the more correct escape (EDIT: and works today): fd = open(".", O_PATH); chroot("foo"); fchdir(fd); // escaped to "." and chroot no longer blocks ".." past "/" chdir("../../../../"); // go to real "/" chroot("."); // broken out The "chdir .." trick used to work a long time ago. The man page probably hasn't been updated in ~20 years.
  - mercora 7y ago
    to be clear, neither will work on a reasonably modern system?
    - cyphar 7y ago
      No, the above escape will definitely work on a modern system.
      - mercora 7y ago
        Thanks that was quite helpful.
  - Vogtinator 7y ago
    Not really an issue. If there's an fd pointing outside of the chroot, of course it's possible to do stuff outside of it. That with a path FD a total escape is possible isn't that obvious, but not unexpected.
fragmede 7y ago
On BSD, jail() is used as an extension to chroot() specifically to improve the security for externally accessible services. Breaking into ftpd (jail() has been around that long) would only give an attacker access to the configured subdirectory, and not /etc/passwd and shadow. The reason chroot() isn't a security feature is because Linux only half copied/re-implemented that feature. Properly implemented, it's a decent idea.
- smitty1e 7y ago
  I was left to wonder if chroot along with a well-crafted SELinux policy might get one closer to security nirvana.
viraptor 7y ago
> Wait, are there people who really think chroot offers security? The real answer is that this is a bad question. chroot disables some attack vectors. For example a path traversal vulnerability in a reverse http proxy is almost entirely mitigated by putting the proxy in a chroot. There may be extra details like access to cache or configuration, but chroot largely prevents harm from that issue. It does little against people with local access. So basically - it's more nuanced. "X offers security" is a trap.

pjmlp 7y ago

The same that keep writing security critical code in C, without any kind of static analysers and code fuzzing as part of their build.

johnchristopher 7y ago

But isn't chroot typically used by normal users anyway ?

cyphar 7y ago
chroot(2) requires privileges (CAP_SYS_CHROOT on Linux). Otherwise you could trick setuid binaries into doing some pretty bad things.
antpls 7y ago
Maybe were you thinking about fakeroot ? "fakeroot runs a command in an environment wherein it appears to have root privileges for file manipulation. This is useful for allowing users to create archives (tar, ar, .deb etc.) with files in them with root permissions/ownership." https://man.cx/fakeroot(1) https://man.cx/fakeroot(1)

mercora 7y ago

i often wondered how exactly one can escape from a chroot but never really tried or read that man page until now. I tried the above and it did not work as described. I tried both changing to the parent directory directly after chroot and chrooting inside the chroot and doing it then. Edit: Now that i really read that page i realized 2 things, first this page is about the syscall and not the command and second it says the syscall itself does not change the current directory to the provided path. I guess the chroot command does just that and this is why it did not work as described. The example given literally still does not work as advertised.

cyphar 7y ago
This is the more correct escape (EDIT: and works today): fd = open(".", O_PATH); chroot("foo"); fchdir(fd); // escaped to "." and chroot no longer blocks ".." past "/" chdir("../../../../"); // go to real "/" chroot("."); // broken out The "chdir .." trick used to work a long time ago. The man page probably hasn't been updated in ~20 years.
- mercora 7y ago
  to be clear, neither will work on a reasonably modern system?
  - cyphar 7y ago
    No, the above escape will definitely work on a modern system.
    - mercora 7y ago
      Thanks that was quite helpful.
- Vogtinator 7y ago
  Not really an issue. If there's an fd pointing outside of the chroot, of course it's possible to do stuff outside of it. That with a path FD a total escape is possible isn't that obvious, but not unexpected.

fragmede 7y ago

On BSD, jail() is used as an extension to chroot() specifically to improve the security for externally accessible services. Breaking into ftpd (jail() has been around that long) would only give an attacker access to the configured subdirectory, and not /etc/passwd and shadow. The reason chroot() isn't a security feature is because Linux only half copied/re-implemented that feature. Properly implemented, it's a decent idea.

smitty1e 7y ago
I was left to wonder if chroot along with a well-crafted SELinux policy might get one closer to security nirvana.

viraptor 7y ago

> Wait, are there people who really think chroot offers security? The real answer is that this is a bad question. chroot disables some attack vectors. For example a path traversal vulnerability in a reverse http proxy is almost entirely mitigated by putting the proxy in a chroot. There may be extra details like access to cache or configuration, but chroot largely prevents harm from that issue. It does little against people with local access. So basically - it's more nuanced. "X offers security" is a trap.