Allow unprivileged processes to chroot() themselves, under the
following conditions:
- The caller must have set NO_NEW_PRIVS to prevent him from
invoking setuid/setgid/setcap executables in the chroot that
could be tricked into opening files from the chroot.
- The fs_struct must not be shared to prevent the caller from
chrooting another process that does not have NO_NEW_PRIVS
active.
- chroot() is sometimes (mis-)used for sandboxing purposes.
To prevent a simple chroot breakout using e.g. the
double-chroot trick (chdir("/"), chroot("/foo"),
chroot("../../../../../../../../")), require the process to
be un-chrooted before performing chroot()
Signed-off-by: Jann Horn <jann@xxxxxxxxx>
---
fs/open.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/fs/open.c b/fs/open.c
index b6f1e96..a07026b 100644
--- a/fs/open.c
+++ b/fs/open.c
@@ -481,7 +481,9 @@ retry:
goto dput_and_out;
error = -EPERM;
- if (!ns_capable(current_user_ns(), CAP_SYS_CHROOT))
+ if ((current->fs->users != 1 || !task_no_new_privs(current)
+ || current_chrooted())
+ && !ns_capable(current_user_ns(), CAP_SYS_CHROOT))
goto dput_and_out;
error = security_path_chroot(&path);
if (error)
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
