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

nixpkgs: allow packages to be marked insecure (this time with docs) #23130

Merged
merged 2 commits into from Feb 24, 2017

Conversation

grahamc
Copy link
Member

@grahamc grahamc commented Feb 24, 2017

Motivation for this change

If a package's meta has knownVulnerabilities, like so:

stdenv.mkDerivation {
  name = "foobar-1.2.3";

  ...

  meta.knownVulnerabilities = [
    "CVE-0000-00000: remote code execution"
    "CVE-0000-00001: local privilege escalation"
  ];
}

and a user attempts to install the package, they will be greeted with
a warning indicating that maybe they don't want to install it:

error: Package ‘foobar-1.2.3’ in ‘...default.nix:20’ is marked as insecure, refusing to evaluate.

Known issues:

 - CVE-0000-00000: remote code execution
 - CVE-0000-00001: local privilege escalation

You can install it anyway by whitelisting this package, using the
following methods:

a) for `nixos-rebuild` you can add ‘foobar-1.2.3’ to
   `nixpkgs.config.permittedInsecurePackages` in the configuration.nix,
   like so:

     {
       nixpkgs.config.permittedInsecurePackages = [
         "foobar-1.2.3"
       ];
     }

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
‘foobar-1.2.3’ to `permittedInsecurePackages` in
~/.config/nixpkgs/config.nix, like so:

     {
       permittedInsecurePackages = [
         "foobar-1.2.3"
       ];
     }

Adding either of these configurations will permit this specific
version to be installed. A third option also exists:

NIXPKGS_ALLOW_INSECURE=1 nix-build ...

though I specifically avoided having a global file-based toggle to
disable this check. This way, users don't disable it once in order to
get a single package, and then don't realize future packages are
insecure.

Things done
  • Tested using sandboxing
    (nix.useSandbox on NixOS,
    or option build-use-sandbox in nix.conf
    on non-NixOS)
  • Built on platform(s)
    • NixOS
    • macOS
    • Linux
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Fits CONTRIBUTING.md.

Previously merged, but needed docs. So I added docs. see: https://github.com/NixOS/nixpkgs/pull/22890/files

cc @FRidh, @danbst, @jgeerds, @globin, @vcunat (I'm not even asking you to convert my docs to docbook this time :) ), @fpletz, @domenkozar, @7c6f434c.

@mention-bot
Copy link

@grahamc, thanks for your PR! By analyzing the history of the files in this pull request, we identified @edolstra, @matthiasbeyer and @seppeljordan to be potential reviewers.

@grahamc grahamc changed the title nixpkgs: allow packages to be marked insecure nixpkgs: allow packages to be marked insecure (this time with docs) Feb 24, 2017
@grahamc
Copy link
Member Author

grahamc commented Feb 24, 2017

You can see the docs rendered here: http://gsc.io/nixpkgs/manual.html#chap-packageconfig

If a package's meta has `knownVulnerabilities`, like so:

    stdenv.mkDerivation {
      name = "foobar-1.2.3";

      ...

      meta.knownVulnerabilities = [
        "CVE-0000-00000: remote code execution"
        "CVE-0000-00001: local privilege escalation"
      ];
    }

and a user attempts to install the package, they will be greeted with
a warning indicating that maybe they don't want to install it:

    error: Package ‘foobar-1.2.3’ in ‘...default.nix:20’ is marked as insecure, refusing to evaluate.

    Known issues:

     - CVE-0000-00000: remote code execution
     - CVE-0000-00001: local privilege escalation

    You can install it anyway by whitelisting this package, using the
    following methods:

    a) for `nixos-rebuild` you can add ‘foobar-1.2.3’ to
       `nixpkgs.config.permittedInsecurePackages` in the configuration.nix,
       like so:

         {
           nixpkgs.config.permittedInsecurePackages = [
             "foobar-1.2.3"
           ];
         }

    b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
    ‘foobar-1.2.3’ to `permittedInsecurePackages` in
    ~/.config/nixpkgs/config.nix, like so:

         {
           permittedInsecurePackages = [
             "foobar-1.2.3"
           ];
         }

Adding either of these configurations will permit this specific
version to be installed. A third option also exists:

  NIXPKGS_ALLOW_INSECURE=1 nix-build ...

though I specifically avoided having a global file-based toggle to
disable this check. This way, users don't disable it once in order to
get a single package, and then don't realize future packages are
insecure.
Patches currently available don't seem to apply.
@globin globin merged commit 8f60b43 into NixOS:master Feb 24, 2017
@grahamc grahamc deleted the insecure-packages-with-docs branch February 24, 2017 12:44
@grahamc grahamc mentioned this pull request Feb 24, 2017
4 tasks
@grahamc
Copy link
Member Author

grahamc commented Feb 24, 2017

🍾


<para>There are several ways to tweak how Nix handles a package
which has been marked as unfree.</para>
Copy link
Member

Choose a reason for hiding this comment

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

"unfree" should probably be "insecure" here.

Copy link
Member

Choose a reason for hiding this comment

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

That had been fixed: a50222b

@Profpatsch
Copy link
Member

@aszlig has found a more “functional” way to enable certain packages:
https://github.com/openlab-aux/vuizvui/blob/350b13fdbb02916aebceed6f115e0b0c38672d3d/modules/core/licensing.nix

It should be possible to adapt that to insecure packages, then they could be marked like this:

systemPackages = [
  …
  insecurePackages.somePkg
  ];

having the semantics of “build, even if the package is marked as insecure”.

@grahamc
Copy link
Member Author

grahamc commented Mar 5, 2017 via email

@Profpatsch
Copy link
Member

e: did the user use pkgs.foobar? mypkgs.foobar?

I see. But it should be ok to reference the derivation name and tell the user in a general way I think. Package names are inherently not very nice to have as references because it corrupts the idea of the input hash as authority of version, instead of the arbitrary package name.

@grahamc
Copy link
Member Author

grahamc commented Mar 5, 2017 via email

@Profpatsch
Copy link
Member

I see, it’s not very sensible then.

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

Successfully merging this pull request may close these issues.

None yet

6 participants