[thenoblesunfish]

For those, like me, lacking context, what are the implications of this?

[phicoh]

The key feature of chroot is that you can provide a process with a completely different filesystem view. You can leave stuff out that exist in the standard view, or change things. Change the contents of system directories.

The problem with traditional chroot is that you can typically import setuid applications in this new space which can get confused, for example by a new /etc/passwd file. For this reason, chroot can be used only by root.

The advantage of such a NO_NEW_PRIVS flag is that this kind of abuse of setuid applications is not possible.

This should make it safe to allow ordinary users to use chroot.

[codetrotter]

chroot is a system call that assigns a limited view of the file system to a process. In particular it makes it so that the specific directory will appear as the top level directory to the process.

Some people like to run for example FTP servers in a chroot so that users have access only to a specific directory and its subdirectories, rather than being able to browse other files on the system.

FreeBSD also has a technology called jails which is what you’d rather use for containerization.

Anyway, previously you had to be root (the Unix admin user) in order to use chroot. FreeBSD now implementing unprivileged chroot means that regular users are able to run processes in chroot as well.

So for example if you were a regular user on a system, you can now create a sub directory in your home directory and run an FTP demon chrooted to that directory and bound to an unprivileged port, and then you can give someone else FTP access to that directory without them being able to see the other files in your home directory, keeping your private data private from them.

[tyingq]

chroot existed, but could only be run as the root user. It was that way to prevent things like this (old actual exploit for Ultrix):

  $ mkdir /tmp/etc
  $ echo root::0:0::/:/bin/sh > /tmp/etc/passwd
  $ mkdir /tmp/bin
  $ cp /bin/sh /tmp/bin/sh
  $ cp /bin/chmod /tmp/bin/chmod
  $ chroot /tmp /bin/login
  # whoami
  root
  # chmod 4700 /bin/sh
  now, log out of the chroot and use your newly minted setuid shell

Since they now have the "NO_NEW_PRIVS" protection, they can let regular users safely use chroot.

[jsiepkes]

You can for example run a build in a chroot as a unprivileged user.