> What's the danger here, that a program will create a chroot and that an attacker will then break out of it? So we're back to where we are now, which is not using chroots.
Not quite right
Currently chroot needs privilegs, so a program which runs sandboxed will not ever be able to chroot and will be stuck in the sandbox.
But with that patch a sandboxed program could start a chroot and then use the chroot environment to weaken or escape the sandbox it is in.
So as far as I understand this change will actively weaken the security of all sandboxes which dropped the privilege to do chroot (or never had it), which are most of them.
The main way you could take advantage of it would be in combination with a RCE vulnerability in a software which runs itself in a sandbox.
> which is not using chroots.
Currently we can make sure chroot is not used by making sure no SYS_CAP_CHROOT or similar capability is given. With the patch it will be impossible to make sure chroot is not used!
Because anyone anywhere with anyuser will be able to use it.
Which would be fine with the constraints the patch adds to chroot, but the problem is that it's known that one of the main constraints it adds doesn't work perfectly/has security gaps.
> intentionally sacrifice security for usability.
The problem is that with the patch everyone using various non-vm sandboxing mechanisms will be forced to sacrifice security for usability, it's not a "opt-in for this programs which do care".
Which is why I think putting this behind another capability or similar would be best (one a unprivileged user can have).
Not quite right
Currently chroot needs privilegs, so a program which runs sandboxed will not ever be able to chroot and will be stuck in the sandbox.
But with that patch a sandboxed program could start a chroot and then use the chroot environment to weaken or escape the sandbox it is in.
So as far as I understand this change will actively weaken the security of all sandboxes which dropped the privilege to do chroot (or never had it), which are most of them.
The main way you could take advantage of it would be in combination with a RCE vulnerability in a software which runs itself in a sandbox.
> which is not using chroots.
Currently we can make sure chroot is not used by making sure no SYS_CAP_CHROOT or similar capability is given. With the patch it will be impossible to make sure chroot is not used!
Because anyone anywhere with anyuser will be able to use it.
Which would be fine with the constraints the patch adds to chroot, but the problem is that it's known that one of the main constraints it adds doesn't work perfectly/has security gaps.
> intentionally sacrifice security for usability.
The problem is that with the patch everyone using various non-vm sandboxing mechanisms will be forced to sacrifice security for usability, it's not a "opt-in for this programs which do care".
Which is why I think putting this behind another capability or similar would be best (one a unprivileged user can have).