transport: add a protocol-whitelist environment variable
If we are cloning an untrusted remote repository into a
sandbox, we may also want to fetch remote submodules in
order to get the complete view as intended by the other
side. However, that opens us up to attacks where a malicious
user gets us to clone something they would not otherwise
have access to (this is not necessarily a problem by itself,
but we may then act on the cloned contents in a way that
exposes them to the attacker).
Ideally such a setup would sandbox git entirely away from
high-value items, but this is not always practical or easy
to set up (e.g., OS network controls may block multiple
protocols, and we would want to enable some but not others).
We can help this case by providing a way to restrict
particular protocols. We use a whitelist in the environment.
This is more annoying to set up than a blacklist, but
defaults to safety if the set of protocols git supports
grows). If no whitelist is specified, we continue to default
to allowing all protocols (this is an "unsafe" default, but
since the minority of users will want this sandboxing
effect, it is the only sensible one).
A note on the tests: ideally these would all be in a single
test file, but the git-daemon and httpd test infrastructure
is an all-or-nothing proposition rather than a test-by-test
prerequisite. By putting them all together, we would be
unable to test the file-local code on machines without
apache.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-16 17:12:52 +00:00
|
|
|
#!/bin/sh
|
|
|
|
|
|
|
|
|
|
test_description='test disabling of git-over-ssh in clone/fetch'
|
|
|
|
|
. ./test-lib.sh
|
|
|
|
|
. "$TEST_DIRECTORY/lib-proto-disable.sh"
|
|
|
|
|
|
|
|
|
|
setup_ssh_wrapper
|
|
|
|
|
|
|
|
|
|
test_expect_success 'setup repository to clone' '
|
|
|
|
|
test_commit one &&
|
|
|
|
|
mkdir remote &&
|
|
|
|
|
git init --bare remote/repo.git &&
|
|
|
|
|
git push remote/repo.git HEAD
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_proto "host:path" ssh "remote:repo.git"
|
2015-11-09 17:49:35 +00:00
|
|
|
test_proto "ssh://" ssh "ssh://remote$PWD/remote/repo.git"
|
|
|
|
|
test_proto "git+ssh://" ssh "git+ssh://remote$PWD/remote/repo.git"
|
transport: add a protocol-whitelist environment variable
If we are cloning an untrusted remote repository into a
sandbox, we may also want to fetch remote submodules in
order to get the complete view as intended by the other
side. However, that opens us up to attacks where a malicious
user gets us to clone something they would not otherwise
have access to (this is not necessarily a problem by itself,
but we may then act on the cloned contents in a way that
exposes them to the attacker).
Ideally such a setup would sandbox git entirely away from
high-value items, but this is not always practical or easy
to set up (e.g., OS network controls may block multiple
protocols, and we would want to enable some but not others).
We can help this case by providing a way to restrict
particular protocols. We use a whitelist in the environment.
This is more annoying to set up than a blacklist, but
defaults to safety if the set of protocols git supports
grows). If no whitelist is specified, we continue to default
to allowing all protocols (this is an "unsafe" default, but
since the minority of users will want this sandboxing
effect, it is the only sensible one).
A note on the tests: ideally these would all be in a single
test file, but the git-daemon and httpd test infrastructure
is an all-or-nothing proposition rather than a test-by-test
prerequisite. By putting them all together, we would be
unable to test the file-local code on machines without
apache.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-16 17:12:52 +00:00
|
|
|
|
2017-07-28 19:23:32 +00:00
|
|
|
# Don't even bother setting up a "-remote" directory, as ssh would generally
|
|
|
|
|
# complain about the bogus option rather than completing our request. Our
|
|
|
|
|
# fake wrapper actually _can_ handle this case, but it's more robust to
|
|
|
|
|
# simply confirm from its output that it did not run at all.
|
|
|
|
|
test_expect_success 'hostnames starting with dash are rejected' '
|
|
|
|
|
test_must_fail git clone ssh://-remote/repo.git dash-host 2>stderr &&
|
|
|
|
|
! grep ^ssh: stderr
|
|
|
|
|
'
|
|
|
|
|
|
2017-07-28 19:28:55 +00:00
|
|
|
test_expect_success 'setup repo with dash' '
|
|
|
|
|
git init --bare remote/-repo.git &&
|
|
|
|
|
git push remote/-repo.git HEAD
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'repo names starting with dash are rejected' '
|
|
|
|
|
test_must_fail git clone remote:-repo.git dash-path 2>stderr &&
|
|
|
|
|
! grep ^ssh: stderr
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'full paths still work' '
|
|
|
|
|
git clone "remote:$PWD/remote/-repo.git" dash-path
|
|
|
|
|
'
|
|
|
|
|
|
transport: add a protocol-whitelist environment variable
If we are cloning an untrusted remote repository into a
sandbox, we may also want to fetch remote submodules in
order to get the complete view as intended by the other
side. However, that opens us up to attacks where a malicious
user gets us to clone something they would not otherwise
have access to (this is not necessarily a problem by itself,
but we may then act on the cloned contents in a way that
exposes them to the attacker).
Ideally such a setup would sandbox git entirely away from
high-value items, but this is not always practical or easy
to set up (e.g., OS network controls may block multiple
protocols, and we would want to enable some but not others).
We can help this case by providing a way to restrict
particular protocols. We use a whitelist in the environment.
This is more annoying to set up than a blacklist, but
defaults to safety if the set of protocols git supports
grows). If no whitelist is specified, we continue to default
to allowing all protocols (this is an "unsafe" default, but
since the minority of users will want this sandboxing
effect, it is the only sensible one).
A note on the tests: ideally these would all be in a single
test file, but the git-daemon and httpd test infrastructure
is an all-or-nothing proposition rather than a test-by-test
prerequisite. By putting them all together, we would be
unable to test the file-local code on machines without
apache.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-16 17:12:52 +00:00
|
|
|
test_done
|