The `--private-users=` flag to systemd-nspawn will create a container with its own user namespace. In principle, this should allow creating systemd container by non-root. That in turn would alleviates the security problems (it's a far more grievous bug for a normal to gain root powers absent an screw-ups on root's powers than root to accidentally back-door itself). See the "Fully Unprivileged Container Payload" section at https://wiki.freedesktop.org/www/Software/systemd/ContainerInterface/
Maybe we should look into (optionally) using `--private-users=` with nixos-container? On Wed, Dec 16, 2015 at 4:33 PM, <joach...@fastmail.fm> wrote: > On Wed, Dec 16, 2015, at 08:46 PM, rohit yadav wrote: > > Hi, > > Hi, > > > After trying docker, rkt etc, I have found nixos-container to be best > > suited for my application. However, I find a warning that root access to > > the container should not be provided to any untrusted user. I am > > wondering > > if I can create a normal user in a declarative container, would that be > > safe? This may be a trivial question, I just want to be clear on this. > > Depending on your setup, having root in the container may be equivalent > to having root on the host. Compared to that situation, executing as an > unprivileged user within the container appears to improve security. That > said, if a container solution CAN adversely affect the host system, it > is prudent to assume that a malicious user will find a way to make that > happen (whether anyone will care to try is another matter). This caveat > very much applies to NixOS containers, which are implemented by > executing `systemd-nspawn` as root on the host system. > > Systemd-nspawn upstream explicitly states that lightweight containers > are insecure and not to be relied on to do much beyond preventing > accidental damage to the host system. If security is your only reason > for using containers, consider whether you're meaningfully improving > security compared to running the service as an unprivileged user on the > host and not actually making things worse by introducing additional > complexity. > > HTH, > Joachim > _______________________________________________ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev >
_______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
