max/nix-super
1
0
Fork 0
mirror of https://github.com/privatevoid-net/nix-super.git synced 2024-11-10 08:16:15 +02:00
Code Issues Projects Releases Packages Wiki Activity Actions
nix-super/tests/functional/restricted.sh

68 lines
4 KiB
Bash
Raw Normal View History

Ensure all functional scripts are (a) executable (b) have shebang This is good for shebang, and also good for future build system simplifications
2024-05-28 19:43:04 +03:00
#!/usr/bin/env bash
Add tests for restricted eval mode
2016-04-14 16:24:06 +03:00
source common.sh
tests/functional: Enable more tests in NixOS VM
2024-06-16 18:56:50 +03:00
clearStoreIfPossible
Add tests for restricted eval mode
2016-04-14 16:24:06 +03:00
Test: Replace --option with the corresponding flag
2017-11-20 18:50:49 +02:00
nix-instantiate --restrict-eval --eval -E '1 + 2'
Trivial changes from the lazy-trees branch
2022-12-07 13:58:58 +02:00
(! nix-instantiate --eval --restrict-eval ./restricted.nix)
Add pure evaluation mode In this mode, the following restrictions apply: * The builtins currentTime, currentSystem and storePath throw an error. * $NIX_PATH and -I are ignored. * fetchGit and fetchMercurial require a revision hash. * fetchurl and fetchTarball require a sha256 attribute. * No file system access is allowed outside of the paths returned by fetch{Git,Mercurial,url,Tarball}. Thus 'nix build -f ./foo.nix' is not allowed. Thus, the evaluation result is completely reproducible from the command line arguments. E.g. nix build --pure-eval '( let nix = fetchGit { url = https://github.com/NixOS/nixpkgs.git; rev = "9c927de4b179a6dd210dd88d34bda8af4b575680"; }; nixpkgs = fetchGit { url = https://github.com/NixOS/nixpkgs.git; ref = "release-17.09"; rev = "66b4de79e3841530e6d9c6baf98702aa1f7124e4"; }; in (import (nix + "/release.nix") { inherit nix nixpkgs; }).build.x86_64-linux )' The goal is to enable completely reproducible and traceable evaluation. For example, a NixOS configuration could be fully described by a single Git commit hash. 'nixos-rebuild' would do something like nix build --pure-eval '( (import (fetchGit { url = file:///my-nixos-config; rev = "..."; })).system ') where the Git repository /my-nixos-config would use further fetchGit calls or Git externals to fetch Nixpkgs and whatever other dependencies it has. Either way, the commit hash would uniquely identify the NixOS configuration and allow it to reproduced.
2018-01-16 19:50:38 +02:00
(! nix-instantiate --eval --restrict-eval <(echo '1 + 2'))
Test: Replace --option with the corresponding flag
2017-11-20 18:50:49 +02:00
nix-instantiate --restrict-eval ./simple.nix -I src=.
nix-instantiate --restrict-eval ./simple.nix -I src1=simple.nix -I src2=config.nix -I src3=./simple.builder.sh
Add tests for restricted eval mode
2016-04-14 16:24:06 +03:00
Test: Replace --option with the corresponding flag
2017-11-20 18:50:49 +02:00
(! nix-instantiate --restrict-eval --eval -E 'builtins.readFile ./simple.nix')
Put functional tests in `tests/functional` I think it is bad for these reasons when `tests/` contains a mix of functional and integration tests - Concepts is harder to understand, the documentation makes a good unit vs functional vs integration distinction, but when the integration tests are just two subdirs within `tests/` this is not clear. - Source filtering in the `flake.nix` is more complex. We need to filter out some of the dirs from `tests/`, rather than simply pick the dirs we want and take all of them. This is a good sign the structure of what we are trying to do is not matching the structure of the files. With this change we have a clean: ```shell-session $ git show 'HEAD:tests' tree HEAD:tests functional/ installer/ nixos/ ```
2023-10-05 19:12:18 +03:00
nix-instantiate --restrict-eval --eval -E 'builtins.readFile ./simple.nix' -I src=../..
Add tests for restricted eval mode
2016-04-14 16:24:06 +03:00
Put functional tests in `tests/functional` I think it is bad for these reasons when `tests/` contains a mix of functional and integration tests - Concepts is harder to understand, the documentation makes a good unit vs functional vs integration distinction, but when the integration tests are just two subdirs within `tests/` this is not clear. - Source filtering in the `flake.nix` is more complex. We need to filter out some of the dirs from `tests/`, rather than simply pick the dirs we want and take all of them. This is a good sign the structure of what we are trying to do is not matching the structure of the files. With this change we have a clean: ```shell-session $ git show 'HEAD:tests' tree HEAD:tests functional/ installer/ nixos/ ```
2023-10-05 19:12:18 +03:00
(! nix-instantiate --restrict-eval --eval -E 'builtins.readDir ../../src/nix-channel')
nix-instantiate --restrict-eval --eval -E 'builtins.readDir ../../src/nix-channel' -I src=../../src
Add tests for restricted eval mode
2016-04-14 16:24:06 +03:00
Use expectStderr
2023-12-06 15:05:32 +02:00
expectStderr 1 nix-instantiate --restrict-eval --eval -E 'let __nixPath = [ { prefix = "foo"; path = ./.; } ]; in builtins.readFile <foo/simple.nix>' | grepQuiet "forbidden in restricted mode"
Move restricted/pure-eval access control out of the evaluator and into the accessor
2023-11-30 17:16:17 +02:00
nix-instantiate --restrict-eval --eval -E 'let __nixPath = [ { prefix = "foo"; path = ./.; } ]; in builtins.readFile <foo/simple.nix>' -I src=.
Add tests for restricted eval mode
2016-04-14 16:24:06 +03:00
nix: Add --expr flag This replaces the '(...)' installable syntax, which is not very discoverable. The downside is that you can't have multiple expressions or mix expressions and other installables.
2019-11-27 01:05:30 +02:00
p=$(nix eval --raw --expr "builtins.fetchurl file://$(pwd)/restricted.sh" --impure --restrict-eval --allowed-uris "file://$(pwd)")
Add option allowed-uris This allows network access in restricted eval mode.
2017-10-30 13:39:59 +02:00
cmp $p restricted.sh
nix: Add --expr flag This replaces the '(...)' installable syntax, which is not very discoverable. The downside is that you can't have multiple expressions or mix expressions and other installables.
2019-11-27 01:05:30 +02:00
(! nix eval --raw --expr "builtins.fetchurl file://$(pwd)/restricted.sh" --impure --restrict-eval)
Add option allowed-uris This allows network access in restricted eval mode.
2017-10-30 13:39:59 +02:00
nix: Add --expr flag This replaces the '(...)' installable syntax, which is not very discoverable. The downside is that you can't have multiple expressions or mix expressions and other installables.
2019-11-27 01:05:30 +02:00
(! nix eval --raw --expr "builtins.fetchurl file://$(pwd)/restricted.sh" --impure --restrict-eval --allowed-uris "file://$(pwd)/restricted.sh/")
Add option allowed-uris This allows network access in restricted eval mode.
2017-10-30 13:39:59 +02:00
nix: Add --expr flag This replaces the '(...)' installable syntax, which is not very discoverable. The downside is that you can't have multiple expressions or mix expressions and other installables.
2019-11-27 01:05:30 +02:00
nix eval --raw --expr "builtins.fetchurl file://$(pwd)/restricted.sh" --impure --restrict-eval --allowed-uris "file://$(pwd)/restricted.sh"
Add option allowed-uris This allows network access in restricted eval mode.
2017-10-30 13:39:59 +02:00
nix: Add --expr flag This replaces the '(...)' installable syntax, which is not very discoverable. The downside is that you can't have multiple expressions or mix expressions and other installables.
2019-11-27 01:05:30 +02:00
(! nix eval --raw --expr "builtins.fetchurl https://github.com/NixOS/patchelf/archive/master.tar.gz" --impure --restrict-eval)
(! nix eval --raw --expr "builtins.fetchTarball https://github.com/NixOS/patchelf/archive/master.tar.gz" --impure --restrict-eval)
(! nix eval --raw --expr "fetchGit git://github.com/NixOS/patchelf.git" --impure --restrict-eval)
Add pure evaluation mode In this mode, the following restrictions apply: * The builtins currentTime, currentSystem and storePath throw an error. * $NIX_PATH and -I are ignored. * fetchGit and fetchMercurial require a revision hash. * fetchurl and fetchTarball require a sha256 attribute. * No file system access is allowed outside of the paths returned by fetch{Git,Mercurial,url,Tarball}. Thus 'nix build -f ./foo.nix' is not allowed. Thus, the evaluation result is completely reproducible from the command line arguments. E.g. nix build --pure-eval '( let nix = fetchGit { url = https://github.com/NixOS/nixpkgs.git; rev = "9c927de4b179a6dd210dd88d34bda8af4b575680"; }; nixpkgs = fetchGit { url = https://github.com/NixOS/nixpkgs.git; ref = "release-17.09"; rev = "66b4de79e3841530e6d9c6baf98702aa1f7124e4"; }; in (import (nix + "/release.nix") { inherit nix nixpkgs; }).build.x86_64-linux )' The goal is to enable completely reproducible and traceable evaluation. For example, a NixOS configuration could be fully described by a single Git commit hash. 'nixos-rebuild' would do something like nix build --pure-eval '( (import (fetchGit { url = file:///my-nixos-config; rev = "..."; })).system ') where the Git repository /my-nixos-config would use further fetchGit calls or Git externals to fetch Nixpkgs and whatever other dependencies it has. Either way, the commit hash would uniquely identify the NixOS configuration and allow it to reproduced.
2018-01-16 19:50:38 +02:00
ln -sfn $(pwd)/restricted.nix $TEST_ROOT/restricted.nix
[[ $(nix-instantiate --eval $TEST_ROOT/restricted.nix) == 3 ]]
(! nix-instantiate --eval --restrict-eval $TEST_ROOT/restricted.nix)
(! nix-instantiate --eval --restrict-eval $TEST_ROOT/restricted.nix -I $TEST_ROOT)
(! nix-instantiate --eval --restrict-eval $TEST_ROOT/restricted.nix -I .)
nix-instantiate --eval --restrict-eval $TEST_ROOT/restricted.nix -I $TEST_ROOT -I .
realiseContext(): Add derivation outputs to the allowed paths This makes import-from-derivation work in restricted mode again.
2018-02-06 16:38:45 +02:00
nix: Add --expr flag This replaces the '(...)' installable syntax, which is not very discoverable. The downside is that you can't have multiple expressions or mix expressions and other installables.
2019-11-27 01:05:30 +02:00
[[ $(nix eval --raw --impure --restrict-eval -I . --expr 'builtins.readFile "${import ./simple.nix}/hello"') == 'Hello World!' ]]
Fix symlink leak in restricted eval mode In EvalState::checkSourcePath, the path is checked against the list of allowed paths first and later it's checked again *after* resolving symlinks. The resolving of the symlinks is done via canonPath, which also strips out "../" and "./". However after the canonicalisation the error message pointing out that the path is not allowed prints the symlink target in the error message. Even if we'd suppress the message, symlink targets could still be leaked if the symlink target doesn't exist (in this case the error is thrown in canonPath). So instead, we now do canonPath() without symlink resolving first before even checking against the list of allowed paths and then later do the symlink resolving and checking the allowed paths again. The first call to canonPath() should get rid of all the "../" and "./", so in theory the only way to leak a symlink if the attacker is able to put a symlink in one of the paths allowed by restricted evaluation mode. For the latter I don't think this is part of the threat model, because if the attacker can write to that path, the attack vector is even larger. Signed-off-by: aszlig <aszlig@nix.build>
2018-08-03 07:24:57 +03:00
Check that we can't follow symlinks outside of the allowed paths
2023-12-05 16:14:28 +02:00
# Check that we can't follow a symlink outside of the allowed paths.
PosixSourceAccessor: Don't follow any symlinks All path components must not be symlinks now (so the user needs to call `resolveSymlinks()` when needed).
2023-12-06 00:02:59 +02:00
mkdir -p $TEST_ROOT/tunnel.d $TEST_ROOT/foo2
Check that we can't follow symlinks outside of the allowed paths
2023-12-05 16:14:28 +02:00
ln -sfn .. $TEST_ROOT/tunnel.d/tunnel
echo foo > $TEST_ROOT/bar
expectStderr 1 nix-instantiate --restrict-eval --eval -E "let __nixPath = [ { prefix = \"foo\"; path = $TEST_ROOT/tunnel.d; } ]; in builtins.readFile <foo/tunnel/bar>" -I $TEST_ROOT/tunnel.d | grepQuiet "forbidden in restricted mode"
PosixSourceAccessor: Don't follow any symlinks All path components must not be symlinks now (so the user needs to call `resolveSymlinks()` when needed).
2023-12-06 00:02:59 +02:00
expectStderr 1 nix-instantiate --restrict-eval --eval -E "let __nixPath = [ { prefix = \"foo\"; path = $TEST_ROOT/tunnel.d; } ]; in builtins.readDir <foo/tunnel/foo2>" -I $TEST_ROOT/tunnel.d | grepQuiet "forbidden in restricted mode"
# Reading the parents of allowed paths should show only the ancestors of the allowed paths.
[[ $(nix-instantiate --restrict-eval --eval -E "let __nixPath = [ { prefix = \"foo\"; path = $TEST_ROOT/tunnel.d; } ]; in builtins.readDir <foo/tunnel>" -I $TEST_ROOT/tunnel.d) == '{ "tunnel.d" = "directory"; }' ]]
Check that we can't follow symlinks outside of the allowed paths
2023-12-05 16:14:28 +02:00
Fix symlink leak in restricted eval mode In EvalState::checkSourcePath, the path is checked against the list of allowed paths first and later it's checked again *after* resolving symlinks. The resolving of the symlinks is done via canonPath, which also strips out "../" and "./". However after the canonicalisation the error message pointing out that the path is not allowed prints the symlink target in the error message. Even if we'd suppress the message, symlink targets could still be leaked if the symlink target doesn't exist (in this case the error is thrown in canonPath). So instead, we now do canonPath() without symlink resolving first before even checking against the list of allowed paths and then later do the symlink resolving and checking the allowed paths again. The first call to canonPath() should get rid of all the "../" and "./", so in theory the only way to leak a symlink if the attacker is able to put a symlink in one of the paths allowed by restricted evaluation mode. For the latter I don't think this is part of the threat model, because if the attacker can write to that path, the attack vector is even larger. Signed-off-by: aszlig <aszlig@nix.build>
2018-08-03 07:24:57 +03:00
# Check whether we can leak symlink information through directory traversal.
traverseDir="$(pwd)/restricted-traverse-me"
ln -sfn "$(pwd)/restricted-secret" "$(pwd)/restricted-innocent"
mkdir -p "$traverseDir"
goUp="..$(echo "$traverseDir" | sed -e 's,[^/]\+,..,g')"
output="$(nix eval --raw --restrict-eval -I "$traverseDir" \
nix: Add --expr flag This replaces the '(...)' installable syntax, which is not very discoverable. The downside is that you can't have multiple expressions or mix expressions and other installables.
2019-11-27 01:05:30 +02:00
--expr "builtins.readFile \"$traverseDir/$goUp$(pwd)/restricted-innocent\"" \
Fix symlink leak in restricted eval mode In EvalState::checkSourcePath, the path is checked against the list of allowed paths first and later it's checked again *after* resolving symlinks. The resolving of the symlinks is done via canonPath, which also strips out "../" and "./". However after the canonicalisation the error message pointing out that the path is not allowed prints the symlink target in the error message. Even if we'd suppress the message, symlink targets could still be leaked if the symlink target doesn't exist (in this case the error is thrown in canonPath). So instead, we now do canonPath() without symlink resolving first before even checking against the list of allowed paths and then later do the symlink resolving and checking the allowed paths again. The first call to canonPath() should get rid of all the "../" and "./", so in theory the only way to leak a symlink if the attacker is able to put a symlink in one of the paths allowed by restricted evaluation mode. For the latter I don't think this is part of the threat model, because if the attacker can write to that path, the attack vector is even larger. Signed-off-by: aszlig <aszlig@nix.build>
2018-08-03 07:24:57 +03:00
2>&1 || :)"
echo "$output" | grep "is forbidden"
Harden tests' bash Use `set -u` and `set -o pipefail` to catch accidental mistakes and failures more strongly. - `set -u` catches the use of undefined variables - `set -o pipefail` catches failures (like `set -e`) earlier in the pipeline. This makes the tests a bit more robust. It is nice to read code not worrying about these spurious success paths (via uncaught) errors undermining the tests. Indeed, I caught some bugs doing this. There are a few tests where we run a command that should fail, and then search its output to make sure the failure message is one that we expect. Before, since the `grep` was the last command in the pipeline the exit code of those failing programs was silently ignored. Now with `set -o pipefail` it won't be, and we have to do something so the expected failure doesn't accidentally fail the test. To do that we use `expect` and a new `expectStderr` to check for the exact failing exit code. See the comments on each for why. `grep -q` is replaced with `grepQuiet`, see the comments on that function for why. `grep -v` when we just want the exit code is replaced with `grepInverse, see the comments on that function for why. `grep -q -v` together is, surprise surprise, replaced with `grepQuietInverse`, which is both combined. Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
2021-12-09 17:26:46 +02:00
echo "$output" | grepInverse -F restricted-secret
Expanded test suite * Lang now verifies errors and parse output * Some new miscellaneous tests * Easy way to update the tests * Document workflow in manual * Use `!` not `~` as separater char for sed It is confusing to use `~` when we are talking about paths and home directories! * Test test suite itself (`test/lang-test/infra.sh`) Additionally, run shellcheck on `tests/lang.sh` to help ensure it is correct, now that is is more complex. Co-authored-by: Robert Hensing <roberth@users.noreply.github.com> Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
2015-09-04 23:23:08 +03:00
expectStderr 1 nix-instantiate --restrict-eval true ./dependencies.nix | grepQuiet "forbidden in restricted mode"
Reference in a new issue Copy permalink