From: Jeff King <peff@peff.net>
To: "Coiner, John" <John.Coiner@amd.com>
Cc: "git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: git, monorepos, and access control
Date: Wed, 5 Dec 2018 16:01:05 -0500 [thread overview]
Message-ID: <20181205210104.GC19936@sigill.intra.peff.net> (raw)
In-Reply-To: <939efd87-b2af-29d7-efdd-9cf8f6de9d10@amd.com>
On Wed, Dec 05, 2018 at 08:13:16PM +0000, Coiner, John wrote:
> One obstacle to moving AMD to git/VFSForGit is the lack of access
> control support in git. AMD has a lot of data whose distribution must be
> limited. Sometimes it's a legal requirement, eg. CPU core designs are
> covered by US export control laws and not all employees may see them.
> Sometimes it's a contractual obligation, as when a third party shares
> data with us and we agree only to share this data with certain
> employees. Any hypothetical AMD monorepo should be able to securely deny
> read access in certain subtrees to users without required permissions.
>
> Has anyone looked at adding access control to git, at a per-directory
> granularity? Is this a feature that the git community would possibly
> welcome?
In my opinion this feature is so contrary to Git's general assumptions
that it's likely to create a ton of information leaks of the supposedly
protected data.
For instance, Git is very eager to try to find delta-compression
opportunities between objects, even if they don't have any relationship
within the tree structure. So imagine I want to know the contents of
tree X. I push up a tree Y similar to X, then fetch it back, falsely
claiming to have X but not Y. If the server generates a delta, that may
reveal information about X (which you can then iterate to send Y', and
so on, treating the server as an oracle until you've guessed the content
of X).
You could work around that by teaching the server to refuse to use "X"
in any way when the client does not have the right permissions. But:
- that's just one example; there are probably a number of such leaks
- you're fighting an uphill battle against the way Git is implemented;
there's no single point to enforce this kind of segmentation
The model that fits more naturally with how Git is implemented would be
to use submodules. There you leak the hash of the commit from the
private submodule, but that's probably obscure enough (and if you're
really worried, you can add a random nonce to the commit messages in the
submodule to make their hashes unguessable).
> I would welcome your feedback on whether this idea makes technical
> sense, and whether the feature could ever be a fit for git.
Sorry I don't have a more positive response. What you want to do is
perfectly reasonable, but I just think it's a mismatch with how Git
works (and because of the security impact, one missed corner case
renders the whole thing useless).
-Peff
next prev parent reply other threads:[~2018-12-05 21:01 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-05 20:13 git, monorepos, and access control Coiner, John
2018-12-05 20:34 ` Ævar Arnfjörð Bjarmason
2018-12-05 20:43 ` Derrick Stolee
2018-12-05 20:58 ` Duy Nguyen
2018-12-05 21:12 ` Ævar Arnfjörð Bjarmason
2018-12-05 23:42 ` Coiner, John
2018-12-06 7:23 ` Jeff King
2018-12-05 21:01 ` Jeff King [this message]
2018-12-06 0:23 ` brian m. carlson
2018-12-06 1:08 ` Junio C Hamano
2018-12-06 7:20 ` Jeff King
2018-12-06 9:17 ` Ævar Arnfjörð Bjarmason
2018-12-06 9:30 ` Jeff King
2018-12-06 20:08 ` Johannes Schindelin
2018-12-06 22:15 ` Stefan Beller
2018-12-06 22:59 ` Coiner, John
2018-12-05 22:37 ` Ævar Arnfjörð Bjarmason
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181205210104.GC19936@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=John.Coiner@amd.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).