Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC 0041] SELinux Support #41

Closed
wants to merge 2 commits into from
Closed

[RFC 0041] SELinux Support #41

wants to merge 2 commits into from

Conversation

outergod
Copy link

@outergod outergod commented Mar 10, 2019

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.

@globin globin changed the title [RFC 0037] SELinux Support [RFC 0041] SELinux Support Mar 10, 2019
@Ekleog
Copy link
Member

Ekleog commented Mar 13, 2019

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
Copy link
Member

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
Copy link
Author

@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
Copy link
Author

@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
Copy link
Member

Mic92 commented Mar 15, 2019

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

@Mic92 Mic92 added the status: open for nominations Open for shepherding team nominations label Mar 15, 2019
@nixos-discourse
Copy link

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
Copy link
Member

shlevy commented Apr 4, 2019

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

@outergod
Copy link
Author

outergod commented Apr 6, 2019

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

How does the process continue, from here?

@Ekleog
Copy link
Member

Ekleog commented Apr 11, 2019

@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
Copy link
Member

globin commented Apr 25, 2019

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

@joachifm
Copy link

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

@thoughtpolice
Copy link
Member

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
Copy link
Member

shlevy commented May 9, 2019

@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
Copy link
Contributor

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

@outergod
Copy link
Author

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

@Mic92 Mic92 added status: in discussion and removed status: open for nominations Open for shepherding team nominations labels May 30, 2019
@domenkozar
Copy link
Member

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

@joachifm
Copy link

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
Copy link
Member

shlevy commented Jun 30, 2019

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

@thoughtpolice
Copy link
Member

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
Copy link
Member

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.

feature: selinux-support
start-date: 2019-03-10
author: Alexander Kahl (@e-user)
co-authors: (none yet)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Author

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
Copy link
Member

shlevy commented Oct 3, 2019

Shall we try to organize another call?

@edolstra
Copy link
Member

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

@joachifm
Copy link

yes

@thoughtpolice
Copy link
Member

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

@outergod
Copy link
Author

Sure

@edolstra
Copy link
Member

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

@joachifm
Copy link

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

Works for me.

@outergod
Copy link
Author

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

Alright. Will someone share the call details with me?

@edolstra
Copy link
Member

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

@joachifm
Copy link

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

@outergod
Copy link
Author

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.

@outergod outergod closed this Oct 18, 2019
@Melkor333
Copy link

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

@nixos-discourse
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet