setup.c: create `safe.bareRepository`
There is a known social engineering attack that takes advantage of the
fact that a working tree can include an entire bare repository,
including a config file. A user could run a Git command inside the bare
repository thinking that the config file of the 'outer' repository would
be used, but in reality, the bare repository's config file (which is
attacker-controlled) is used, which may result in arbitrary code
execution. See [1] for a fuller description and deeper discussion.
A simple mitigation is to forbid bare repositories unless specified via
`--git-dir` or `GIT_DIR`. In environments that don't use bare
repositories, this would be minimally disruptive.
Create a config variable, `safe.bareRepository`, that tells Git whether
or not to die() when working with a bare repository. This config is an
enum of:
- "all": allow all bare repositories (this is the default)
- "explicit": only allow bare repositories specified via --git-dir
or GIT_DIR.
If we want to protect users from such attacks by default, neither value
will suffice - "all" provides no protection, but "explicit" is
impractical for bare repository users. A more usable default would be to
allow only non-embedded bare repositories ([2] contains one such
proposal), but detecting if a repository is embedded is potentially
non-trivial, so this work is not implemented in this series.
[1]: https://lore.kernel.org/git/kl6lsfqpygsj.fsf@chooglen-macbookpro.roam.corp.google.com
[2]: https://lore.kernel.org/git/5b969c5e-e802-c447-ad25-6acc0b784582@github.com
Signed-off-by: Glen Choo <chooglen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-07-14 23:28:01 +02:00
|
|
|
safe.bareRepository::
|
|
|
|
Specifies which bare repositories Git will work with. The currently
|
|
|
|
supported values are:
|
|
|
|
+
|
|
|
|
* `all`: Git works with all bare repositories. This is the default.
|
|
|
|
* `explicit`: Git only works with bare repositories specified via
|
|
|
|
the top-level `--git-dir` command-line option, or the `GIT_DIR`
|
|
|
|
environment variable (see linkgit:git[1]).
|
|
|
|
+
|
|
|
|
If you do not use bare repositories in your workflow, then it may be
|
|
|
|
beneficial to set `safe.bareRepository` to `explicit` in your global
|
|
|
|
config. This will protect you from attacks that involve cloning a
|
|
|
|
repository that contains a bare repository and running a Git command
|
|
|
|
within that directory.
|
|
|
|
+
|
|
|
|
This config setting is only respected in protected configuration (see
|
|
|
|
<<SCOPES>>). This prevents the untrusted repository from tampering with
|
|
|
|
this value.
|
|
|
|
|
2022-03-02 12:23:04 +01:00
|
|
|
safe.directory::
|
|
|
|
These config entries specify Git-tracked directories that are
|
|
|
|
considered safe even if they are owned by someone other than the
|
|
|
|
current user. By default, Git will refuse to even parse a Git
|
|
|
|
config of a repository owned by someone else, let alone run its
|
|
|
|
hooks, and this config setting allows users to specify exceptions,
|
|
|
|
e.g. for intentionally shared repositories (see the `--shared`
|
|
|
|
option in linkgit:git-init[1]).
|
|
|
|
+
|
|
|
|
This is a multi-valued setting, i.e. you can add more than one directory
|
|
|
|
via `git config --add`. To reset the list of safe directories (e.g. to
|
|
|
|
override any such directories specified in the system config), add a
|
|
|
|
`safe.directory` entry with an empty value.
|
|
|
|
+
|
2022-07-14 23:28:00 +02:00
|
|
|
This config setting is only respected in protected configuration (see
|
|
|
|
<<SCOPES>>). This prevents the untrusted repository from tampering with this
|
|
|
|
value.
|
2022-03-02 12:23:04 +01:00
|
|
|
+
|
|
|
|
The value of this setting is interpolated, i.e. `~/<path>` expands to a
|
|
|
|
path relative to the home directory and `%(prefix)/<path>` expands to a
|
|
|
|
path relative to Git's (runtime) prefix.
|
2022-04-13 17:32:31 +02:00
|
|
|
+
|
|
|
|
To completely opt-out of this security check, set `safe.directory` to the
|
|
|
|
string `*`. This will allow all repositories to be treated as if their
|
|
|
|
directory was listed in the `safe.directory` list. If `safe.directory=*`
|
|
|
|
is set in system config and you want to re-enable this protection, then
|
|
|
|
initialize your list with an empty value before listing the repositories
|
|
|
|
that you deem safe.
|
git-compat-util: avoid failing dir ownership checks if running privileged
bdc77d1d685 (Add a function to determine whether a path is owned by the
current user, 2022-03-02) checks for the effective uid of the running
process using geteuid() but didn't account for cases where that user was
root (because git was invoked through sudo or a compatible tool) and the
original uid that repository trusted for its config was no longer known,
therefore failing the following otherwise safe call:
guy@renard ~/Software/uncrustify $ sudo git describe --always --dirty
[sudo] password for guy:
fatal: unsafe repository ('/home/guy/Software/uncrustify' is owned by someone else)
Attempt to detect those cases by using the environment variables that
those tools create to keep track of the original user id, and do the
ownership check using that instead.
This assumes the environment the user is running on after going
privileged can't be tampered with, and also adds code to restrict that
the new behavior only applies if running as root, therefore keeping the
most common case, which runs unprivileged, from changing, but because of
that, it will miss cases where sudo (or an equivalent) was used to change
to another unprivileged user or where the equivalent tool used to raise
privileges didn't track the original id in a sudo compatible way.
Because of compatibility with sudo, the code assumes that uid_t is an
unsigned integer type (which is not required by the standard) but is used
that way in their codebase to generate SUDO_UID. In systems where uid_t
is signed, sudo might be also patched to NOT be unsigned and that might
be able to trigger an edge case and a bug (as described in the code), but
it is considered unlikely to happen and even if it does, the code would
just mostly fail safely, so there was no attempt either to detect it or
prevent it by the code, which is something that might change in the future,
based on expected user feedback.
Reported-by: Guy Maurel <guy.j@maurel.de>
Helped-by: SZEDER Gábor <szeder.dev@gmail.com>
Helped-by: Randall Becker <rsbecker@nexbridge.com>
Helped-by: Phillip Wood <phillip.wood123@gmail.com>
Suggested-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-05-13 03:00:18 +02:00
|
|
|
+
|
|
|
|
As explained, Git only allows you to access repositories owned by
|
|
|
|
yourself, i.e. the user who is running Git, by default. When Git
|
|
|
|
is running as 'root' in a non Windows platform that provides sudo,
|
2022-06-17 22:23:38 +02:00
|
|
|
however, git checks the SUDO_UID environment variable that sudo creates
|
|
|
|
and will allow access to the uid recorded as its value in addition to
|
|
|
|
the id from 'root'.
|
git-compat-util: avoid failing dir ownership checks if running privileged
bdc77d1d685 (Add a function to determine whether a path is owned by the
current user, 2022-03-02) checks for the effective uid of the running
process using geteuid() but didn't account for cases where that user was
root (because git was invoked through sudo or a compatible tool) and the
original uid that repository trusted for its config was no longer known,
therefore failing the following otherwise safe call:
guy@renard ~/Software/uncrustify $ sudo git describe --always --dirty
[sudo] password for guy:
fatal: unsafe repository ('/home/guy/Software/uncrustify' is owned by someone else)
Attempt to detect those cases by using the environment variables that
those tools create to keep track of the original user id, and do the
ownership check using that instead.
This assumes the environment the user is running on after going
privileged can't be tampered with, and also adds code to restrict that
the new behavior only applies if running as root, therefore keeping the
most common case, which runs unprivileged, from changing, but because of
that, it will miss cases where sudo (or an equivalent) was used to change
to another unprivileged user or where the equivalent tool used to raise
privileges didn't track the original id in a sudo compatible way.
Because of compatibility with sudo, the code assumes that uid_t is an
unsigned integer type (which is not required by the standard) but is used
that way in their codebase to generate SUDO_UID. In systems where uid_t
is signed, sudo might be also patched to NOT be unsigned and that might
be able to trigger an edge case and a bug (as described in the code), but
it is considered unlikely to happen and even if it does, the code would
just mostly fail safely, so there was no attempt either to detect it or
prevent it by the code, which is something that might change in the future,
based on expected user feedback.
Reported-by: Guy Maurel <guy.j@maurel.de>
Helped-by: SZEDER Gábor <szeder.dev@gmail.com>
Helped-by: Randall Becker <rsbecker@nexbridge.com>
Helped-by: Phillip Wood <phillip.wood123@gmail.com>
Suggested-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-05-13 03:00:18 +02:00
|
|
|
This is to make it easy to perform a common sequence during installation
|
|
|
|
"make && sudo make install". A git process running under 'sudo' runs as
|
|
|
|
'root' but the 'sudo' command exports the environment variable to record
|
|
|
|
which id the original user has.
|
|
|
|
If that is not what you would prefer and want git to only trust
|
2022-06-17 22:23:38 +02:00
|
|
|
repositories that are owned by root instead, then you can remove
|
git-compat-util: avoid failing dir ownership checks if running privileged
bdc77d1d685 (Add a function to determine whether a path is owned by the
current user, 2022-03-02) checks for the effective uid of the running
process using geteuid() but didn't account for cases where that user was
root (because git was invoked through sudo or a compatible tool) and the
original uid that repository trusted for its config was no longer known,
therefore failing the following otherwise safe call:
guy@renard ~/Software/uncrustify $ sudo git describe --always --dirty
[sudo] password for guy:
fatal: unsafe repository ('/home/guy/Software/uncrustify' is owned by someone else)
Attempt to detect those cases by using the environment variables that
those tools create to keep track of the original user id, and do the
ownership check using that instead.
This assumes the environment the user is running on after going
privileged can't be tampered with, and also adds code to restrict that
the new behavior only applies if running as root, therefore keeping the
most common case, which runs unprivileged, from changing, but because of
that, it will miss cases where sudo (or an equivalent) was used to change
to another unprivileged user or where the equivalent tool used to raise
privileges didn't track the original id in a sudo compatible way.
Because of compatibility with sudo, the code assumes that uid_t is an
unsigned integer type (which is not required by the standard) but is used
that way in their codebase to generate SUDO_UID. In systems where uid_t
is signed, sudo might be also patched to NOT be unsigned and that might
be able to trigger an edge case and a bug (as described in the code), but
it is considered unlikely to happen and even if it does, the code would
just mostly fail safely, so there was no attempt either to detect it or
prevent it by the code, which is something that might change in the future,
based on expected user feedback.
Reported-by: Guy Maurel <guy.j@maurel.de>
Helped-by: SZEDER Gábor <szeder.dev@gmail.com>
Helped-by: Randall Becker <rsbecker@nexbridge.com>
Helped-by: Phillip Wood <phillip.wood123@gmail.com>
Suggested-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-05-13 03:00:18 +02:00
|
|
|
the `SUDO_UID` variable from root's environment before invoking git.
|