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

Default to binary-only installs when running with elevated privileges? #4735

Closed
ncoghlan opened this Issue Sep 21, 2017 · 6 comments

Comments

Projects
None yet
3 participants
@ncoghlan
Member

ncoghlan commented Sep 21, 2017

As noted at #1668 (comment), one of the problems with sudo pip install is that it means any from-source installs will run arbitrary code with elevated privileges, even though the installed library may then never be loaded by any privileged processes.

Actually implementing #1668 is fraught with compatibility problems, but I'm wondering if their might be a useful intermediate step which works like so:

  • when pip is run with elevated privileges, treat that as implying --only-binary :all: so that even though you'll still get global installs by default, you won't get the current "run arbitrary code as root" behaviour
  • add the --global flag from #1668 to explicitly request the current behaviour that falls back to installing from source when there's no wheel file available (right now, that would technically duplicate --only-binary :none:, but it would also override a future change to default to --user once that actually happens)

That approach would still have compatibility problems, but there'd be fewer of them, and all of the remediation measures would be things we actively want to encourage:

  • switch from global installs to per-user or virtual environment installs
  • encourage affected dependencies to publish a suitable wheel file
  • start supplying the --global flag (in preparation for eventual implementation of #1668)
@dstufft

This comment has been minimized.

Show comment
Hide comment
@dstufft

dstufft Sep 21, 2017

Member

I don't really think it's worthwhile, if you're installing something from someone the code is going to run at some point. This just kind of feels like shuffling deck chairs on the titanic.

Member

dstufft commented Sep 21, 2017

I don't really think it's worthwhile, if you're installing something from someone the code is going to run at some point. This just kind of feels like shuffling deck chairs on the titanic.

@ncoghlan

This comment has been minimized.

Show comment
Hide comment
@ncoghlan

ncoghlan Sep 21, 2017

Member

Yeah, from a security perspective, this only pays off in cases where:

  1. The install is executed with elevated privileges
  2. The module/script is subsequently only ever run with ordinary user level privileges (i.e. it was an extra package, not an upgrade of a system managed package)

It makes it slightly harder to get a persistent foothold on a machine, but not appreciably so if it's a local workstation where the user always logs in anyway (so you can just hook their login scripts and assorted other attack vectors).

So I also wouldn't be opposed to just going down the #1668 path of:

  • add --global as a way to ignore a user=true setting in pip.conf
  • eventually make user=true the default, and require either --global or user=false in pip.conf to override it

And deciding this isn't worth it as an intermediate step.

Member

ncoghlan commented Sep 21, 2017

Yeah, from a security perspective, this only pays off in cases where:

  1. The install is executed with elevated privileges
  2. The module/script is subsequently only ever run with ordinary user level privileges (i.e. it was an extra package, not an upgrade of a system managed package)

It makes it slightly harder to get a persistent foothold on a machine, but not appreciably so if it's a local workstation where the user always logs in anyway (so you can just hook their login scripts and assorted other attack vectors).

So I also wouldn't be opposed to just going down the #1668 path of:

  • add --global as a way to ignore a user=true setting in pip.conf
  • eventually make user=true the default, and require either --global or user=false in pip.conf to override it

And deciding this isn't worth it as an intermediate step.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Sep 21, 2017

The best method to solve this is to run bdist_wheel in ring 3. Honestly restricting network access has been mentioned and that is not a good idea.

ghost commented Sep 21, 2017

The best method to solve this is to run bdist_wheel in ring 3. Honestly restricting network access has been mentioned and that is not a good idea.

@pradyunsg

This comment has been minimized.

Show comment
Hide comment
@pradyunsg

pradyunsg Sep 30, 2017

Member

@ncoghlan So... can this be closed?

Member

pradyunsg commented Sep 30, 2017

@ncoghlan So... can this be closed?

@ncoghlan

This comment has been minimized.

Show comment
Hide comment
@ncoghlan

ncoghlan Oct 2, 2017

Member

Aye, closing for now as presumably failing the potential security benefit vs increased code complexity trade-off.

However, if someone likes the idea enough to try implementing it, and finds the resulting PR to be reasonably easy to follow, then they should still feel free to post that PR and request that this RFE be reopened.

Member

ncoghlan commented Oct 2, 2017

Aye, closing for now as presumably failing the potential security benefit vs increased code complexity trade-off.

However, if someone likes the idea enough to try implementing it, and finds the resulting PR to be reasonably easy to follow, then they should still feel free to post that PR and request that this RFE be reopened.

@ncoghlan ncoghlan closed this Oct 2, 2017

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Oct 2, 2017

ghost commented Oct 2, 2017

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