search

NixOS / nixpkgs

Nix Packages collection & NixOS
MIT License
17.96k stars 13.97k forks source link

platformio package broken (on hardened NixOS) #86993

Closed Mindavi closed 4 years ago

Mindavi commented 4 years ago

Describe the bug

The platformio package seems to be broken.

Running the pio or platformio command after creating a shell nix-shell -p platformio creates the following crash:

** Message: 18:50:17.956: Requires Linux version >= 3.19 built with CONFIG_USER_NS
** Message: 18:50:17.959: Run: sudo sysctl -w kernel.unprivileged_userns_clone=1

** (process:6731): ERROR **: 18:50:17.960: main: unshare: Operation not permitted
Trace/breakpoint trap (core dumped)

Expected behavior

For the pio command, I expected the help text for the command.

Additional context

It seems like this might have to do with the hardening features of NixOS hardened. I don't want to disable these features, because they're set to protect my system against attacks.

https://security.stackexchange.com/questions/209529/what-does-enabling-kernel-unprivileged-userns-clone-do

I looked at this briefly, but I'm not yet sure if it's platformio itself doing this or if the wrapping does something that might cause this.

Notify maintainers

The original maintainers don't seem to be maintaining this anymore, so I tagged the last/common committers. Let me know if you're interested in looking into this, otherwise I'll remove the mention.

@dotlambda @peterhoeg @fpletz @geistesk

Metadata

Maintainer information:

# a list of nixpkgs attributes affected by the problem
attribute:
# a list of nixos modules affected by the problem
module:
peterhoeg commented 4 years ago

The platformio package seems to be broken.

It seems like this might have to do with the hardening features of NixOS hardened.

My guess is that in order to be able to enter the fhsenv, we need the user_ns functionality.

What happens if you try what was suggested:

sudo sysctl -w kernel.unprivileged_userns_clone=1

Can you then do it?

Mindavi commented 4 years ago

Yeah, it does work in that case. So this means I can't use platformio without compromising my security? I've tried with sudo, but if I try to setup a new project I'm not sure where it ends up. Of course, using sudo is not a preferable solution either.

$ sudo pio project init --board d1_mini

The current working directory / will be used for the project.

The next files/directories have been created in /
include - Put project header files here
lib - Put here project specific (private) libraries
src - Put project source files here
platformio.ini - Project Configuration File

Project has been successfully initialized! Useful commands:
`pio run` - process/build project from the current directory
`pio run --target upload` or `pio run -t upload` - upload firmware to a target
`pio run --target clean` - clean project (remove compiled files)
`pio run --help` - additional information

I guess I can temporarily enable the unprivileged userns clone when I want to use platformio, but it's a workaround at best.

The message comes from here, indeed from the fhsenv.

I guess this isn't resolved then, but I'm also unsure if anything can be done about it or that I should just tread carefully whenever using any package that creates an fhsenv.

peterhoeg commented 4 years ago

(#86993) Reply-To: Priority: Normal In-Reply-To: NixOS/nixpkgs/issues/86993/624464260@github.com

running pio with sudo is definitely not the way to go.

So this means I can't use platformio without compromising my security?

That very much depends on how you define "compromising my security". Security isn't absolute.

If the question is "am I able to run applications in an fhsenv without user namespace support", then the answer is "no, not currently". Just as well as there are several other mitigations against exploits one could potentially put in place that would limit ones ability to use other programs.

If you really want to use pio without user namespace support, I guess the way forward is to patch pio to not depend on being run inside an FHS-like environment, which is however likely to be a ton of work for very little (how much is obviously debatable) gain.

I should just tread carefully whenever using any package that creates an fhsenv.

I don't see a reason to treat fhsenv applications any differently from non-fhsenv applications. You just will not be able to run them without userns support.

Mindavi commented 4 years ago

I might look into running it without userns, but I guess I'll just workaround this by temporarily setting the configuration.

Thanks for looking at this with me! Closing as I'm ok with the solution. You're right, I shouldn't be worried too much about this one security feature.