doc: rewrite the multi-user documentation to actually talk about security

It's in the security section, and it was totally outdated anyway.

I took the opportunity to write down the stuff we already believed.

Change-Id: I73e62ae85a82dad13ef846e31f377c3efce13cb0

doc/manual/src/installation/multi-user.md

@@ -1,32 +1,121 @@
 # Multi-User Mode
 
-To allow a Nix store to be shared safely among multiple users, it is
+To allow a Nix store to be shared safely among multiple users, it is important that users cannot meaningfully influence the execution of derivation builds such that they could inject malicious code into them without changing their (either input- or output- addressed) hash.
-important that users are not able to run builders that modify the Nix
+If they could do so, they could install a Trojan horse in some package and compromise the accounts of other users.
-store or database in arbitrary ways, or that interfere with builds
-started by other users. If they could do so, they could install a Trojan
-horse in some package and compromise the accounts of other users.
 
-To prevent this, the Nix store and database are owned by some privileged
+To prevent this, the Nix store and database are owned by some privileged user (usually `root`) and builders are executed under unprivileged system user accounts (usually named `nixbld1`, `nixbld2`, etc.).
-user (usually `root`) and builders are executed under special user
+When an unprivileged user runs a Nix command, actions that operate on the Nix store (such as builds) are forwarded to a *Nix daemon* running under the owner of the Nix store/database that performs the operation.
-accounts (usually named `nixbld1`, `nixbld2`, etc.). When a unprivileged
-user runs a Nix command, actions that operate on the Nix store (such as
-builds) are forwarded to a *Nix daemon* running under the owner of the
-Nix store/database that performs the operation.
 
-> **Note**
+The buried lede in the above sentence is that *currently*, even in multi-user mode using a daemon, if executing as the user that owns the store, Lix directly manipulates the store unless `--store daemon` is specified.
->
+[We intend to change this in the future][multi-user-should-not-be-root].
-> Multi-user mode has one important limitation: only root and a set of
-> trusted users specified in `nix.conf` can specify arbitrary binary
-> caches. So while unprivileged users may install packages from
-> arbitrary Nix expressions, they may not get pre-built binaries.
 
-## Setting up the build users
+<div class="warning">
+The Lix team considers the goal of the sandbox to be primarily for preventing reproducibility mistakes, and does not consider multi-user mode to be a strong security boundary between users.
+
+Do not evaluate or build untrusted, potentially-malicious, Nix language code on machines that you care deeply about maintaining user isolation on.
+
+Although we would consider any sandbox escapes to be serious security bugs and we intend to fix them, we are not confident enough in the daemon's security to call the daemon a security boundary.
+</div>
+
+[multi-user-should-not-be-root]: https://git.lix.systems/lix-project/lix/issues/18
+
+## Trust model
+
+There are two categories of users of the Lix daemon: trusted users and untrusted users.
+The Lix daemon only allows connections from users that are either trusted users, or are specified in, or are members of groups specified in, [`allowed-users`](../command-ref/conf-file.md#conf-allowed-users) in `nix.conf`.
+Trusted users are users and users of groups specified in [`trusted-users`](../command-ref/conf-file.md#conf-trusted-users) in `nix.conf`.
+
+All users of the Lix daemon may do the following to bring things into the Nix store:
+
+- Users may load derivations and output-addressed files into the store with `nix-store --add` or through Nix language code.
+- Users may locally build derivations, either of the output-addressed or input-addressed variety, creating output paths.
+
+  Note that [fixed-output derivations only consider name and hash](https://github.com/NixOS/nix/issues/969), so it is possible to write a fixed-output derivation for something important with a bogus hash and have it resolve to something else already built in the store.
+
+  On systems with `sandbox` enabled (default on Linux; [not *yet* on macOS][sandbox-enable-macos]), derivations are either:
+    - Input-addressed, so they are run in the sandbox with no network access, with the following exceptions:
+
+      - The (poorly named, since it is not *just* about chroot) property `__noChroot` is set on the derivation and `sandbox` is set to `relaxed`.
+      - On macOS, the derivation property `__darwinAllowLocalNetworking` allows network access to localhost from input-addressed derivations regardless of the `sandbox` setting value. This property exists with such semantics because macOS has no network namespace equivalent to isolate individual processes' localhost networking.
+    - Output-addressed, so they are run with network access but their result must match an expected hash.
+
+  Trusted users may set any setting, including `sandbox = false`, so the sandbox state can be different at runtime from what is described in `nix.conf` for builds invoked with such settings.
+- Users may copy appropriately-signed derivation outputs into the store.
+
+  By default, any paths *copied into a store* (such as by substitution) must have signatures from [`trusted-public-keys`](../command-ref/conf-file.md#conf-trusted-public-keys) unless they are [output-addressed](../glossary.md#gloss-output-addressed-store-object).
+
+  Unsigned paths may be copied into a store if [`require-sigs`](../command-ref/conf-file.md#conf-require-sigs) is disabled in the daemon's configuration (not default), or if the client is a trusted user and passed `--no-check-sigs` to `nix copy`.
+- Users may request that the daemon substitutes appropriately-signed derivation outputs from a binary cache in the daemon's [`substituters`](../command-ref/conf-file.md#conf-substituters) list.
+
+  Untrusted clients may also specify additional values for `substituters` (via e.g. `--extra-substituters` on a Nix command) that are listed in [`trusted-substituters`](../command-ref/conf-file.md#conf-trusted-substituters).
+
+  A client could in principle substitute such paths itself then copy them to the daemon (see clause above) if they are appropriately signed but are *not* from a trusted substituter, however this is not implemented in the current Lix client to our knowledge, at the time of writing.
+  This probably means that `trusted-substituters` is a redundant setting except insofar as such substitution would have to be done on the client rather than as root on the daemon; and it is highly defensible to not allow random usage of our HTTP client running as root.
+
+[sandbox-enable-macos]: https://git.lix.systems/lix-project/lix/issues/386
+
+### The Lix daemon as a security non-boundary
+
+The Lix team and wider community does not consider the Lix daemon to be a *security boundary* against malicious Nix language code.
+
+Although we do our best to make it secure, we do not recommend sharing a Lix daemon with potentially malicious users.
+That means that public continuous integration (CI) builds of untrusted Nix code should not share builders with CI that writes into a cache used by trusted infrastructure.
+
+For example, [hydra.nixos.org], which is the builder for [cache.nixos.org], does not execute untrusted Nix language code; a separate system, [ofborg] is used for CI of nixpkgs pull requests.
+The build output of pull request CI is never pushed to [cache.nixos.org], and those systems are considered entirely untrusted.
+
+This is because, among other things, the Lix sandbox is *more* susceptible to kernel exploits than Docker, which, unlike Lix, blocks nested user namespaces via `seccomp` in its default policy, and there have been many kernel bugs only exposed to unprivileged users via user namespaces allowing otherwise-root-only system calls.
+In general, the Lix sandbox is set up to be relatively unrestricted while maintaining its goals of building useful, reproducible software; security is not its primary goal.
+
+The Lix sandbox is a custom *non-rootless* Linux container implementation that has not been audited to nearly the same degree as Docker and similar systems.
+Also, the Lix daemon is a complex and historied C++ executable running as root with very little privilege separation.
+All of this means that a security hole in the Lix daemon gives immediate root access.
+Systems like Docker (especially non-rootless Docker) should *themselves* probably not be used in a multi-tenant manner with mutually distrusting tenants, but the Lix daemon *especially* should not be used as such as of this writing.
+
+The primary purpose of the sandbox is to strongly encourage packages to be reproducible, a goal which it is generally quite successful at.
+
+[hydra.nixos.org]: https://hydra.nixos.org
+[ofborg]: https://github.com/NixOS/ofborg
+[cache.nixos.org]: https://cache.nixos.org
+
+### Trusted users
+
+Trusted users are permitted to set any setting and bypass security restrictions on the daemon.
+They are currently in widespread use for a couple of reasons such as remote builds (which we [intend to fix](https://git.lix.systems/lix-project/lix/issues/171)).
+
+Trusted users are effectively root on Nix daemons running as root (the default configuration) for *at least* the following reasons, and should be thus thought of as equivalent to passwordless sudo.
+This is not a comprehensive list.
+
+- They may copy an unsigned malicious built output into the store for `systemd` or anything else that will run as root, then when the system is upgraded, that path will be used from the local store rather than substituted.
+- They may set the following settings that are commands the daemon will run as root:
+  - `build-hook`
+  - `diff-hook`
+  - `pre-build-hook`
+  - `post-build-hook`
+- They may set `build-users-group`.
+
+  In particular, they may set it to empty string, which runs builds as root with respect to the rest of the system (!!).
+  We, too, [think that is absurd and intend to not accept such a configuration](https://git.lix.systems/lix-project/lix/issues/242).
+  It is then simply an exercise to the reader to find a daemon that does `SCM_CREDENTIALS` over a `unix(7)` socket and lets you run commands as root, and mount it into the sandbox with `extra-sandbox-paths`.
+
+  At the very least, the Lix daemon itself (since `root` is a trusted user by default) and probably `systemd` qualify for this.
+- They may set the `builders` list, which will have ssh run as root.
+  We aren't sure if there is a way to abuse this for command execution but it's plausible.
+
+Note that setting `accept-flake-config` allows arbitrary Nix flakes to set Nix settings in the `nixConfig` stanza.
+Do not set this setting or pass `--accept-flake-config` while executing untrusted Nix language code as a trusted user for the reasons above!
+
+## Build users
 
 The *build users* are the special UIDs under which builds are performed.
-They should all be members of the *build users group* `nixbld`. This
+A build user is selected for a build by looking in the group specified by [`build-users-group`](../command-ref/conf-file.md#conf-build-users-group), by default, `nixbld`, then a member of that group not currently executing a build is selected for the build.
-group should have no other members. The build users should not be
+The build users should not be members of any other group.
-members of any other group. On Linux, you can create the group and users
+
-as follows:
+There can never be more concurrent builds than the number of build users, unless using [`auto-allocate-uids`](../command-ref/conf-file.md#conf-auto-allocate-uids) ([tracking issue][auto-allocate-uids-issue]).
+
+[auto-allocate-uids-issue]: https://git.lix.systems/lix-project/lix/issues/387
+
+If, for some reason, you need to create such users manually, the following command will create 10 build users on Linux:
 
 ```console
 $ groupadd -r nixbld
@@ -35,43 +124,12 @@ $ for n in $(seq 1 10); do useradd -c "Nix build user $n" \
     nixbld$n; done
 ```
 
-This creates 10 build users. There can never be more concurrent builds
-than the number of build users, so you may want to increase this if you
-expect to do many builds at the same time.
-
 ## Running the daemon
 
-The [Nix daemon](../command-ref/nix-daemon.md) should be started as
+The [Nix daemon](../command-ref/nix-daemon.md) can be started manually as follows (as `root`):
-follows (as `root`):
 
 ```console
-$ nix-daemon
+# nix-daemon
 ```
 
-You’ll want to put that line somewhere in your system’s boot scripts.
+In standard installations of Lix, the daemon is started by a `systemd` unit (Linux) or `launchd` service (macOS).
-
-To let unprivileged users use the daemon, they should set the
-[`NIX_REMOTE` environment variable](../command-ref/env-common.md) to
-`daemon`. So you should put a line like
-
-```console
-export NIX_REMOTE=daemon
-```
-
-into the users’ login scripts.
-
-## Restricting access
-
-To limit which users can perform Nix operations, you can use the
-permissions on the directory `/nix/var/nix/daemon-socket`. For instance,
-if you want to restrict the use of Nix to the members of a group called
-`nix-users`, do
-
-```console
-$ chgrp nix-users /nix/var/nix/daemon-socket
-$ chmod ug=rwx,o= /nix/var/nix/daemon-socket
-```
-
-This way, users who are not in the `nix-users` group cannot connect to
-the Unix domain socket `/nix/var/nix/daemon-socket/socket`, so they
-cannot perform Nix operations.

doc/manual/src/installation/nix-security.md

@@ -7,9 +7,8 @@ management operations. All other users can then use the installed
 packages, but they cannot perform package management operations
 themselves.
 
-Alternatively, you can configure Lix in “multi-user mode”. In this
+Alternatively, you can configure Lix in “multi-user mode”. In this model, all users can perform package management operations — for instance, every user can install software for themselves without requiring root privileges.
-model, all users can perform package management operations — for
+Lix does its best to ensure that this is secure.
-instance, every user can install software without requiring root
+For instance, it would be considered a serious security bug for one untrusted user to be able to overwrite a package used by another user with a Trojan horse.
-privileges. Lix ensures that this is secure. For instance, it’s not
+
-possible for one user to overwrite a package used by another user with a
+Nevertheless, the Lix team does not consider multi-user mode a strong security boundary, and does not recommend running untrusted user-supplied Nix language code on privileged machines, even if it is secure to the best of our knowledge at any moment in time.
-Trojan horse.

src/libfetchers/fetch-settings.hh

@@ -87,7 +87,17 @@ struct FetchSettings : public Config
         {}, true, Xp::Flakes};
 
     Setting<bool> acceptFlakeConfig{this, false, "accept-flake-config",
-        "Whether to accept nix configuration from a flake without prompting.",
+        R"(
+          Whether to accept Lix configuration from the `nixConfig` attribute of
+          a flake without prompting. This is almost always a very bad idea.
+
+          Setting this setting as a trusted user allows Nix flakes to gain root
+          access on your machine if they set one of the several
+          trusted-user-only settings that execute commands as root.
+
+          See [multi-user installations](@docroot@/installation/multi-user.md)
+          for more details on the Lix security model.
+        )",
         {}, true, Xp::Flakes};
 
     Setting<std::string> commitLockFileSummary{

src/libstore/derivations.hh

@@ -208,7 +208,7 @@ struct DerivationType {
     /**
      * Impure derivation type
      *
-     * This is similar at buil-time to the content addressed, not standboxed, not fixed
+     * This is similar at build-time to the content addressed, not sandboxed, not fixed
      * type, but has some restrictions on its usage.
      */
     struct Impure {

src/libstore/globals.hh

@@ -331,7 +331,7 @@ public:
           performed by the Lix account since that would allow users to
           arbitrarily modify the Nix store and database by supplying specially
           crafted builders; and they cannot be performed by the calling user
-          since that would allow him/her to influence the build result.
+          since that would allow them to influence the build result.
 
           Therefore, if this option is non-empty and specifies a valid group,
           builds will be performed under the user accounts that are a member
@@ -352,10 +352,17 @@ public:
 
           If the build users group is empty, builds will be performed under
           the uid of the Lix process (that is, the uid of the caller if
-          `NIX_REMOTE` is empty, the uid under which the Nix daemon runs if
+          both `NIX_REMOTE` is either empty or `auto` and the Nix store is
-          `NIX_REMOTE` is `daemon`). Obviously, this should not be used
+          owned by that user, or, alternatively, the uid under which the Nix
+          daemon runs if `NIX_REMOTE` is `daemon` or if it is `auto` and the
+          store is not owned by the caller). Obviously, this should not be used
           with a nix daemon accessible to untrusted clients.
 
+          For the avoidance of doubt, explicitly setting this to *empty* with a
+          Lix daemon running as root means that builds will be executed as root
+          with respect to the rest of the system.
+          We intend to fix this: https://git.lix.systems/lix-project/lix/issues/242
+
           Defaults to `nixbld` when running as root, *empty* otherwise.
         )",
         {}, false};

src/nix/flake.md

@@ -394,15 +394,17 @@ The following attributes are supported in `flake.nix`:
   value (e.g. `packages.x86_64-linux` must be an attribute set of
   derivations built for the `x86_64-linux` platform).
 
-* `nixConfig`: a set of `nix.conf` options to be set when evaluating any
+* `nixConfig`: a set of `nix.conf` options to be set when evaluating any part of a flake.
-  part of a flake. In the interests of security, only a small set of
+  This attribute is only considered if the flake is at top-level (i.e. if it is passed directly to `nix build`, `nix run`, etc, rather than as an input of another flake).
-  set of options is allowed to be set without confirmation so long as [`accept-flake-config`](@docroot@/command-ref/conf-file.md#conf-accept-flake-config) is not enabled in the global configuration:
+  In the interests of security, only a small set of set of options is allowed to be set without confirmation so long as [`accept-flake-config`](@docroot@/command-ref/conf-file.md#conf-accept-flake-config) is not enabled in the global configuration:
    - [`bash-prompt`](@docroot@/command-ref/conf-file.md#conf-bash-prompt)
    - [`bash-prompt-prefix`](@docroot@/command-ref/conf-file.md#conf-bash-prompt-prefix)
    - [`bash-prompt-suffix`](@docroot@/command-ref/conf-file.md#conf-bash-prompt-suffix)
    - [`flake-registry`](@docroot@/command-ref/conf-file.md#conf-flake-registry)
    - [`commit-lockfile-summary`](@docroot@/command-ref/conf-file.md#conf-commit-lockfile-summary)
 
+  For the avoidance of doubt, setting `accept-flake-config` in `nix.conf` or passing `--accept-flake-config` *allows root access to your machine* if you are running as a trusted user and don't read `nixConfig` in every flake you build.
+
 ## Flake inputs
 
 The attribute `inputs` specifies the dependencies of a flake, as an