Re: [PATCH v3 1/5] Documentation: define protected configuration

[Derrick Stolee <derrickstolee@github.com>]

On 5/27/2022 7:29 PM, Junio C Hamano wrote:
> "Glen Choo via GitGitGadget" <gitgitgadget@gmail.com> writes:
>> +[[def_protected_config]]protected configuration::
>> +	Protected configuration is configuration that Git considers more
>> +	trustworthy because it is unlikely to be tampered with by an
>> +	attacker. For security reasons, some configuration variables are
>> +	only respected when they are defined in protected configuration.
>> ++
>> +Protected configuration includes:
>> ++
>> +- system-level config, e.g. `/etc/git/config`
>> +- global config, e.g. `$XDG_CONFIG_HOME/git/config` and
>> +  `$HOME/.gitconfig`
>> +Protected configuration excludes:
>> ++
>> +- repository config, e.g. `$GIT_DIR/config` and
>> +  `$GIT_DIR/config.worktree`
>> +- the command line option `-c` and its equivalent environment variables
> 
> The description is a bit unclear what "protected configuration"
> refers.
> 
> If it is the scopes (as in "git config --show-scope") Git can trust
> more, in other words, a statement like this
> 
>     safe.directory is honored only when it comes from a protected
>     configuration.
> 
> is what you want to make easier to write by introducing a new
> phrase, perhaps use the word "scope" for more consistency?  E.g.
> 
>     Only safe.directory that is defined in a trusted scope is
>     honored.
> 
> I dunno.
> 
> It would make sense to give a rationale behind the seemingly
> arbitrary choice of what is and what is not "protected".  Not
> necessarily in the glossary, but in the proposed log message of the
> commit that makes the decision.  The rationale must help readers to
> be able to answer the following questions.
> 
>  - The system level is "protected" because?  Is it because we do not
>    even try to protect ourselves from those who can write anywhere
>    in /etc/ or other system directories?
> 
>  - The per-user config is "protected" because?  Is it because our
>    primary interest in "protection" is to protect individual users
>    from landmines laid in the filesystem by other users, and those
>    who can already write into $HOME are not we try to guard against?

I think the answers to these two questions is "yes", so they can
be turned into an affirmative sentence:

	We do not event try to protect ourselves from those who can
	write anywhere...

>  - The per-repo config is not "protected" (i.e. "trusted"), because?
>    If we are not honoring a configuration in the repository, why are
>    we working in that repository in the first place?

This requires an example:

	Some workflows use repositories stored in shared directories,
	which are writable by multiple unprivileged users.
 
>  - The per invocation config is not "protected" (i.e. "trusted"),
>    because?  If we cannot trusting our own command line, what
>    prevents an attacker from mucking with our command line to say
>    "sudo whatever" using the same attack vector?

With this argument, I agree that -c config can be considered
protected. At the very least, it is visible to the user when they
are running a command. This would unify our expectations with
uploadPack.packObjectsHook, too.

Thanks,
-Stolee