3 ms·

My reaction: Why? Oh that makes sense. Wait! Abysmal Security Nightmare! Nooooooo Don't do that, Pleeeeeeease. One of the main reason is that: 1. It increase

My reaction: Why? Oh that makes sense. Wait! Abysmal Security Nightmare! Nooooooo Don't do that, Pleeeeeeease. One of the main reason is that: 1. It increases the attack surface. 2. At least currently PR_SET_NO_NEW_PRIVS must not be relied on to be perfect for security. Must use cases use it as an additional security layer, but the chroot patch uses it as a fundamental required to be perfect building block. 3. As far as I can tell the benefit it gives is not worth the increased attack surface even if PR_SET_NO_NEW_PRIVS would work perfectly. But I might be wrong. Honestly the additional constraints it puts on chroot are good and I believe should be fulfilled for must use cases of chroot. So I think best would be either a "CAP_RESTRICTED_CHROOT" capability which allows chroot but only under given circumstances or a prctrl which "degrades" CAP_SYS_CHROOT to only work under given circumstances. In both cases programs which drop all CAP's they don't need would not be affected by this feature made for programs which use chroot. But in the current design the sandbox of ALL!!!! sandboxed programs which drop the CAP_SYS_CHROOT capability is weakened. Which IMHO is unreasonable.

0xbadcafebee 6y ago
The security concerns are overblown because this assumes everyone will start using chroot for everything, which isn't the case. There are plenty of use cases where you intentionally sacrifice security for usability. 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.
- dathinab 6y ago
  > 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).

0xbadcafebee 6y ago

The security concerns are overblown because this assumes everyone will start using chroot for everything, which isn't the case. There are plenty of use cases where you intentionally sacrifice security for usability. 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.

dathinab 6y ago
> 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).