`sandbox` setting is a horrifying field of landmines of implementation complexity #936

New issue

Open

opened 2025-07-28 02:20:10 +00:00 by jade · 0 comments

jade commented

2025-07-28 02:20:10 +00:00

Owner

For starters, useChroot is an erroneous name in local-derivation-goal.cc. chroot is never used on darwin but useChroot is still applicable there. And there's a whole bunch of semantics which are confusing at best and broken at worst.

Plus, it's unclear how to correctly experimentally use a new minimal sandbox on Darwin (#756, #386, etc). Such a policy would specifically just ban broken homebrew interactions and be applied to "no-sandbox" derivations. How would such a thing be opted out during a stabilization period? I don't know!!

The sandbox has so many confusing knobs which interact badly together and was more congealed than designed. Some of this complexity is inherent:

Opt out of some amount of the sandbox is desirable on a per-derivation level, and is a prerequisite to getting anywhere with stabilizing default-on sandbox on macOS
The above is true on both macOS and Linux
macOS cannot absolutely sandbox everything under the sun with any sandbox that isn't using EndpointSecurity.framework or Virtualization crimes due to #756, but there is additional nixpkgs work to bring "sandbox cant be globally enabled by default" to "sandbox can be used by default"
There is some degree to which some of a sandbox is somewhat necessary for security (setuid files, etc) even though the primary purpose of the sandbox is packager self-own protection
FODs need slightly less sandbox so they can touch the network
Our config system is not very good (and fixing it is a largeish project)

Some of it is, however, self-owns:

There's knobs like __darwinAllowLocalNetworking which aren't documented or in any comprehensible schema: #217
sandbox = relaxed apparently means more than just "on by default with opt-out allowed"???!
Inside libstore, the intended sandbox state is a mishmash of various boolean variables that are very confusing.
Admins may want to specify which things they are okay with disabling on a case by case basis
There's no signalling to the scheduler as to what the allowable sandbox states are for remote builds (#604)

EsperLily says on Matrix:

yeah i have no idea who thought it was a good idea to say "relaxed means don't sandbox the FODs" since what it should mean is "enable the escape hatches like __sandboxProfile and __noChroot so derivations can opt in to weakening protections"

I think that the way forward on this is to come up with a coherent idea of what the sandbox is for and what states it should be in, in addition to what the platform specific needs are. That can then be used to redesign the code so it is possible to understand and so that it can be documented #121.

For starters, `useChroot` is an erroneous name in `local-derivation-goal.cc`. chroot is never used on darwin but `useChroot` is still applicable there. And there's a whole bunch of semantics which are confusing at best and broken at worst. Plus, it's unclear how to correctly experimentally use a new minimal sandbox on Darwin (https://git.lix.systems/lix-project/lix/issues/756, https://git.lix.systems/lix-project/lix/issues/386, etc). Such a policy would specifically just ban broken homebrew interactions and be applied to "no-sandbox" derivations. How would such a thing be opted out during a stabilization period? I don't know!! The sandbox has so many confusing knobs which interact badly together and was more congealed than designed. Some of this complexity is inherent: - Opt out of some amount of the sandbox is desirable on a per-derivation level, and is a prerequisite to getting anywhere with stabilizing default-on sandbox on macOS - The above is true on both macOS and Linux - macOS cannot absolutely sandbox everything under the sun with any sandbox that isn't using EndpointSecurity.framework or Virtualization crimes due to https://git.lix.systems/lix-project/lix/issues/756, but there is additional nixpkgs work to bring "sandbox cant be globally enabled by default" to "sandbox can be used by default" - There is some degree to which *some* of a sandbox is somewhat necessary for security (setuid files, etc) even though the primary purpose of the sandbox is packager self-own protection - FODs need slightly less sandbox so they can touch the network - Our config system is not very good (and fixing it is a largeish project) Some of it is, however, self-owns: - There's knobs like `__darwinAllowLocalNetworking` which aren't documented or in any comprehensible schema: https://git.lix.systems/lix-project/lix/issues/217 - `sandbox = relaxed` apparently means more than just "on by default with opt-out allowed"???! - Inside libstore, the intended sandbox state is a mishmash of various boolean variables that are very confusing. - Admins may want to specify which things they are okay with disabling on a case by case basis - There's no signalling to the scheduler as to what the allowable sandbox states are for remote builds (https://git.lix.systems/lix-project/lix/issues/604) [EsperLily says on Matrix](https://matrix.to/#/!lymvtcwDJ7ZA9Npq:lix.systems/$j4_cfVZB_iWhP0YhfuuX8VT0Z2bZ7bit843tbvtuLZ8?via=lix.systems&via=matrix.org&via=catgirl.cloud): > yeah i have no idea who thought it was a good idea to say "relaxed means don't sandbox the FODs" since what it should mean is "enable the escape hatches like __sandboxProfile and __noChroot so derivations can opt in to weakening protections" I think that the way forward on this is to come up with a coherent idea of what the sandbox is for and what states it should be in, in addition to what the platform specific needs are. That can then be used to redesign the code so it is possible to understand and so that it can be documented https://git.lix.systems/lix-project/lix/issues/121.