Comment by Lockal
6 days ago
"trivial modification of an existing exploit"...
Why git does not use Landlock? I know it is Linux-only, but why? "git clone" should only have r/o access to config directory and r/w to clone directory. And no subprocesses. In every exploit demo: "Yep, <s>it goes to a square hole</s> it launches a calculator".
> no subprocesses
I guess you're okay with breaking all git hooks, including post-checkout, because those are subprocesses as a feature.
You can always run your git operations in a container with seccomp or such if you're not using any of the many features that it breaks
This would also break custom commands. Which if you don't know about it, is a pretty cool feature.
Drop a git-something executable in your path and you can execute it as git something.
Why is this helpful? Just add the executable itself to path and execute it with "something" instead of "git something". Why are we making git an intermediary ? I am kind of stupid and this is genuine.
6 replies →
> And no subprocesses.
have you never used git over ssh?
The problem with Landlock, AFAIU, is that it's inherited across exec. OpenBSD's pledge and unveil were deliberately designed to reset across exec by default precisely because the "more secure" behavior makes it difficult or impossible to add to alot of existing code that needs to invoke other programs. It could be done in theory--e.g. by forking a helper process prior to locking down--but that requires a significant refactor all its own, so what ends up happening is that people just abstain from using seccomp or Landlock. Whereas all OpenBSD core utils were quickly modified to make use of pledge and unveil to some extent, and then over time improved to tighten things further; they were designed to permit and promote this sort of easy, incremental deployment.
I don't know the extent to which Landlock or even unveil would have helped here; maybe they would have only prevented the hook from running during the clone, but not subsequently when it's expected trusted hooks to run. But I'd bet adding unveil support to Git would be an easier task, notwithstanding (or even because of) the way Git invokes subprocesses.