{"thread":{"id":"43306","subject":"Re: Locked down (but still shared) repositories","startedAt":"2006-12-07T11:35:39Z","lastAt":"2006-12-07T20:32:07Z","messageCount":8,"participants":["Shawn Pearce","Johannes Schindelin","Randal L. Schwartz","Rogan Dawes","Martin Waitz"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"294643","messageId":"20061207113539.GA10781@spearce.org","threadId":"43306","inReplyTo":null,"subject":"Locked down (but still shared) repositories","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-07T11:35:39Z","receivedAt":"2006-12-07T11:35:39Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"I have a number of repositories that I want to share across a number\nof users on the same UNIX system.\n\nFor various auditing reasons the repositories need to be tightly\ncontrolled. That is the following cannot be permitted:\n\n * delete or overwrite a loose object;\n * delete or overwrite a pack file;\n * delete or overwrite a ref, except see below;\n * change the config;\n * change the description;\n * change HEAD;\n\nThe only changes that are permissible can be made through\ngit-receive-pack, which limits the user to only the following:\n\n * upload (possibly new) objects;\n * create/update/force-update a ref;\n * delete a ref;\n\nAnd the latter two are controlled by a very strict update hook.\nThe update hook checks the ref name and real user id against\nan ACL file (info/allowed-users) and checks to see if the user\ncan perform the requested operation against that ref, with four\noperations being recognized:\n\n * A == the ref is being created;\n * U == the ref is being fast-forwarded;\n * R == the ref is being rewound/reset;\n * D == the ref is being deleted;\n\nThe update hook also requires that all lines returned by:\n\n git-rev-list --pretty=raw $3 --not --all | egrep ^committer\n\ncorrespond to a name/email address combination registered in another\ntable for the real user id (info/allowed-committers). Which means\nwe can actually trust the committer field of all commits which\nare referenced by refs, as the UNIX system authenticated them.\nThe tagger field is also checked for every tag, but its slightly\nmore involved than the simple line above as it peels back the tag\nlayers as needed. :)\n\nSo the update hook is update-hook-example.txt, but suffering from\nextreme paranoia and has been put on steriods. I'm considering\nsending it in for Documentation/howto, or contrib.\n\n\nWhich brings me to the following problem:\n\nI can't create the repository with --shared, as the UNIX users\nall have normal shell access to the system. (/bin/rm would work\nwonders to let a user violate a number of the items above.)\n\nI also cannot create secondary git-only UNIX accounts for each user,\nusing git-shell in the git-only account. (For example \"spearce\"\nand \"spearce-git\", with the latter using git-shell and being in a\ngroup which does have repository access, while the former doesn't.)\n\nThe workaround that I have come up with is the following:\n\nThe repositories are all owned by a single user, and were created\nwithout --shared, so only the owner can modify the repository.\nThe repositories are however readable by a specific group, and\nall permitted users of that repository are members of that group.\nSo they can read the repository files directory, which works very\nwell with objects/info/alternates. :-)\n\ngit-receive-pack on this system is owned by the same repository\nowner, and is also marked setuid. Consequently when a user pushes\ninto a repository the effective uid is that of the repository owner,\nobjects can be written, refs can be changed, the update hook runs\nsetuid, and it enforces everything.\n\n\nThe problem now is what happens when users try to use Git\nas a distributed tool and push changes between their own two\nrepositories? Even if the two specific users can agree on using\n--shared (because maybe they actually read the Git manual and want\nto use that feature), git-receive-pack runs setuid as the blessed\nrepository user. Any update hook installed within one of these\n'user private' repositories is untrusted, but will be running with\nenough permissions to run /bin/rm and destroy data. See above\nabout how I can't have that...\n\nSo I've patched git-receive-pack to refuse to run if its running\nsetuid and the hook's owner isn't the effective uid, or the hook\nis group/world writable. This seems to close the last hole, but\nit also makes hooks/update and hooks/post-update useless in user\nprivate repositories on this system.\n\n\nI'm sending this to try and solicit better ideas from the mailing\nlist. We have a lot of UNIX guru types, and a lot of Git guru types,\nand they are all smarter than I... ;-)\n\n-- \n"},{"id":"296747","messageId":"20061207122111.GD10468@admingilde.org","threadId":"43306","inReplyTo":"20061207113539.GA10781@spearce.org","subject":"Re: Locked down (but still shared) repositories","fromName":"Martin Waitz","fromEmail":"tali@admingilde.org","sentAt":"2006-12-07T12:21:11Z","receivedAt":"2006-12-07T12:21:11Z","isPatch":false,"sender":{"key":"tali@admingilde.org","avatar":"https://gravatar.com/avatar/3f89b03eee362187effabe257898735b475673a12265c398ea9161259ae91553?d=mp&s=160"},"body":"hoi :)\n\nOn Thu, Dec 07, 2006 at 06:35:39AM -0500, Shawn Pearce wrote:\n> So I've patched git-receive-pack to refuse to run if its running\n> setuid and the hook's owner isn't the effective uid, or the hook\n> is group/world writable. This seems to close the last hole, but\n> it also makes hooks/update and hooks/post-update useless in user\n> private repositories on this system.\n\nperhaps don't refuse to run, but simply change back to the safed uid?\nOr use one special machine which hosts the repository and which has\nthe modified version of git installed.\n\n-- \nMartin Waitz\n"},{"id":"294431","messageId":"Pine.LNX.4.63.0612071640160.28348@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43306","inReplyTo":"20061207113539.GA10781@spearce.org","subject":"Re: Locked down (but still shared) repositories","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-12-07T15:42:43Z","receivedAt":"2006-12-07T15:42:43Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 7 Dec 2006, Shawn Pearce wrote:\n\n> For various auditing reasons the repositories need to be tightly\n> controlled. That is the following cannot be permitted:\n> \n> * delete or overwrite a loose object;\n> * delete or overwrite a pack file;\n> * delete or overwrite a ref, except see below;\n> * change the config;\n> * change the description;\n> * change HEAD;\n> \n> [...]\n>\n> I also cannot create secondary git-only UNIX accounts for each user,\n> using git-shell in the git-only account.\n\nHow about just one such user? After all, you already have this user: the \nrepo owner. Of course, people have to push via ssh, even on the same \nmachine.\n\nCiao,\nDscho\n"},{"id":"294287","messageId":"20061207191730.GA12143@spearce.org","threadId":"43306","inReplyTo":"Pine.LNX.4.63.0612071640160.28348@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Locked down (but still shared) repositories","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-07T19:17:30Z","receivedAt":"2006-12-07T19:17:30Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Johannes Schindelin wrote:\n> On Thu, 7 Dec 2006, Shawn Pearce wrote:\n> \n> > For various auditing reasons the repositories need to be tightly\n> > controlled. That is the following cannot be permitted:\n> > \n> > [...]\n> \n> How about just one such user? After all, you already have this user: the \n> repo owner. Of course, people have to push via ssh, even on the same \n> machine.\n\nHow do I know which SSH key the client used to connect? Remember I'm\nlooking at the real uid to determine who is performing the operation.\nIn the situation you describe everyone looks the same to the\nupdate hook...\n\nFor (probably stupid) reasons the server is the commerial F-Secure\nSSH server, btw. So OpenSSH based things wouldn't apply. And best\nthat I can tell, F-Secure SSH won't tell me which key was used\nto authenticate.\n\n-- \n"},{"id":"296741","messageId":"45786F5A.6020400@dawes.za.net","threadId":"43306","inReplyTo":"20061207191730.GA12143@spearce.org","subject":"Re: Locked down (but still shared) repositories","fromName":"Rogan Dawes","fromEmail":"discard@dawes.za.net","sentAt":"2006-12-07T19:45:30Z","receivedAt":"2006-12-07T19:45:30Z","isPatch":false,"sender":{"key":"discard@dawes.za.net","avatar":null},"body":"Shawn Pearce wrote:\n> Johannes Schindelin wrote:\n>> On Thu, 7 Dec 2006, Shawn Pearce wrote:\n>>\n>>> For various auditing reasons the repositories need to be tightly\n>>> controlled. That is the following cannot be permitted:\n>>>\n>>> [...]\n>> How about just one such user? After all, you already have this user: the \n>> repo owner. Of course, people have to push via ssh, even on the same \n>> machine.\n> \n> How do I know which SSH key the client used to connect? Remember I'm\n> looking at the real uid to determine who is performing the operation.\n> In the situation you describe everyone looks the same to the\n> update hook...\n> \n> For (probably stupid) reasons the server is the commerial F-Secure\n> SSH server, btw. So OpenSSH based things wouldn't apply. And best\n> that I can tell, F-Secure SSH won't tell me which key was used\n> to authenticate.\n> \n\nSee Section 8.2.6.1\n\nhttp://www.unix.org.ua/orelly/networking_2ndEd/ssh/ch08_02.htm\n\nYou should be able to do something similar for git as they do for SSH.\n\nRogan\n"},{"id":"295259","messageId":"20061207201625.GA12502@spearce.org","threadId":"43306","inReplyTo":"45786F5A.6020400@dawes.za.net","subject":"Re: Locked down (but still shared) repositories","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-07T20:16:25Z","receivedAt":"2006-12-07T20:16:25Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Rogan Dawes wrote:\n> Shawn Pearce wrote:\n> >In the situation you describe everyone looks the same to the\n> >update hook...\n> \n> See Section 8.2.6.1\n> \n> http://www.unix.org.ua/orelly/networking_2ndEd/ssh/ch08_02.htm\n> \n> You should be able to do something similar for git as they do for SSH.\n\nOk, I just learned something new. Thank you!\n\nForced commands on a per-key basis would certainly work. I'm not\nsettled on the idea as the end solution, but it does seem to be\nperhaps slightly better than the setuid approach.\n\n-- \n"},{"id":"294960","messageId":"86irgnihqf.fsf@blue.stonehenge.com","threadId":"43306","inReplyTo":"45786F5A.6020400@dawes.za.net","subject":"Re: Locked down (but still shared) repositories","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2006-12-07T20:16:56Z","receivedAt":"2006-12-07T20:16:56Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Rogan\" == Rogan Dawes writes:\n\nRogan> See Section 8.2.6.1\n\nRogan> http://[deleted]/orelly/networking_2ndEd/ssh/ch08_02.htm\n\nPlease don't point to pirated copies of O'Reilly (or other) books\non the web, especially when there are authors (like me) present.\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n \nPerl/Unix/security consulting, Technical writing, Comedy, etc. etc.\n"},{"id":"295480","messageId":"45787A47.8080003@dawes.za.net","threadId":"43306","inReplyTo":"86irgnihqf.fsf@blue.stonehenge.com","subject":"Re: Locked down (but still shared) repositories","fromName":"Rogan Dawes","fromEmail":"discard@dawes.za.net","sentAt":"2006-12-07T20:32:07Z","receivedAt":"2006-12-07T20:32:07Z","isPatch":false,"sender":{"key":"discard@dawes.za.net","avatar":null},"body":"Randal L. Schwartz wrote:\n>>>>>> \"Rogan\" == Rogan Dawes writes:\n> \n> Rogan> See Section 8.2.6.1\n> \n> Rogan> http://[deleted]/orelly/networking_2ndEd/ssh/ch08_02.htm\n> \n> Please don't point to pirated copies of O'Reilly (or other) books\n> on the web, especially when there are authors (like me) present.\n> \n\nOops. I didn't realise/think. I just googled for the keywords I needed . . .\n\nNot a very good excuse, I admit.\n\nSorry.\n\nRogan\n"}]}