mirror of
https://github.com/git/git.git
synced 2024-05-28 08:06:23 +02:00
a1d4f67c12
An earlier patch discussed and fixed a scenario where Git could be used
as a vector to exfiltrate sensitive data through a Docker container when
a potential victim clones a suspicious repository with local submodules
that contain symlinks.
That security hole has since been plugged, but a similar one still
exists. Instead of convincing a would-be victim to clone an embedded
submodule via the "file" protocol, an attacker could convince an
individual to clone a repository that has a submodule pointing to a
valid path on the victim's filesystem.
For example, if an individual (with username "foo") has their home
directory ("/home/foo") stored as a Git repository, then an attacker
could exfiltrate data by convincing a victim to clone a malicious
repository containing a submodule pointing at "/home/foo/.git" with
`--recurse-submodules`. Doing so would expose any sensitive contents in
stored in "/home/foo" tracked in Git.
For systems (such as Docker) that consider everything outside of the
immediate top-level working directory containing a Dockerfile as
inaccessible to the container (with the exception of volume mounts, and
so on), this is a violation of trust by exposing unexpected contents in
the working copy.
To mitigate the likelihood of this kind of attack, adjust the "file://"
protocol's default policy to be "user" to prevent commands that execute
without user input (including recursive submodule initialization) from
taking place by default.
Suggested-by: Jeff King <peff@peff.net>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
64 lines
2.1 KiB
Plaintext
64 lines
2.1 KiB
Plaintext
protocol.allow::
|
|
If set, provide a user defined default policy for all protocols which
|
|
don't explicitly have a policy (`protocol.<name>.allow`). By default,
|
|
if unset, known-safe protocols (http, https, git, ssh) have a
|
|
default policy of `always`, known-dangerous protocols (ext) have a
|
|
default policy of `never`, and all other protocols (including file)
|
|
have a default policy of `user`. Supported policies:
|
|
+
|
|
--
|
|
|
|
* `always` - protocol is always able to be used.
|
|
|
|
* `never` - protocol is never able to be used.
|
|
|
|
* `user` - protocol is only able to be used when `GIT_PROTOCOL_FROM_USER` is
|
|
either unset or has a value of 1. This policy should be used when you want a
|
|
protocol to be directly usable by the user but don't want it used by commands which
|
|
execute clone/fetch/push commands without user input, e.g. recursive
|
|
submodule initialization.
|
|
|
|
--
|
|
|
|
protocol.<name>.allow::
|
|
Set a policy to be used by protocol `<name>` with clone/fetch/push
|
|
commands. See `protocol.allow` above for the available policies.
|
|
+
|
|
The protocol names currently used by git are:
|
|
+
|
|
--
|
|
- `file`: any local file-based path (including `file://` URLs,
|
|
or local paths)
|
|
|
|
- `git`: the anonymous git protocol over a direct TCP
|
|
connection (or proxy, if configured)
|
|
|
|
- `ssh`: git over ssh (including `host:path` syntax,
|
|
`ssh://`, etc).
|
|
|
|
- `http`: git over http, both "smart http" and "dumb http".
|
|
Note that this does _not_ include `https`; if you want to configure
|
|
both, you must do so individually.
|
|
|
|
- any external helpers are named by their protocol (e.g., use
|
|
`hg` to allow the `git-remote-hg` helper)
|
|
--
|
|
|
|
protocol.version::
|
|
If set, clients will attempt to communicate with a server
|
|
using the specified protocol version. If the server does
|
|
not support it, communication falls back to version 0.
|
|
If unset, the default is `2`.
|
|
Supported versions:
|
|
+
|
|
--
|
|
|
|
* `0` - the original wire protocol.
|
|
|
|
* `1` - the original wire protocol with the addition of a version string
|
|
in the initial response from the server.
|
|
|
|
* `2` - link:technical/protocol-v2.html[wire protocol version 2].
|
|
|
|
--
|