[RFC 0097] Unset read permission bit on /nix/store for other users

[L-as]

This is effectively equal to chmod o-r /nix/store.

Rendered

[L-as]

Fixed the parts about usage activity and added the drawback about tools needing more permissions.

[L-as]

I rewrote a lot of the text.

[edolstra]

I once tried removing read permission for the nixbld group (NixOS/nixpkgs@224d0d5) because it gives some of the advantages of build sandboxing without needing a mount namespace. Unfortunately it broke our VM tests but that should be fixable.

I'm not opposed to this proposal, but it does have a "security through obscurity" vibe. Currently, you shouldn't store secrets in the store, and because Unix software has not traditionally treated paths as secrets, it would be dangerous to rely on the secrecy of a path name for access control.

Note that currently any user that has access to the Nix daemon socket can discover all store paths by doing nix path-info --all, or discover "secret" parts of a closure through nix path-info -r (e.g. if the /run/current-system closure contains a configuration file with a password). Of course, ideally, properly sandboxed services shouldn't have access to the daemon socket. (And we should probably make the daemon only accessible by the users group by default...)

[L-as]

Thanks, the part about /run/current-system is expected though, since the expectation is that you'd be able to access every store path that is mentioned and its dependencies.

I get why you feel it has a "security through obscurity" vibe, since it does depend on hashes being secret.
The fundamental difference between a sandbox that uses something like the systemd-confinement.nix module and one that
just expects the store to be 1771, is that in the latter case, you can not trivially compute all store paths
that will be accessed, and that can be the source of unease, since it's harder to prove that some path isn't accessed
from inside the sandbox.

However, I think it's important to take into account that making this change won't worsen security, since
it doesn't force anyone to drop the use of alternative security measures. It is objectively a net improvement in
security, and essentially I think we need to consider whether it's worth the effort, which IMO is not a lot, since
it's just changing a few numbers, adding a few calls to chmod, and possibly some other small work.

[kevincox]

I think the key concern is: because Unix software has not traditionally treated paths as secrets.

If unix had always treated paths as a capability security mechanism kernel and software developers would design new interfaces and patches quite differently. With the current state of paths generally being considered mostly harmless to share with the entire system the risk of leaks is high, if not current interfaces then ones that may appear in the future. And without a good way to detect these leaks it is a very real threat to the security of sandboxes relying on "capability-based" /nix/store security.

Again, I don't think this is a blocker but I don't think this RFC is complete without thinking through the security risks that are present in this approach compared to options such as mounting only the needed paths that this RFC is suggesting could be replaced by this.

[L-as]

I made changes to the RFC about the drawbacks of depending on this for sandboxing and fixed some other things.

[spacekookie]

Opening this RFC for nominations. Can nominated shepherds please respond whether they accept?

[edolstra]

@kevincox @7c6f434c Are you interested in shepherding this RFC?

Also nominating myself.

[kevincox]

I can be a shepherd.

[Mic92]

We still need one more shepherd here.

[7c6f434c]

In particular, what is the actual change that happens.

Not much (which is good): stop enforcing permissions via Nix, and allow opting out from enforcing them via NixOS either, and do not make store group-readable by default when creating a store via Nix.

There are no real alternatives mentioned

The alternative to «why we are even bothering to enforce this so much? let's stop» is not stopping, I don't think we need more.

It doesn’t look like it has been thought a lot about what could break by doing this

Any changes of the defaults are for the store group users only, those are only supposed to be used during Nix builds.

Will I be able to ls -la /nix/store in the default configuration in the future?

In the near future yes, as there are options created but no change in the defaults; the longer term is future work for another RFC.

In what way does it provide a security risk?

This change itself, as mentioned in RFC, is not large enough for a useful change in security. There is just a piece of functionality in Nix which is too rigid and without clear enough purpose and stands in the way of some more complex experiments not intended to become mainline defaults.

[7c6f434c]

@L-as do you want to comment on questions by @Profpatsch or maybe update some writing to improve readability?

In particular, one thing maybe indeed we need to state clearly is that any changes in the name of implementing this RFC should create no new test failures (and if some VM tests somehow end up broken, the burden of fixing things or delaying the offending part is on the implementation PR)

@edolstra what is your current opinion on the current state of the RFC?

[L-as]

I feel that your response is good enough. Not breaking existing tests is I think not worth mentioning. Any change should of course not break tests, no matter what that change is.

[7c6f434c]

Not breaking existing tests is I think not worth mentioning. Any change should of course not break tests, no matter what that change is.

Well, there are cases where existing tests are declared reliant on obsolete assumptions and removed, or partially fixed with least important ones left to languish (roughly along the lines of RFC 0088). This is not what should happen here (I think the RFC as-is gives nothing to lighten the burden of justification of removing tests; it could explicitly add to it but I also hope this bar won't be cleared either way). Maybe the PR name should be «Allow unsetting…» now. I preserve my agreement to move to FCP with disposition to accept.

[edolstra]

@7c6f434c Yeah I'm 👍 on FCP/accept.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/rfc-0097-fcp-unset-read-permission-bit-on-nix-store-for-other-users/17351/1

[tomberek]

How does this interact with https://github.com/edolstra/nix/commits/acls?

[edolstra]

@tomberek It shouldn't have an effect, AFAIK ACL paths will work fine in a non-world-readable store.

[roberth]

I assume that at least some filesystems are vulnerable to timing attacks, probing paths with stat to build prefixes of subdirectory paths until the full path is recovered; using the x bit to recover r for all paths, including ones that aren't running.

Nonetheless, it's good for practical hermeticity.

[7c6f434c]

Yes, we hope that people either look at the list and start, like you, name extra leak vectors, or trust «insufficient for security» claim. It would be interesting to have a survey of path leak vectors, but this RFC is shorter than any useful survey like that…

[kevincox]

I agree. Any list we try to create in this RFC is likely incomplete so it is better to just state that as an assumption and accept it for the rationale here. If someone wants to prove that the list of leaks is empty (and expected to stay that way) they can propose a follow-up RFC to rely on that fact.

[roberth]

Why not restrict it to sensible or at least not terrible values? Seems quite feasible and the allow list could be extended if we discover a new use case.

[7c6f434c]

Because this «undesirable» includes the idea that most likely unfortunate mistakes are someon else's «just as planned» (I am not even sure 0000 is always useless; hmmm, now I am tempted to try once this is merged and trying is easy)

[asymmetric]

Has this ever been implemented? When I look at one of the lines mentioned in the RFC, it hasn't been changed since.

[roberth]

Sometimes I use tab completion on a store path; saves some mousing when I fail to copy a path completely, or sometimes typing three or four letters of the hash is easy enough.

[L-as]

I realised it wasn't actually that useful due to 7c6f434c's comments about being able to query all paths known from Hydra. Also, logs leak paths. Slightly better security, but only slightly.

[roberth]

Has this ever been implemented?

I don't think an RFC was strictly necessary for this (potential?) change. It'd be fine to introduce it as an opt-in hardening option and then perhaps create the RFC to call attention to it? Maybe I don't see the whole history though.

EDIT: simultaneous reply by L-as explains it.

[L-as]

Yeah looking back it didn't need an RFC, but if anyone implements this at least it's decided that it will be merged. It's a very low cost change.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/nixcon-governance-workshop/32705/9

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/musing-on-store-permissions/33695/2