
Is chroot a security feature? - katzeilla
https://access.redhat.com/blogs/766093/posts/1975883
======
jedberg
So the basic argument is that if you can become root you can escape the jail.
So if you have access to a vulnerable program you can become root and escape.

This might be true, but it's still a good practice for defense in depth and
_does_ offer a security benefit. It helps protect you when there are non-root
flaws in software. For example a web server that lets clients get to
directories with '..' notation. Even with that compromised software, they
wouldn't be able to get to /etc or /home if they are in a proper chroot.

~~~
cyphar
There are several more ways you can escape chroot(2) through VFS attacks
(nd->root protections are very minimal).

However, the more important point should be that there is a similar syscall
which doesn't have the same flaws as chroot(2) because the protection is based
on mount namespaces -- pivot_root(2). The problem with chroot(2) is that the
mountpoints above "/" are still accessible by the VFS internally.
pivot_root(2) gets rid of the mounts and so VFS won't reach them anymore.

~~~
e12e
I see there's a similar wrapper binary - but apparently you need to both pivot
and chroot?

[https://linux.die.net/man/8/pivot_root](https://linux.die.net/man/8/pivot_root)

~~~
cyphar
The man page is out-dated (and Michael Kerrisk has posted on LKML that he
plans to rewrite it). You don't need to do chroot("/") -- that operation makes
no sense because there is no semantic difference between chroot("/") and doing
nothing (even the kernel can't distinguish the two cases).

What you need to do is the following:

    
    
      mkdir newroot/oldroot
      mount --rbind newroot newroot # if newroot isn't a mountpoint
      pivot_root newroot oldroot
      cd /
      # and now get rid of the old root's mounts
      mount --make-rslave oldroot
      umount -lR oldroot
    

At least, approximately. There is a more clever way to do it by doing
"pivot_root . ."[1] but posting that here just makes it more confusing. As a
complete aside, this is what container runtimes do when switching to the
container rootfs -- and is the main reason why --no-pivot-root is _incredibly_
insecure (because it uses chroot).

[1]:
[https://github.com/opencontainers/runc/blob/v1.0.0-rc8/libco...](https://github.com/opencontainers/runc/blob/v1.0.0-rc8/libcontainer/rootfs_linux.go#L700-L757)

------
asadjb
Many comments in this thread are bashing the article for saying that _chroot_
is useless or shouldn't be used. However the article itself takes a more
nuanced approach.

From the conclusion:

>It is not hard to consider the chroot() system call a security feature. In
theory, it sounds great, but if you really take the time to understand what is
going on, it is not really a security feature, it is closer to what we would
call a hardening feature. It might slow down an attacker, but in most
situations it is not going to stop them. We are dealing with a situation where
calling this a security feature is likely more damaging than not because it
creates a false sense of security. It is human nature to let our guard down if
we believe we are safe. Using chroot is no safer than not using a chroot. You
would be far better off investing your resources into a custom SELinux policy
and ensuring your system is properly hardened. Good security has no shortcuts.

I think the point is that you shouldn't consider _chroot_ the only or best
option for securing your system. It's just one tool in the toolbox and needs
to be understood properly and not trusted blindly as the solution for all
security vulnerabilities.

~~~
xorcist
> the article itself takes a more nuanced approach

Let's see what the article says:

> Using chroot is no safer than not using a chroot.

Not very nuanced in my opinion.

Few people argue we should replace chroot calls with SELinux these days. The
article is interesting from a historical perspective but clearly needs a
"(2013)" context.

~~~
effie
The article is inconsistent about chroot, but regarding SELinux, it has a
point. SELinux looks like an old and solid mechanism to isolate processes from
each other. Nowadays we have lxc to do that as well, but it does not make
SELinux useless.

------
phkamp
How can this even be a question 20 years after FreeBSD Jails ?

[https://papers.freebsd.org/2000/phk-
jails/](https://papers.freebsd.org/2000/phk-jails/)

------
tptacek
_Nothing would prevent root from just modifying the process memory directly to
change the chroot() location back to '/'._

Huh? The chroot root directory is stored in the kernel, in the task structure,
not in process memory. For that matter, every process can modify its own
memory, not just root.

It is in fact a bug, or at least a design flaw, that root can break out of
chroot. For instance, the Unix filesystem, historically, at the VFS layer (or
whatever Linux calls it), has a simple tree structure, Unix allows nested
chroots, and chroot(2) doesn't chdir(2) you into the new root. If you chroot
to a subdirectory of your root and don't chdir into it, Unix is too dumb to
know you're "above" your current root.

~~~
pcwalton
Yeah, I assume the author meant to write "kernel memory" there. I think what
they were getting at is that root could theoretically mknod a /dev/mem device
inside the chroot jail and then modify kernel data structures through it. Or
root could issue an init_module(2) syscall to install a kernel module that
breaks out of the jail.

~~~
tptacek
Right, but on modern Linux, you're a seccomp call away from blocking those
vectors. The inadequacy of chroot was a more coherent story to tell 10 years
ago, but now, it seems silly to suggest that chroot isn't a security feature;
it is, it's just part of an ensemble of related features that need to be
deployed in concert.

~~~
darren0
This isn't true. For example containers use pivot_root instead of chroot or
MS_MOVE because there are specific security issues with keeping a reference to
the parents mount table.

If you care about security there is no reason to use chroot on Linux, there
are better approaches.

~~~
tptacek
Is there a vulnerability pivot_root breaks that applies to unprivileged users?
I wrote quickly and imprecisely and agree that in general chroot isn't
especially helpful against the superuser (for a bunch of reasons).

------
tus88
I can't believe this guy works for redhat.

> you are no safer inside a chroot than relying on system permissions to keep
> a user in check

But how may systems lock down every executable in /bin and /usr/bin?

Chroot is about denying an attacker a hackers toolkit when they get access.

It's not just about hacking the current system, but the network.

No gcc? No netcat or ssh or netstat? Or even bash? The first thing hackers
look for is what tools are available on the system, and denying them any is a
form of security. This had been known for _decades_.

------
rascul
chroot() started out as just a chdir() operating on root directory instead of
current directory.

[https://utcc.utoronto.ca/~cks/space/blog/unix/ChrootHistory](https://utcc.utoronto.ca/~cks/space/blog/unix/ChrootHistory)

------
xorcist
> Using chroot is no safer than not using a chroot.

This is terrible advice. Software should drop privileges early, and chroot is
as important as it has ever been. Other useful things include seccomp-bpf and
pledge.

OpenSSH and Postfix is absolutely safer because they drop privileges after
reading configuration and binding ports.

~~~
cyphar
The problem is that there are many well-known ways to get around chroot(2)
(which don't require privileges). This includes /proc-related escapes as well
as more general VFS attacks.

Really, tools should have switched to using pivot_root(2) a decade ago instead
of continuing to use chroot(2). Unfortunately this article completely ignores
the existence of pivot_root(2) -- which makes it read as though they are
trying to convince people to stop using root-switching a security feature
(which is definitely bad advice).

~~~
bluecmd
I've never seen this advice, would you mind elaborating or citing a more
elaborate source?

Since pivot_root requires the old root to be a child of the new root,
traversing back to the full system seems trivial. Actually, I don't see why
this syscall isn't worse than chroot due to this.

~~~
cyphar
> Actually, I don't see why this syscall isn't worse than chroot due to this.

You can (and everyone does) unmount the oldroot. Then in your mount namespace
the old root is not reachable through the VFS alone. You need to make use of
procfs's magic-links or other such tricks.

------
nickcw
chroot is a layer in the security onion.

Like every other layer it adds security but isn't perfect. Security will never
be 100%. If you want more security, then likely you want another layer in the
onion.

~~~
cyphar
Yes, but pivot_root(2) is a far more robust and secure way of doing the same
thing. There really is no reason to use chroot(2) instead of pivot_root(2)
(unless you are running code on initramfs -- and even then you should do the
tmpfs trick that everyone else uses).

~~~
weinzierl
> There really is no reason to use chroot(2)

You mentioned intiramfs yourself, but there are other uses of chroot where
security doesn't play a role. Deterministic build environments are an example.

------
johnklos
This article is entirely FUD.

chroots are useful when running software which we don't necessarily know is
secure. It reduces the impact of flaws in software we don't control.

The point is taken that proper permissions would effectively be no different
from a chroot, but this is disingenuous, particularly if considered with the
statement, "but note that setting up a chroot can be far more complex than
configuring a system".

This is pure hyperbole and deserves to be called ridiculous. Compare
configuring a chroot, which is easy, straightforward, common and well
understood with configuring a user to exclude access to everything in a system
except what the chroot would allow, and try to reasonably suggest that the
chroot is more complex.

You can do lots with login.conf, but hang on - systemd does things
differently. So instead of decades of well understood chroot history, now you
have to figure out how login.conf works with systemd. Then you have to figure
out what version of systemd it is, and whether behavior has changed, and
whether documentation even matches your system's systemd...

In other words, this whole article has no purpose aside from trying to
disparage chroot without any actual, meaningful information.

So how does Red Hat benefit? Of course Red Hat doesn't want people running
lots of processes in a single installation. They want people to run a ton of
system images in huge VM environments and have people become accustomed to
needing lots of resources to do the simplest of things. This makes paying Red
Hat for "support" easier to swallow. One instance with lots of tasks?
Insecure, according to them. A separate VM for each program? Much better, if
you believe them :P

~~~
greedo
Nonsense. Red Hat supports containerization in more ways than I can count.
Also, most businesses running RHEL in a VM environment (like ESX) are using
per host licensing where you can run an unlimited number of RHEL VMs on a
single physical host.

------
pmorici
"it is not really a security feature, it is closer to what we would call a
hardening feature. It might slow down an attacker, but in most situations it
is not going to stop them."

Does his argument boil down to this? If so this seems like a silly argument
over semantics. Is there anything in existence that can "stop" an attack?

------
z3t4
If you forget to setuid after chroot it's much less secure :P I have a free
online service where anyone can run any code on a fairly powerful dedicated
server. And it uses chroot, setuid, iptables and Apparmor. It has not yet got
pwned, knock on wood.

------
gpvos
I don't understand why the article recommends pivot_root. Its man page says
that it _may or may not change the current root and the current working
directory of any processes or threads which use the old root directory,_ which
means it can change the root _of other processes!_ Also, it says that its
typical use is for switching from the boot RAM disk to the actual root
filesystem. This is an entirely different use case than chroot, and doesn't
seem to have any security benefits either.

------
takeda
That's why FreeBSD created jails, the idea was to actually make a secure
chroot.

The original purpose of chroot was nothing more than control where an
installer installs its files.

------
agapon
IMO, chroot is good for changing root :) but not for security. Example: zfs
clone your current root, chroot there, experiment / test /etc.

------
loeg
> Putting a regular user in a chroot() will prevent them from having access to
> the rest of the system. This means using a chroot is not less secure, but it
> is not more secure either. If you have proper permissions configured on your
> system, you are no safer inside a chroot than relying on system permissions
> to keep a user in check

Lol. So, all security mitigations ever are pointless.

------
aloknnikhil
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.

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

~~~
antpls
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\))

------
Tepix
If an unprivileged process can gain super user privileges, you have a problem.
This applies to both situations with chroot and those without chroot.

------
darren0
To understand just how trivial it is to escape a chroot with root, just run
"nsenter -m -t $$" and your out.

~~~
otterley
That doesn't work for an unprivileged user, does it?

------
naranha
Is systemd-nspawn more secure?

~~~
chupasaurus
cyphar made a lot of comments here on usage of mount namespaces and
pivot_root.

------
test124
Not really.

