On 10/03/2021 21:59, Casey Schaufler wrote:

On 3/10/2021 10:17 AM, Mickaël Salaün wrote:

quoted

On 10/03/2021 18:22, Casey Schaufler wrote:

quoted

On 3/10/2021 8:09 AM, Mickaël Salaün wrote:

quoted

Hi,

The chroot system call is currently limited to be used by processes with
the CAP_SYS_CHROOT capability.  This protects against malicious
procesess willing to trick SUID-like binaries.  The following patch
allows unprivileged users to safely use chroot(2).

Mount namespaces have pretty well obsoleted chroot(). CAP_SYS_CHROOT is
one of the few fine grained capabilities. We're still finding edge cases
(e.g. ptrace) where no_new_privs is imperfect. I doesn't seem that there
is a compelling reason to remove the privilege requirement on chroot().

What is the link between chroot and ptrace?

The possibility of sophisticated interactions with no_new_privs.

Would you mind giving some practical examples?

quoted

What is interesting with CAP_SYS_CHROOT?

CAP_SYS_CHROOT is specific to chroot. It doesn't give you privilege
beyond what you expect, unlike CAP_CHOWN or CAP_SYS_ADMIN. Making chroot
unprivileged is silly when it's possibly the best example of how the
capability mechanism is supposed to work.

Why would it be silly to make the use of this feature safe for any
processes instead of giving the right (with CAP_SYS_CHROOT) to some
processes to use it unsafely?

quoted

quoted

quoted

This patch is a follow-up of a previous one sent by Andy Lutomirski some
time ago:
https://lore.kernel.org/lkml/0e2f0f54e19bff53a3739ecfddb4ffa9a6dbde4d.1327858005.git.luto@amacapital.net/ (local)

This patch can be applied on top of v5.12-rc2 .  I would really
appreciate constructive reviews.

Regards,

Mickaël Salaün (1):
  fs: Allow no_new_privs tasks to call chroot(2)

 fs/open.c | 64 ++++++++++++++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 61 insertions(+), 3 deletions(-)


base-commit: a38fd8748464831584a19438cbb3082b5a2dab15