[RFC 0041] SELinux Support

[outergod]

As suggested by @Mic92 in NixOS/nix#2670, I would like to propose this RFC for implementation in Nix and NixOS.

@fishilico @etbe @mstone for your consideration, as well.

[Ekleog]

I have doubts on the idea of running Nix on SELinux-enabled distributions. What I currently understand appears to imply that binaries will be trusted based on their path relative to the root of their derivation: /nix/store/1234567890abcdef-httpd/bin/httpd would take into account only /bin/httpd.

This is insecure, as any user with access to the nix daemon could request such a file to be built with whatever content.

As I guess I misunderstood something, would it be possible to make the threat model and the currently-envisioned solution explicit?

Currently, I think I can see how to make NixOS interoperate cleanly with SELinux (by generating the policy as part of the module system), but I cannot see yet how to make Nix interoperate cleanly with a SELinux-enabled system.

[edolstra]

I've never used SELinux, so take the following with a grain of salt, but it's my understanding that SELinux is a poor fit for the immutable model of the Nix store. If I understand NixOS/nix#2670 correctly, it applies file contexts to store paths after they have been built, which breaks immutability. Alternatively, file contexts could be set by derivations at build time, but then file contexts should be recorded in NAR files.

Some previous discussion on SELinux on NixOS: https://nixos.org/nix-dev/2013-May/011091.html (the conclusion being that AppArmor is a better fit for NixOS).

[outergod]

@Ekleog

I have doubts on the idea of running Nix on SELinux-enabled distributions. What I currently understand appears to imply that binaries will be trusted based on their path relative to the root of their derivation: /nix/store/1234567890abcdef-httpd/bin/httpd would take into account only /bin/httpd.

This is correct for the solution proposed by @etbe, which is also the primary one described in the RFC. However the alternative solution would be to assign contexts for each build, individually, which comes with all the drawbacks enumerated.

This is insecure, as any user with access to the nix daemon could request such a file to be built with whatever content.

As I guess I misunderstood something, would it be possible to make the threat model and the currently-envisioned solution explicit?

Yes, there is a misunderstanding, here. Currently, binaries installed by Nix on an SELinux-enabled system are automatically labelled unconfined_t in lack of a policy covering anything in /nix, which is least restrictive on what these binaries can do. There is an exception however, which is that systemctl can't operate on unconfined files so it can't symlink services files through Nix profile directories, but that's about it. A user with root rights can still create said symlinks to service files manually or copy them so Nix binaries will ultimately be run through systemd in the least restricted manner, i.e. completely unsecured.

SELinux is usually used only for system services requiring root privileges and restrains processes to the exact privileges they need to operate with. SELinux can be tailored to operate in a more locked down, white-listing fashion, even affecting what regular users can do as well, but this far less common and no distribution I'm aware of is built this way. Maybe the SELinux folks can shed some more light on these use cases, like @etbe or @fishilico.

Currently, I think I can see how to make NixOS interoperate cleanly with SELinux (by generating the policy as part of the module system), but I cannot see yet how to make Nix interoperate cleanly with a SELinux-enabled system.

Any level of integration will currently only take away privileges from Nix-owned binaries, so interoperability can't possibly worsen. SELinux does not grant additional privileges overriding default POSIX security measures like file ownership, so I can't possibly think of any benefit when a user tries to maliciously build a binary with a different name. If they can run it as root, they can do whatever they want anyway, including manually relabeling the binary to be unconfined.

A system which is designed to be as locked down as possible and where SELinux is used for this purpose, wouldn't allow users to install and run arbitrary binaries to begin with.

Again, @etbe and @fishilico please correct me if I'm wrong.

[outergod]

@edolstra

I've never used SELinux, so take the following with a grain of salt, but it's my understanding that SELinux is a poor fit for the immutable model of the Nix store. If I understand NixOS/nix#2670 correctly, it applies file contexts to store paths after they have been built, which breaks immutability. Alternatively, file contexts could be set by derivations at build time, but then file contexts should be recorded in NAR files.

SELinux can do anything AppArmor can do, just in a more fine-grained way and with more control over the process. Making SELinux and Nix a good match is just a matter of work.

NixOS/nix#2670 is indeed at odds with immutability and originally only aimed at fixing the very issue of providing basic interoperability on SELinux-enabled systems. With a bit of work, I could change the PR to instead derive file contexts from a policy derivation coming from the store itself which gets applied during build time and written to the NAR archive, as well. This would, I believe, supersede @etbe's patches to SELinux itself, but I might be wrong.

I understand that this may be the only way forward for actual NixOS support, whereas the proposed original solution only works as an ephemeral workaround to make Nix work again on SELinux-enabled systems in multi-user mode.

Some previous discussion on SELinux on NixOS: https://nixos.org/nix-dev/2013-May/011091.html (the conclusion being that AppArmor is a better fit for NixOS).

I don't know AppArmor as well as I know SELinux, but I think this is a fallacy. SELinux is just more complex than AppArmor, but there isn't a single distinguishing feature or property in AppArmor that makes it more well-suited for NixOS. On the contrary, AppArmor operates on paths only as I understand it, which means only SELinux labels can be written to NAR archives in order to maintain immutability, even though this is isn't part of the current iteration of the RFC.

I would like to wait for comments from @etbe and @fishilico as they are from SELinux upstream, but in the meantime, I could work on a proof-of-concept prototype for the aforementioned, immutability-adhering solution.

[Mic92]

I would suggest that in the shepherd team at least one person from @NixOS/nix-core should be included.

[nixos-discourse]

This pull request has been mentioned on Nix community. There might be relevant details there:

https://discourse.nixos.org/t/rfcs-41-selinux-support-is-open-for-shepherd-nomination/2420/1

[shlevy]

@edolstra has been nominated. @Ekleog @aszlig available to join?

[outergod]

I'm very happy to hear @edolstra will be the shepherd for this RFC!

How does the process continue, from here?

[Ekleog]

@shlevy Given my upcoming schedule, I unfortunately think I won't be able to shepherd this RFC for at least the coming month.

As a side-note, I'd suggest inviting interested people from SELinux in the meeting, so that discussion could also use their insight.

[globin]

I additionally nominate @joachifm @xeji and @thoughtpolice, who all have worked on hardening/SELinux PRs/issues in nixpkgs

[joachifm]

I'd be happy to contribute to this, to the extent that I am able.

[thoughtpolice]

I'm in the middle of many things right now (job hunt, house work, planned travels) so I'm afraid I can't make any kind of commitment at this moment to see things through, at least for several more weeks or so once things shake out -- and I also must admit I'm unfamiliar with SELinux. (I appreciate the nomination, nonetheless!)

[shlevy]

@e-user Do you have any thoughts for others we can nominate to the team? If not, are you OK with having a smaller-than-usual shepherd team to facilitate the discussion and make the final decision?

[asymmetric]

Can we have a link to the rendered RFC in the top comment? :)

[outergod]

@shlevy I'm fine with anything as long as we can move forward.

[domenkozar]

@thoughtpolice what about now, did situation improve? :)

[joachifm]

If the changes to Nix are acceptable in principle, maybe it'd be easier to reduce the scope of the RFC to only cover those and leave NixOS for later?

[shlevy]

@edolstra Should we move forward with a meeting with the reduced shepherd team?

[thoughtpolice]

Sorry for the delay here. I've had a recent job change and things have settled down a bit for me, so I can accept the nomination to help shepard this. Please note that I have little insight into SELinux itself, but am interested in helping steer things to ensure it can work for our users if that's what they desire, to the greatest extent I can (and I can surely get a bit more up-to-speed in the mean time.)

Regarding @joachifm's point, personally I think a single RFC is fine. But the larger, long-term timelines here (upstreaming SELinux changes, Nix changes/review cycles, cutting a new Nix stable with them, releasing to users, then making Nixpkgs changes) mean some people may feel differently. I think there are reasonable positions for both, but this RFC has lingered a bit -- so I think we should probably begin moving forward first, and scope discussions should probably be a starting point.

[edolstra]

Hm, I haven't heard back from the @e-user, who really should join the call since he's the RFC author :-) Let's postpone until we hear back from him.

[domenkozar]

Suggested change

	co-authors: (none yet)
	co-authors: (none yet)
	shepherd-team: Eelco Dolstra, Shea Levy, Austin Seipp, Joachim F.
	shepherd-leader: Eelco Dolstra

[outergod]

Hey everyone,

my work life has currently caught up and I don't have a lot of capacity left to work on this, but this might change sometime soon, when I can spend some of my spare time. I can definitely make some room for the call, just @-ping me with the details.

[shlevy]

Shall we try to organize another call?

[edolstra]

@shlevy @thoughtpolice, @joachifm @e-user Would you have time for a call some time next week?

[joachifm]

yes

[thoughtpolice]

Yes, I can make time for a call -- details sooner better than later, of course!

[outergod]

Sure

[edolstra]

How about Friday 18th at 14:00 UTC (16:00 CET)?

[joachifm]

How about Friday 18th at 14:00 UTC (16:00 CET)?

Works for me.

[outergod]

How about Friday 18th at 14:00 UTC (16:00 CET)?

Alright. Will someone share the call details with me?

[edolstra]

I've created a Google calendar invite. The hangout is https://hangouts.google.com/call/ktIe3WzNmon8fltbusAqAEEI.

[joachifm]

Sorry, some work related stuff has come up; I won't be able to make it.

[outergod]

After a very productive call, @edolstra and I decided to close the RFC with the option of re-opening at a later time. Instead, we'll be focusing on a minimum viable solution to run Nix store binaries from systemd on SELinux-enabled systems, which most likely only requires changes to Nix' installer and is not intrusive towards the rest of the overall Nix and NixOS architecture.

[Melkor333]

Is it possible to share some details why this decision was made for eventual later reference? :)

[nixos-discourse]

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

https://discourse.nixos.org/t/how-many-people-are-paid-to-work-on-nix-nixpkgs/8307/46