5 ms·

nixos missing 2/3 is what's behind my repeated insistence that nix is in sore need of a plan 9-esque host system. perhaps with fuchsia there's hope yet. cgroup

nixos missing 2/3 is what's behind my repeated insistence that nix is in sore need of a plan 9-esque host system. perhaps with fuchsia there's hope yet. cgroups and linux namespaces are great and all but pervasive namespace abstraction really really needs a fluid, low-friction interface for constructing those namespaces and subsequently examining precisely how they're put together. this is why typing ns in plan 9 is a huge eye-opener for a lot of newcomers. suid and friends ensure a perpetual lower bound on red tape and drudgery where traditional unix-likes implement namespaces.

pmarreck 4y ago
Been a NixOS user for over a year now, quite happy with it, can you go over why 2 and 3 are "necessary"?
- 0x69420 4y ago
  in the same way that flakes address build-time (and hence, nix project) boundaries, i want to easily control runtime boundaries does a service need to see all of the store? no; just its closure. all of /proc? probably not. i would love to stop caring about secrets in the store something as heavyweight as a container just to achieve those restrictions almost feels insulting, and something like pledge(2) approaches the problem from the wrong end. then you take those well-defined boundaries, and you know exactly where you can deploy that service. take advantage of that well-known nix reproducibility, stub out the endpoints, plop it down on your local system, debug it at zero latency, revise it, deploy the fixed version.
  - johnny22 4y ago
    i wonder if you can take advantage of systemd-nspawn for most of that?
  - tadfisher 4y ago
    Just about every restriction using cgroups/namespaces can be applied in systemd units. Many of the services in NixOS have been hardened through systemd, and there's an ongoing effort to harden all of them.
  - agumonkey 4y ago
    OS level "closures" are something I think about, and then the idea of composing said container/env closures into larger ones. I don't know if it's stupid or useful.
amarshall 4y ago
See https://spectrum-os.org/ https://spectrum-os.org/ where some work is being done.

pmarreck 4y ago

Been a NixOS user for over a year now, quite happy with it, can you go over why 2 and 3 are "necessary"?

0x69420 4y ago
in the same way that flakes address build-time (and hence, nix project) boundaries, i want to easily control runtime boundaries does a service need to see all of the store? no; just its closure. all of /proc? probably not. i would love to stop caring about secrets in the store something as heavyweight as a container just to achieve those restrictions almost feels insulting, and something like pledge(2) approaches the problem from the wrong end. then you take those well-defined boundaries, and you know exactly where you can deploy that service. take advantage of that well-known nix reproducibility, stub out the endpoints, plop it down on your local system, debug it at zero latency, revise it, deploy the fixed version.
- johnny22 4y ago
  i wonder if you can take advantage of systemd-nspawn for most of that?
- tadfisher 4y ago
  Just about every restriction using cgroups/namespaces can be applied in systemd units. Many of the services in NixOS have been hardened through systemd, and there's an ongoing effort to harden all of them.
- agumonkey 4y ago
  OS level "closures" are something I think about, and then the idea of composing said container/env closures into larger ones. I don't know if it's stupid or useful.

amarshall 4y ago

See https://spectrum-os.org/ https://spectrum-os.org/ where some work is being done.