{"thread":{"id":"16650","subject":"is gitosis secure?","startedAt":"2008-12-09T08:56:48Z","lastAt":"2009-02-05T08:04:19Z","messageCount":41,"participants":["Thomas Koch","Sverre Rabbelier","R. Tyler Ballance","Garry Dolley","Sam Vilain","Nix","Sitaram Chamarty","david@lang.hm","martin","Jakub Narebski","Asheesh Laroia","Rogan Dawes","Mike Hommey","Tait","Florian Weimer","Boyd Stephen Smith Jr.","Tommi Virtanen","Stephen R. van den Berg"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"97410","messageId":"200812090956.48613.thomas@koch.ro","threadId":"16650","inReplyTo":null,"subject":"is gitosis secure?","fromName":"Thomas Koch","fromEmail":"thomas@koch.ro","sentAt":"2008-12-09T08:56:48Z","receivedAt":"2008-12-09T08:56:48Z","isPatch":false,"sender":{"key":"thomas@koch.ro","avatar":null},"body":"Sorry for the shameless subject, but I presented gitosis yesterday to\nour sysadmin and he wasn't much delighted to learn, that write access to\nrepositories hosted with gitosis would need SSH access.\n\nSo could you help me out in this discussion, whether to use or not to\nuse gitosis? \nOur admin would prefer to not open SSH at all outside our LAN, but\ndevelopers would need to have write access also outside the office.\n\nBest regards,\n-- \nThomas Koch, Software Developer\nhttp://www.koch.ro\n\nYoung Media Concepts GmbH\nSonnenstr. 4\nCH-8280 Kreuzlingen\nSwitzerland\n\nTel +41 (0)71 / 508 24 86\nFax +41 (0)71 / 560 53 89\nMobile +49 (0)170 / 753 89 16\nWeb www.ymc.ch\n"},{"id":"97453","messageId":"1228813453.28186.73.camel@maia.lan","threadId":"16650","inReplyTo":"200812090956.48613.thomas@koch.ro","subject":"Re: is gitosis secure?","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2008-12-09T09:04:13Z","receivedAt":"2008-12-09T09:04:13Z","isPatch":false,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"On Tue, 2008-12-09 at 09:56 +0100, Thomas Koch wrote:\n> Sorry for the shameless subject, but I presented gitosis yesterday to\n> our sysadmin and he wasn't much delighted to learn, that write access to\n> repositories hosted with gitosis would need SSH access.\n> \n> So could you help me out in this discussion, whether to use or not to\n> use gitosis? \n> Our admin would prefer to not open SSH at all outside our LAN, but\n> developers would need to have write access also outside the office.\n\nRestricted unix shells are a technology which has been proven secure for\ndecades now. If you use git-shell, you are keeping the secure part of\nSSH - the authentication and encryption - and restricting the SSH access\npart to the bare minimum required for useful access to the required\nservices.\n\nie ... it all comes down to the shell you give those 'login' users as to\nwhat they can do.\n\nSam.\n"},{"id":"97414","messageId":"1228813620.18611.41.camel@starfruit.local","threadId":"16650","inReplyTo":"200812090956.48613.thomas@koch.ro","subject":"Re: is gitosis secure?","fromName":"R. Tyler Ballance","fromEmail":"tyler@slide.com","sentAt":"2008-12-09T09:07:00Z","receivedAt":"2008-12-09T09:07:00Z","isPatch":false,"sender":{"key":"tyler@slide.com","avatar":null},"body":"On Tue, 2008-12-09 at 09:56 +0100, Thomas Koch wrote:\n> Sorry for the shameless subject, but I presented gitosis yesterday to\n> our sysadmin and he wasn't much delighted to learn, that write access to\n> repositories hosted with gitosis would need SSH access.\n\nAccounts set up with keys for Gitosis are given restricted accounts\n(from my understanding similar to how CVS or SVN operate over SSH\ntunnels). \n\nThe sysadmins here at Slide also had similar frustrations/concerns about\nusing Gitosis, but we were able to convince them that keys were a far\nbetter solution than keyboard-interactive login sessions over HTTPS for\nSubversion.\n\nWe're using gitosis with plenty of developers (coming up on 50) and\nhaven't had any issues with security (yet, crossed fingers). We even\nhave some accounts that are able to read but not write, i.e. they can\nclone and pull, but not push back up to the central repository. YMMV.\n\n> \n> So could you help me out in this discussion, whether to use or not to\n> use gitosis? \n> Our admin would prefer to not open SSH at all outside our LAN, but\n> developers would need to have write access also outside the office.\n\nI recommend using VPN if the need to push/pull while outside of the\noffice (more fun solutions include SSH gateways that tunnel outside to\ninside). Otherwise, why could they not simply commit locally, etc, and\nthen when they come into the office push/pull?\n\nCheers\n-- \n-R. Tyler Ballance\nSlide, Inc.\n"},{"id":"97413","messageId":"bd6139dc0812090138l5dbaf20bsd1cde00f52bb94e5@mail.gmail.com","threadId":"16650","inReplyTo":"200812090956.48613.thomas@koch.ro","subject":"Re: is gitosis secure?","fromName":"Sverre Rabbelier","fromEmail":"alturin@gmail.com","sentAt":"2008-12-09T09:38:50Z","receivedAt":"2008-12-09T09:38:50Z","isPatch":false,"sender":{"key":"alturin@gmail.com","avatar":null},"body":"On Tue, Dec 9, 2008 at 09:56, Thomas Koch wrote:\n> Our admin would prefer to not open SSH at all outside our LAN, but\n> developers would need to have write access also outside the office.\n\nWhat safer to connect to the LAN than with SSH? What _would_ your\nsystem admin be happy with using?\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"97448","messageId":"20081209191854.GA2365@garry-thinkpad.arpnetworks.com","threadId":"16650","inReplyTo":"200812090956.48613.thomas@koch.ro","subject":"Re: is gitosis secure?","fromName":"Garry Dolley","fromEmail":"gdolley@arpnetworks.com","sentAt":"2008-12-09T19:18:54Z","receivedAt":"2008-12-09T19:18:54Z","isPatch":false,"sender":{"key":"gdolley@ucla.edu","avatar":"https://gravatar.com/avatar/b9ca98e2d5fd3a993ad695e8315f078b7ae364d2d1b637a6adecf8953a034dd2?d=mp&s=160"},"body":"On Tue, Dec 09, 2008 at 09:56:48AM +0100, Thomas Koch wrote:\n> Sorry for the shameless subject, but I presented gitosis yesterday to\n> our sysadmin and he wasn't much delighted to learn, that write access to\n> repositories hosted with gitosis would need SSH access.\n> \n> So could you help me out in this discussion, whether to use or not to\n> use gitosis? \n> Our admin would prefer to not open SSH at all outside our LAN, but\n> developers would need to have write access also outside the office.\n\nIf your admin doesn't want to open SSH to the outside, then the\npeople who need it would need to VPN into your LAN first. That's\nhow I do it on networks that don't allow any traffic from the\noutside.\n\nBut like someone else ask, what alternative *would* your admin\nprefer? I'd rather use SSH than a yet-to-be-proven-secure\nalternative app.\n\n-- \nGarry Dolley\nARP Networks, Inc. http://www.arpnetworks.com\nData center, VPS, and IP transit solutions (818) 206-0181\nMember Los Angeles County REACT, Unit 336 WQGK336\nBlog http://scie.nti.st\n"},{"id":"97800","messageId":"87hc58hwmi.fsf@hades.wkstn.nix","threadId":"16650","inReplyTo":"bd6139dc0812090138l5dbaf20bsd1cde00f52bb94e5@mail.gmail.com","subject":"Re: is gitosis secure?","fromName":"Nix","fromEmail":"nix@esperi.org.uk","sentAt":"2008-12-13T16:23:49Z","receivedAt":"2008-12-13T16:23:49Z","isPatch":false,"sender":{"key":"nix@esperi.org.uk","avatar":"https://avatars.githubusercontent.com/u/6503005?v=4"},"body":"On 9 Dec 2008, Sverre Rabbelier spake thusly:\n\n> On Tue, Dec 9, 2008 at 09:56, Thomas Koch wrote:\n>> Our admin would prefer to not open SSH at all outside our LAN, but\n>> developers would need to have write access also outside the office.\n>\n> What safer to connect to the LAN than with SSH? What _would_ your\n> system admin be happy with using?\n\ntelnet. I do not jest, this is our sysadmins' stated reasons for not\nopening the git port and for tweaking their (mandatory) HTTP proxy to\nblock HTTP traffic from git.\n\n(Telnet over some horrible impossibly slow buggy proprietary VPN.\nIt takes >5min to bring up a single connection.)\n\nDo not underestimate the stupidity and hideboundedness of undertrained\nsystem administrators, for it is vast.\n"},{"id":"97801","messageId":"bd6139dc0812131007va4f07f2k54289163932f0c2b@mail.gmail.com","threadId":"16650","inReplyTo":"87hc58hwmi.fsf@hades.wkstn.nix","subject":"Re: is gitosis secure?","fromName":"Sverre Rabbelier","fromEmail":"alturin@gmail.com","sentAt":"2008-12-13T18:07:07Z","receivedAt":"2008-12-13T18:07:07Z","isPatch":false,"sender":{"key":"alturin@gmail.com","avatar":null},"body":"On Sat, Dec 13, 2008 at 17:23, Nix wrote:\n> telnet. I do not jest, this is our sysadmins' stated reasons for not\n> opening the git port and for tweaking their (mandatory) HTTP proxy to\n> block HTTP traffic from git.\n\nI don't know what to say to this :P.\n\n> (Telnet over some horrible impossibly slow buggy proprietary VPN.\n> It takes >5min to bring up a single connection.)\n\nI feel for you man, try and get that guy fired and have them hire some\n_real_ sysadmins!\n\n> Do not underestimate the stupidity and hideboundedness of undertrained\n> system administrators, for it is vast.\n\nThis is beyond doubt.\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"97839","messageId":"gi1qsl$22p$1@ger.gmane.org","threadId":"16650","inReplyTo":"87hc58hwmi.fsf@hades.wkstn.nix","subject":"Re: is gitosis secure?","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2008-12-14T02:26:29Z","receivedAt":"2008-12-14T02:26:29Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On 2008-12-13, Nix wrote:\n> telnet. I do not jest, this is our sysadmins' stated reasons for not\n> opening the git port and for tweaking their (mandatory) HTTP proxy to\n> block HTTP traffic from git.\n\nWow -- my sympathies!\n\nBut on occasion, when real or imaginary issues prevented me\nfrom making a live connection, I have used \"git bundle\" to\ndo the job. Not as satisfactory as a real connection, but\nwhen you have a proper, non-fast-forwarding, repo as the\n\"mother ship\", git bundle with some custom procmail scripts\non both sides can work OK enough.\n\nTo do that with a public repo you'd have to mirror that on a\nhome machine and let your restricted environment work\nagainst that.\n\n> Do not underestimate the stupidity and hideboundedness of undertrained\n> system administrators, for it is vast.\n\nThese same administrators also underestimate (i) the number\nof well connected home machines and (ii) the idea that on\nhis own machine, everyone is root.\n\nMost of these blocks are \"default allow\", and your home IP\nis not on that list and they don't have the smarts to figure\nout that you're getting around their blocks :-) Add dynamic\nIP and a dyndns hostname (and dyndns has a hundred or so 2nd\nlevel domains to choose your 3rd level hostname from!) and\nclueless admins don't stand a chance.\n\n[sorry this is so badly off-topic...]\n"},{"id":"97843","messageId":"alpine.DEB.1.10.0812132126470.17688@asgard.lang.hm","threadId":"16650","inReplyTo":"gi1qsl$22p$1@ger.gmane.org","subject":"Re: is gitosis secure?","fromName":"","fromEmail":"david@lang.hm","sentAt":"2008-12-14T05:40:24Z","receivedAt":"2008-12-14T05:40:24Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"this is really a reply to an earlier message that I deleted.\n\nthe question was asked 'what would the security people like instead of \nSSH'\n\nas a security person who doesn't like how ssh is used for everything, let \nme list a couple of concerns.\n\nssh is default allow (it lets you run any commands), you can lock it down \nwith effort.\n\nssh defaults to establishing a tunnel between machines that other network \ntraffic can use to bypass your system. yes I know that with enough effort \nand control of both systems you can tunnel over anything, the point is \nthat ssh is eager to do this for you (overly eager IMHO)\n\nssh depends primarily on certificates that reside on untrusted machines. \nit can be made to work with tokens or such, but it takes a fair bit of \neffort.\n\nsshd runs as root on just about every system\n\npeople trust ssh too much. they tend to think that anything is acceptable \nif it's done over ssh (this isn't a technical issue, but it is a social \nissue)\n\n\nwhat would I like to see in an ideal world?\n\nsomething that runs as the git user, does not enable tunneling, and only \ndoes the data transfer functions needed for a push. it should use \noff-the-shelf libraries for certificate authentication and tie into PAM \nfor additional authentication.\n\nthe authentication would not be any better than with SSH, but the rest \nwould be better. I was very pleased to watch the git-daemon development, \nand the emphisis on it running with minimum privilages and provide just \nthe functionality that was needed, and appropriately assuming that any \nconnection from the outside is hostile until proven otherwise.\n\n\nwhat would I do with current tools?\n\nI would say that developers working from outside should VPN into the \ncompany network before doing the push with SSH rather than exposing the \nSSH daemon to the entire Internet.\n\nin the medium term, if the git-over-http gets finished, I would like to \nsee a seperate cgi created to allow push as well. http is overused as a \ntunneling protocol, but it's easy to setup a server that can't do anything \nexcept what you want, so this tunneling is generally not a threat to \nservers (it's a horrible threat to client systems)\n\nDavid Lang\n"},{"id":"97849","messageId":"4944D4F7.7050501@siamect.com","threadId":"16650","inReplyTo":"alpine.DEB.1.10.0812132126470.17688@asgard.lang.hm","subject":"Re: is gitosis secure?","fromName":"martin","fromEmail":"martin@siamect.com","sentAt":"2008-12-14T09:42:15Z","receivedAt":"2008-12-14T09:42:15Z","isPatch":false,"sender":{"key":"martin@siamect.com","avatar":"https://gravatar.com/avatar/97ed731b9c70a7342247447388d2d3581a1316ad8b69979ab88efd37b9de5f1a?d=mp&s=160"},"body":"Dear David.\nWhy do you trust VPN more than the SSH?\nI ask because I have just removed the \"first VPN then SSH\" solution in \nfavor for a SSH only solution using Gitosis just to get rid of the VPN \nwhich I believe is less secure than SSH (well until I read you comments \nbelow).\nI thought I was doing something right for once but maybe I'm not?\nThanks and best regards\nMartin\n\ndavid@lang.hm wrote:\n> this is really a reply to an earlier message that I deleted.\n>\n> the question was asked 'what would the security people like instead of \n> SSH'\n>\n> as a security person who doesn't like how ssh is used for everything, \n> let me list a couple of concerns.\n>\n> ssh is default allow (it lets you run any commands), you can lock it \n> down with effort.\n>\n> ssh defaults to establishing a tunnel between machines that other \n> network traffic can use to bypass your system. yes I know that with \n> enough effort and control of both systems you can tunnel over \n> anything, the point is that ssh is eager to do this for you (overly \n> eager IMHO)\n>\n> ssh depends primarily on certificates that reside on untrusted \n> machines. it can be made to work with tokens or such, but it takes a \n> fair bit of effort.\n>\n> sshd runs as root on just about every system\n>\n> people trust ssh too much. they tend to think that anything is \n> acceptable if it's done over ssh (this isn't a technical issue, but it \n> is a social issue)\n>\n>\n> what would I like to see in an ideal world?\n>\n> something that runs as the git user, does not enable tunneling, and \n> only does the data transfer functions needed for a push. it should use \n> off-the-shelf libraries for certificate authentication and tie into \n> PAM for additional authentication.\n>\n> the authentication would not be any better than with SSH, but the rest \n> would be better. I was very pleased to watch the git-daemon \n> development, and the emphisis on it running with minimum privilages \n> and provide just the functionality that was needed, and appropriately \n> assuming that any connection from the outside is hostile until proven \n> otherwise.\n>\n>\n> what would I do with current tools?\n>\n> I would say that developers working from outside should VPN into the \n> company network before doing the push with SSH rather than exposing \n> the SSH daemon to the entire Internet.\n>\n> in the medium term, if the git-over-http gets finished, I would like \n> to see a seperate cgi created to allow push as well. http is overused \n> as a tunneling protocol, but it's easy to setup a server that can't do \n> anything except what you want, so this tunneling is generally not a \n> threat to servers (it's a horrible threat to client systems)\n>\n> David Lang\n> -- \n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n>\n"},{"id":"97853","messageId":"m34p17f3bh.fsf@localhost.localdomain","threadId":"16650","inReplyTo":"alpine.DEB.1.10.0812132126470.17688@asgard.lang.hm","subject":"Re: is gitosis secure?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-12-14T10:40:39Z","receivedAt":"2008-12-14T10:40:39Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"david@lang.hm writes:\n\n> this is really a reply to an earlier message that I deleted.\n> \n> the question was asked 'what would the security people like instead of\n> SSH'\n> \n> as a security person who doesn't like how ssh is used for everything,\n> let me list a couple of concerns.\n> \n> ssh is default allow (it lets you run any commands), you can lock it\n> down with effort.\n\nHow is VPN better than that?\n \n> ssh defaults to establishing a tunnel between machines that other\n> network traffic can use to bypass your system. yes I know that with\n> enough effort and control of both systems you can tunnel over\n> anything, the point is that ssh is eager to do this for you (overly\n> eager IMHO)\n\nHow is VPN better than that?\n\n> ssh depends primarily on certificates that reside on untrusted\n> machines. it can be made to work with tokens or such, but it takes a\n> fair bit of effort.\n\nThere probably VPN differs...\n\n> sshd runs as root on just about every system\n\nAnd VPN doesn't?\n\n[...]\n\nThe idea with using SSH was, I think, that it is easier and better to\nuse existing solution for authentication and authorization than roll\nyour own (see the case of CVS pserver, and Subversion svnserve).\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"97856","messageId":"m3zlizdofy.fsf@localhost.localdomain","threadId":"16650","inReplyTo":"gi1qsl$22p$1@ger.gmane.org","subject":"Re: is gitosis secure?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-12-14T10:47:31Z","receivedAt":"2008-12-14T10:47:31Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Sitaram Chamarty writes:\n> On 2008-12-13, Nix wrote:\n\n> > telnet. I do not jest, this is our sysadmins' stated reasons for not\n> > opening the git port and for tweaking their (mandatory) HTTP proxy to\n> > block HTTP traffic from git.\n> \n> Wow -- my sympathies!\n> \n> But on occasion, when real or imaginary issues prevented me\n> from making a live connection, I have used \"git bundle\" to\n> do the job. Not as satisfactory as a real connection, but\n> when you have a proper, non-fast-forwarding, repo as the\n> \"mother ship\", git bundle with some custom procmail scripts\n> on both sides can work OK enough.\n\nPerhaps one would be interested in adding bundle support to gitweb.\nThe problem is in the interface, but I think in simplest case gitweb\ncould present 'bundle' link along snapshot link(s) in the 'heads' view\n(showing branches), which link would generate bundle for a given\nbranch, starting from latest annotated tag. But this is only for\ndownload...\n \nAnother solution would be to help with \"smart\" HTTP protocol,\ni.e. git-over-http solution. This would hopefully change signature so\nat least for some time it would pas proxy filters. Also only for\ndownload.\n\n\nBTW. is outgoing SSH transport (from network to outside) blocked as\nwell?\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"97857","messageId":"m3vdtndo9b.fsf@localhost.localdomain","threadId":"16650","inReplyTo":"alpine.DEB.1.10.0812140304320.17688@asgard.lang.hm","subject":"Re: is gitosis secure?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-12-14T10:51:26Z","receivedAt":"2008-12-14T10:51:26Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"david@lang.hm writes:\n> On Sun, 14 Dec 2008, martin wrote:\n> \n> > Dear David.\n> > Why do you trust VPN more than the SSH?\n> > I ask because I have just removed the \"first VPN then SSH\" solution\n> > in favor for a SSH only solution using Gitosis just to get rid of\n> > the VPN which I believe is less secure than SSH (well until I read\n> > you comments below).\n> > I thought I was doing something right for once but maybe I'm not?\n> > Thanks and best regards\n> > Martin\n> \n> in part it's that a VPN is a single point of control for all remote\n> access.\n> \n> If you use ssh you end up exposing all the individual machines\n> \n> 1. data leakage of just what machines exist to possibly hostile users.\n\nErrr... what? One of established practices is expose only _one_\nmachine to outside; you have to SSH to gateway.\n \n> 2. the many machines are configured seperatly, frequently by different\n> people. this makes it far more likely that sometime some machine will\n> get misconfigured.\n\nSee above.\n\n> 3. people who are focused on providing features have a strong\n> temptation to cut corners and just test that the feature works and not\n> test that everything that isn't supposed to work actually doesn't\n> work. as a result, in many companies there is a deliberate seperation\n> (and tension) between a group focused on controlling and auditing\n> access and one that is focused on creating fucntionality and features.\n\nAnd that differs from VPN in what way?\n\n> also from a polical/social point of view everyone recognises that if\n> you grant someone VPN access you are trusting them, but people don't\n> seem to think the same way with ssh.\n\nErrr... what? I think everybody knows that unrestricted SSH access\n(without limiting done by shell used) means that you trust user.\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"97858","messageId":"4944E7E1.2030907@siamect.com","threadId":"16650","inReplyTo":"alpine.DEB.1.10.0812140304320.17688@asgard.lang.hm","subject":"Re: is gitosis secure?","fromName":"martin","fromEmail":"martin@siamect.com","sentAt":"2008-12-14T11:02:57Z","receivedAt":"2008-12-14T11:02:57Z","isPatch":false,"sender":{"key":"martin@siamect.com","avatar":"https://gravatar.com/avatar/97ed731b9c70a7342247447388d2d3581a1316ad8b69979ab88efd37b9de5f1a?d=mp&s=160"},"body":"\n\ndavid@lang.hm wrote:\n> On Sun, 14 Dec 2008, martin wrote:\n>\n>> Dear David.\n>> Why do you trust VPN more than the SSH?\n>> I ask because I have just removed the \"first VPN then SSH\" solution \n>> in favor for a SSH only solution using Gitosis just to get rid of the \n>> VPN which I believe is less secure than SSH (well until I read you \n>> comments below).\n>> I thought I was doing something right for once but maybe I'm not?\n>> Thanks and best regards\n>> Martin\n>\n> in part it's that a VPN is a single point of control for all remote \n> access.\n>\n> If you use ssh you end up exposing all the individual machines\n>\n> 1. data leakage of just what machines exist to possibly hostile users.\n>\n> 2. the many machines are configured seperatly, frequently by different \n> people. this makes it far more likely that sometime some machine will \n> get misconfigured.\n>\n> 3. people who are focused on providing features have a strong \n> temptation to cut corners and just test that the feature works and not \n> test that everything that isn't supposed to work actually doesn't \n> work. as a result, in many companies there is a deliberate seperation \n> (and tension) between a group focused on controlling and auditing \n> access and one that is focused on creating fucntionality and features.\n>\n> also from a polical/social point of view everyone recognises that if \n> you grant someone VPN access you are trusting them, but people don't \n> seem to think the same way with ssh.\n>\n> David Lang\n>\n\nI opened port 22 in the firewall to just those hosts that I need to \nreach, which is one in this case...the rest of the machines I cannot reach.\nI did a brief port scan and the thing is silent... so I don't think I \nreveal any of the other hosts... but I should not say is it's secure \nwith your measures...\n\nYour point two I don't understand... If you are in charge of the \nfirewall you also know what machines you let people reach. If these \nmachines are numerous then I think there is a management problem \nsomewhere else...\n\n\nPoint 3 is correct but I fail to see how this is less of a problem with \nVPN than SSH.\n\nThanks and Best regards\nMartin\n"},{"id":"97850","messageId":"alpine.DEB.1.10.0812140304320.17688@asgard.lang.hm","threadId":"16650","inReplyTo":"4944D4F7.7050501@siamect.com","subject":"Re: is gitosis secure?","fromName":"","fromEmail":"david@lang.hm","sentAt":"2008-12-14T11:25:17Z","receivedAt":"2008-12-14T11:25:17Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Sun, 14 Dec 2008, martin wrote:\n\n> Dear David.\n> Why do you trust VPN more than the SSH?\n> I ask because I have just removed the \"first VPN then SSH\" solution in favor \n> for a SSH only solution using Gitosis just to get rid of the VPN which I \n> believe is less secure than SSH (well until I read you comments below).\n> I thought I was doing something right for once but maybe I'm not?\n> Thanks and best regards\n> Martin\n\nin part it's that a VPN is a single point of control for all remote \naccess.\n\nIf you use ssh you end up exposing all the individual machines\n\n1. data leakage of just what machines exist to possibly hostile users.\n\n2. the many machines are configured seperatly, frequently by different \npeople. this makes it far more likely that sometime some machine will get \nmisconfigured.\n\n3. people who are focused on providing features have a strong temptation \nto cut corners and just test that the feature works and not test that \neverything that isn't supposed to work actually doesn't work. as a \nresult, in many companies there is a deliberate seperation (and tension) \nbetween a group focused on controlling and auditing access and one that is \nfocused on creating fucntionality and features.\n\nalso from a polical/social point of view everyone recognises that if you \ngrant someone VPN access you are trusting them, but people don't seem to \nthink the same way with ssh.\n\nDavid Lang\n\n> david@lang.hm wrote:\n>> this is really a reply to an earlier message that I deleted.\n>> \n>> the question was asked 'what would the security people like instead of SSH'\n>> \n>> as a security person who doesn't like how ssh is used for everything, let \n>> me list a couple of concerns.\n>> \n>> ssh is default allow (it lets you run any commands), you can lock it down \n>> with effort.\n>> \n>> ssh defaults to establishing a tunnel between machines that other network \n>> traffic can use to bypass your system. yes I know that with enough effort \n>> and control of both systems you can tunnel over anything, the point is that \n>> ssh is eager to do this for you (overly eager IMHO)\n>> \n>> ssh depends primarily on certificates that reside on untrusted machines. it \n>> can be made to work with tokens or such, but it takes a fair bit of effort.\n>> \n>> sshd runs as root on just about every system\n>> \n>> people trust ssh too much. they tend to think that anything is acceptable \n>> if it's done over ssh (this isn't a technical issue, but it is a social \n>> issue)\n>> \n>> \n>> what would I like to see in an ideal world?\n>> \n>> something that runs as the git user, does not enable tunneling, and only \n>> does the data transfer functions needed for a push. it should use \n>> off-the-shelf libraries for certificate authentication and tie into PAM for \n>> additional authentication.\n>> \n>> the authentication would not be any better than with SSH, but the rest \n>> would be better. I was very pleased to watch the git-daemon development, \n>> and the emphisis on it running with minimum privilages and provide just the \n>> functionality that was needed, and appropriately assuming that any \n>> connection from the outside is hostile until proven otherwise.\n>> \n>> \n>> what would I do with current tools?\n>> \n>> I would say that developers working from outside should VPN into the \n>> company network before doing the push with SSH rather than exposing the SSH \n>> daemon to the entire Internet.\n>> \n>> in the medium term, if the git-over-http gets finished, I would like to see \n>> a seperate cgi created to allow push as well. http is overused as a \n>> tunneling protocol, but it's easy to setup a server that can't do anything \n>> except what you want, so this tunneling is generally not a threat to \n>> servers (it's a horrible threat to client systems)\n>> \n>> David Lang\n>> -- \n>> To unsubscribe from this list: send the line \"unsubscribe git\" in\n>> the body of a message to majordomo@vger.kernel.org\n>> More majordomo info at http://vger.kernel.org/majordomo-info.html\n>> \n>\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n>\n"},{"id":"97868","messageId":"gi2rej$1mn$1@ger.gmane.org","threadId":"16650","inReplyTo":"alpine.DEB.1.10.0812140304320.17688@asgard.lang.hm","subject":"Re: is gitosis secure?","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2008-12-14T11:42:11Z","receivedAt":"2008-12-14T11:42:11Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On 2008-12-14, david@lang.hm wrote:\n> On Sun, 14 Dec 2008, martin wrote:\n>> Why do you trust VPN more than the SSH?\n> in part it's that a VPN is a single point of control for all remote \n> access.\n>\n> If you use ssh you end up exposing all the individual machines\n\nNeed not be true. None of my internal servers aer even\naccessible from the outside world; they're all in RFC1918\nspace and there's only one gateway. This *is* my single\npoint of control.\n\nI can setup different port numbers to forward to different\ninternal servers (ssh, http, whatever I wish); that may\nsound like a form of \"exposing\" but in reality it's a lot\n*more* restrictive than setting up a VPN and granting access\nto it.\n\nI actually don't like VPNs; they imply that you're \"inside\"\nthe network in some way, and I hate blurring that\ndistinction. If I'm outside, I want to be acutely aware of\nit, and the fact that I can't even ping one of the inside\nhosts or see what's on it, or do anything other than what is\nspecifically allowed by the gateway, is one way of ensuring\nthis.\n"},{"id":"97907","messageId":"87prju5m6s.fsf@hades.wkstn.nix","threadId":"16650","inReplyTo":"m3zlizdofy.fsf@localhost.localdomain","subject":"Re: is gitosis secure?","fromName":"Nix","fromEmail":"nix@esperi.org.uk","sentAt":"2008-12-15T00:14:35Z","receivedAt":"2008-12-15T00:14:35Z","isPatch":false,"sender":{"key":"nix@esperi.org.uk","avatar":"https://avatars.githubusercontent.com/u/6503005?v=4"},"body":"On 14 Dec 2008, Jakub Narebski spake thusly:\n> BTW. is outgoing SSH transport (from network to outside) blocked as\n> well?\n\n*No* ports are open. All they have is a (non-transparent) buggy HTTP\nproxy. These guys really don't get the Internet, despite their sales\nliterature banging on endlessly about it.\n\nLooks like a lot of git-bundling is in my future.\n"},{"id":"97902","messageId":"alpine.DEB.1.10.0812141645060.17688@asgard.lang.hm","threadId":"16650","inReplyTo":"m34p17f3bh.fsf@localhost.localdomain","subject":"Re: is gitosis secure?","fromName":"","fromEmail":"david@lang.hm","sentAt":"2008-12-15T00:50:03Z","receivedAt":"2008-12-15T00:50:03Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Sun, 14 Dec 2008, Jakub Narebski wrote:\n\n> david@lang.hm writes:\n>\n>> this is really a reply to an earlier message that I deleted.\n>>\n>> the question was asked 'what would the security people like instead of\n>> SSH'\n>>\n>> as a security person who doesn't like how ssh is used for everything,\n>> let me list a couple of concerns.\n>>\n>> ssh is default allow (it lets you run any commands), you can lock it\n>> down with effort.\n>\n> How is VPN better than that?\n>\n>> ssh defaults to establishing a tunnel between machines that other\n>> network traffic can use to bypass your system. yes I know that with\n>> enough effort and control of both systems you can tunnel over\n>> anything, the point is that ssh is eager to do this for you (overly\n>> eager IMHO)\n>\n> How is VPN better than that?\n>\n>> ssh depends primarily on certificates that reside on untrusted\n>> machines. it can be made to work with tokens or such, but it takes a\n>> fair bit of effort.\n>\n> There probably VPN differs...\n>\n>> sshd runs as root on just about every system\n>\n> And VPN doesn't?\n\nyou aren't having the VPN software running commands passed to it by the \noutside world.\n\n> [...]\n>\n> The idea with using SSH was, I think, that it is easier and better to\n> use existing solution for authentication and authorization than roll\n> your own (see the case of CVS pserver, and Subversion svnserve).\n\nI'm not saying that it's good to roll your own from scratch, you need to \nuse libraries that have been examined and validated, but SSH is a swiss \narmy knife, it's designed to do lots of things, and when you are exposing \nthings to the outside world you want them to be as limited as possible to \nlimit the damage that they can do.\n\nDavid Lang\n"},{"id":"97903","messageId":"alpine.DEB.1.10.0812141650100.17688@asgard.lang.hm","threadId":"16650","inReplyTo":"m3vdtndo9b.fsf@localhost.localdomain","subject":"Re: is gitosis secure?","fromName":"","fromEmail":"david@lang.hm","sentAt":"2008-12-15T00:54:59Z","receivedAt":"2008-12-15T00:54:59Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Sun, 14 Dec 2008, Jakub Narebski wrote:\n\n> david@lang.hm writes:\n>> On Sun, 14 Dec 2008, martin wrote:\n>>\n>>> Dear David.\n>>> Why do you trust VPN more than the SSH?\n>>> I ask because I have just removed the \"first VPN then SSH\" solution\n>>> in favor for a SSH only solution using Gitosis just to get rid of\n>>> the VPN which I believe is less secure than SSH (well until I read\n>>> you comments below).\n>>> I thought I was doing something right for once but maybe I'm not?\n>>> Thanks and best regards\n>>> Martin\n>>\n>> in part it's that a VPN is a single point of control for all remote\n>> access.\n>>\n>> If you use ssh you end up exposing all the individual machines\n>>\n>> 1. data leakage of just what machines exist to possibly hostile users.\n>\n> Errr... what? One of established practices is expose only _one_\n> machine to outside; you have to SSH to gateway.\n\nthat works for sysadmin access to a box, it doesn't work for git push \n(unless that box also happens to be your git repository). multiply by a \nfew dozen different applications that all take the attitude 'just us SSH \nand you are secure' and you end up with a bunch of machines that _have_ to \nbe exposed via SSH.\n\n>> 2. the many machines are configured seperatly, frequently by different\n>> people. this makes it far more likely that sometime some machine will\n>> get misconfigured.\n>\n> See above.\n>\n>> 3. people who are focused on providing features have a strong\n>> temptation to cut corners and just test that the feature works and not\n>> test that everything that isn't supposed to work actually doesn't\n>> work. as a result, in many companies there is a deliberate seperation\n>> (and tension) between a group focused on controlling and auditing\n>> access and one that is focused on creating fucntionality and features.\n>\n> And that differs from VPN in what way?\n\nthe VPN is typically (but not always) run by the group who is focused on \ncontrolling and auditing access.\n\n>> also from a polical/social point of view everyone recognises that if\n>> you grant someone VPN access you are trusting them, but people don't\n>> seem to think the same way with ssh.\n>\n> Errr... what? I think everybody knows that unrestricted SSH access\n> (without limiting done by shell used) means that you trust user.\n\nyou would be surprised.\n\nI'm not saying that SSH is bad for all uses by any means. I'm responding \nto the people who seemd to be thinking that anyone who didn't like the \n'use SSH' option are luddites and just don't know what they are doing. \ndifferent networks can have different stances and all be right (for their \nenvironment)\n\nDavid Lang\n"},{"id":"97906","messageId":"alpine.DEB.1.10.0812141655150.17688@asgard.lang.hm","threadId":"16650","inReplyTo":"4944E7E1.2030907@siamect.com","subject":"Re: is gitosis secure?","fromName":"","fromEmail":"david@lang.hm","sentAt":"2008-12-15T01:00:14Z","receivedAt":"2008-12-15T01:00:14Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Sun, 14 Dec 2008, martin wrote:\n\n> david@lang.hm wrote:\n>> On Sun, 14 Dec 2008, martin wrote:\n>> \n>>> Dear David.\n>>> Why do you trust VPN more than the SSH?\n>>> I ask because I have just removed the \"first VPN then SSH\" solution in \n>>> favor for a SSH only solution using Gitosis just to get rid of the VPN \n>>> which I believe is less secure than SSH (well until I read you comments \n>>> below).\n>>> I thought I was doing something right for once but maybe I'm not?\n>>> Thanks and best regards\n>>> Martin\n>> \n>> in part it's that a VPN is a single point of control for all remote access.\n>> \n>> If you use ssh you end up exposing all the individual machines\n>> \n>> 1. data leakage of just what machines exist to possibly hostile users.\n>> \n>> 2. the many machines are configured seperatly, frequently by different \n>> people. this makes it far more likely that sometime some machine will get \n>> misconfigured.\n>> \n>> 3. people who are focused on providing features have a strong temptation to \n>> cut corners and just test that the feature works and not test that \n>> everything that isn't supposed to work actually doesn't work. as a result, \n>> in many companies there is a deliberate seperation (and tension) between a \n>> group focused on controlling and auditing access and one that is focused on \n>> creating fucntionality and features.\n>> \n>> also from a polical/social point of view everyone recognises that if you \n>> grant someone VPN access you are trusting them, but people don't seem to \n>> think the same way with ssh.\n>> \n>> David Lang\n>> \n>\n> I opened port 22 in the firewall to just those hosts that I need to reach, \n> which is one in this case...the rest of the machines I cannot reach.\n> I did a brief port scan and the thing is silent... so I don't think I reveal \n> any of the other hosts... but I should not say is it's secure with your \n> measures...\n>\n> Your point two I don't understand... If you are in charge of the firewall \n> you also know what machines you let people reach. If these machines are \n> numerous then I think there is a management problem somewhere else...\n\ntwo things here\n\n1. if you are running multiple different applications that all want to be \nexposed via port 22 (like git for 'git push') then you may need to expose \nnumerous machines. tools that use SSH don't tend to have the ability to \nuse a gateway box before they start executing commands, they assume that \nyou will SSH directly into the destination box.\n\n2. many people take the attitude that SSH is secure, period, end of \nstatement. so they think that every machine should be able to be contacted \nvia SSH, and you can then use SSH to do any other functionality on any \nmachine that you can dream up. a small minority of people try to minimize \nwhat boxes are exposed directly (you are one of them), but most don't\n\nDavid Lang\n"},{"id":"97908","messageId":"alpine.DEB.1.10.0812141700330.17688@asgard.lang.hm","threadId":"16650","inReplyTo":"gi2rej$1mn$1@ger.gmane.org","subject":"Re: is gitosis secure?","fromName":"","fromEmail":"david@lang.hm","sentAt":"2008-12-15T01:20:26Z","receivedAt":"2008-12-15T01:20:26Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Sun, 14 Dec 2008, Sitaram Chamarty wrote:\n\n> On 2008-12-14, david@lang.hm wrote:\n>> On Sun, 14 Dec 2008, martin wrote:\n>>> Why do you trust VPN more than the SSH?\n>> in part it's that a VPN is a single point of control for all remote\n>> access.\n>>\n>> If you use ssh you end up exposing all the individual machines\n>\n> Need not be true. None of my internal servers aer even\n> accessible from the outside world; they're all in RFC1918\n> space and there's only one gateway. This *is* my single\n> point of control.\n>\n> I can setup different port numbers to forward to different\n> internal servers (ssh, http, whatever I wish); that may\n> sound like a form of \"exposing\" but in reality it's a lot\n> *more* restrictive than setting up a VPN and granting access\n> to it.\n\nif you setup multiple inbound redirects for SSH (be they different IP \naddresses or different ports), then you have the exact same situation as \nthose machines being accessed directly.\n\n> I actually don't like VPNs; they imply that you're \"inside\"\n> the network in some way, and I hate blurring that\n> distinction. If I'm outside, I want to be acutely aware of\n> it, and the fact that I can't even ping one of the inside\n> hosts or see what's on it, or do anything other than what is\n> specifically allowed by the gateway, is one way of ensuring\n> this.\n\nthis is the mindset about SSH that I don't like. I see allowing SSH in as \nblurring that distinction.\n\nWith a VPN you aren't blurring it, you _are_ letting the person into your \nnetwork. it's not appropriate to do this for everyone, but in the initial \npost the desire was to have trusted company employees working remotely \npush data to the repository. In that scenerio a VPN makes sense. If you \nwere doing a distributed opensource project it would probably not make \nsense to allow contributers that you only know via e-mail to VPN into a \nnetwork to do their push (it can be agued that they shouldn't be doing a \npush at all, but that's a workflow discussion ;-)\n\nmany people who would never allow a person to VPN into a network seem to \nhave no problem with that same person useing SSH to login to a machine on \nthat same network (and usually without trying to setup a limited shell). \nIn my opinion SSH and VPN access are both in the same category.\n\nIn both cases you can limit what the person you are granting access can \ndo. with a VPN you would use a firewall to control what they can access \nafter connecting to the VPN, with SSH you have to have the server they are \nconnecting to configured to limit what they can do.\n\nVPNs tend to have better tools for auditing access and doing strong \nauthentication other than certificates (even certificate plus password is \nbetter than just certificate). cerificates are good and useful, but they \naren't always enough by themselves.\n\nthere have been a number of breeches over the last few years that have \nresulted from one client machine with SSH being comprimized and the \ncredentials then used to hop to other machines, gather other credentials \nto then use to comprimize other machines, etc. while I am sure that there \nhave also been networks comprimized via VPN, I haven't heard of any \ndaisy-chain type attacks involving VPN access.\n\nSSH is a monoculture. there is essentially only one implementation that is \nused (although there are patches to it in some cases), and while it is \npretty good, any problems with it give you no options. with VPNs there are \nmany implementations, if any one has a problem it's possible to replace it \n(painful to change out clients, but possible)\n\n\nDavid Lang\n"},{"id":"97909","messageId":"alpine.DEB.1.10.0812141720510.17688@asgard.lang.hm","threadId":"16650","inReplyTo":"87prju5m6s.fsf@hades.wkstn.nix","subject":"Re: is gitosis secure?","fromName":"","fromEmail":"david@lang.hm","sentAt":"2008-12-15T01:29:52Z","receivedAt":"2008-12-15T01:29:52Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Mon, 15 Dec 2008, Nix wrote:\n\n> On 14 Dec 2008, Jakub Narebski spake thusly:\n>> BTW. is outgoing SSH transport (from network to outside) blocked as\n>> well?\n>\n> *No* ports are open. All they have is a (non-transparent) buggy HTTP\n> proxy. These guys really don't get the Internet, despite their sales\n> literature banging on endlessly about it.\n>\n> Looks like a lot of git-bundling is in my future.\n\nno ports being open and a non-transparent HTTP proxy doesn't tell me that \nthey don't get the Internet. They could get the Internet just fine and be \nsuitably paranoid about it. Controlling outbound traffic is actually a \ngood thing in the current era of botnets (it prevents any of the machines \nin that company from participating in a botnet if they can't reach the \ncommand system)\n\nthe fact that the proxy is buggy could be an issue (I'm curious about what \ntypes of bugs you are running into, what you see as a bug may not be)\n\n\n\nif there is a business reason for the developers on that network to be \naccessing resources on the Internet there should be a way to request that \nthe appropriate ports get opened. if the answer from the security folks is \n'no' you should ask them why not and what could be done to get the job \ndone.\n\nit may be that they don't want to provide access out from a bunch of \ndesktops. If that is the case it may be appropriate to build a box to put \ninto the DMZ that pulls from the upstream and then the inside desktops \npull from this gateway system.\n\n\nthe saying goes \"don't attribute to malice what can be explained by \nincompetence\", but along the same lines in the security field, don't \nattribute to incompetence what can be explained by people doing their jobs \nthat are ignorant of the requirements. they may also be operating under \nconstraints that you don't know about.\n\nDavid Lang\n"},{"id":"97924","messageId":"alpine.DEB.2.00.0812142121090.9552@vellum.laroia.net","threadId":"16650","inReplyTo":"87prju5m6s.fsf@hades.wkstn.nix","subject":"Re: is gitosis secure?","fromName":"Asheesh Laroia","fromEmail":"asheesh@asheesh.org","sentAt":"2008-12-15T05:24:31Z","receivedAt":"2008-12-15T05:24:31Z","isPatch":false,"sender":{"key":"asheesh@asheesh.org","avatar":"https://avatars.githubusercontent.com/u/25457?v=4"},"body":"On Mon, 15 Dec 2008, Nix wrote:\n\n> On 14 Dec 2008, Jakub Narebski spake thusly:\n>> BTW. is outgoing SSH transport (from network to outside) blocked as \n>> well?\n>\n> *No* ports are open. All they have is a (non-transparent) buggy HTTP \n> proxy. These guys really don't get the Internet, despite their sales \n> literature banging on endlessly about it.\n\nIf that's the only way you can access the network, you can take advantage \nof the way HTTP proxies deal with HTTPS: they typically let it through \nbyte for byte.\n\n\"connect.c is the simple relaying command to make network connection via \nSOCKS and https proxy. It is mainly intended to be used as proxy command \nof OpenSSH.\"\n\nRun sshd on port 443, use connect.c, and you're set.\n\n(Except for some really smart SSL-aware HTTP proxies that verify that it's \nan SSL connection of some kind. In theory, you could then sslwrap your \nsshd and then be set.)\n\n-- Asheesh.\n\n-- \nQ:\tWhy did the astrophysicist order three hamburgers?\nA:\tBecause he was hungry.\n"},{"id":"97925","messageId":"alpine.DEB.1.10.0812142229010.17688@asgard.lang.hm","threadId":"16650","inReplyTo":"alpine.DEB.2.00.0812142121090.9552@vellum.laroia.net","subject":"Re: is gitosis secure?","fromName":"","fromEmail":"david@lang.hm","sentAt":"2008-12-15T06:32:35Z","receivedAt":"2008-12-15T06:32:35Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Sun, 14 Dec 2008, Asheesh Laroia wrote:\n\n> On Mon, 15 Dec 2008, Nix wrote:\n>\n>> On 14 Dec 2008, Jakub Narebski spake thusly:\n>>> BTW. is outgoing SSH transport (from network to outside) blocked as well?\n>> \n>> *No* ports are open. All they have is a (non-transparent) buggy HTTP proxy. \n>> These guys really don't get the Internet, despite their sales literature \n>> banging on endlessly about it.\n>\n> If that's the only way you can access the network, you can take advantage of \n> the way HTTP proxies deal with HTTPS: they typically let it through byte for \n> byte.\n>\n> \"connect.c is the simple relaying command to make network connection via \n> SOCKS and https proxy. It is mainly intended to be used as proxy command of \n> OpenSSH.\"\n>\n> Run sshd on port 443, use connect.c, and you're set.\n>\n> (Except for some really smart SSL-aware HTTP proxies that verify that it's an \n> SSL connection of some kind. In theory, you could then sslwrap your sshd and \n> then be set.)\n\nalthough, if the company is doing this as a deliberate security measure \n(as opposed to not knowing what they are doing), setting up a bypass like \nthis can get you fired for deliberatly bypassing a security device.\n\nalso, examples of people going to this sort of effort to bypass security \npolicies end up with employees being trusted less.\n\nyou are far better off going through channels and discussing what you are \ntrying to do and why.\n\nDavid Lang\n"},{"id":"97931","messageId":"20081215071737.GA32387@glandium.org","threadId":"16650","inReplyTo":"alpine.DEB.1.10.0812141655150.17688@asgard.lang.hm","subject":"Re: is gitosis secure?","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2008-12-15T07:17:37Z","receivedAt":"2008-12-15T07:17:37Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Sun, Dec 14, 2008 at 05:00:14PM -0800, david@lang.hm wrote:\n> 1. if you are running multiple different applications that all want to be \n> exposed via port 22 (like git for 'git push') then you may need to expose \n> numerous machines. tools that use SSH don't tend to have the ability to \n> use a gateway box before they start executing commands, they assume that \n> you will SSH directly into the destination box.\n\nBut ssh itself allows you to do proxying. See ProxyCommand in\nssh_config's manpage.\n\nMike\n"},{"id":"97927","messageId":"49460531.8010808@dawes.za.net","threadId":"16650","inReplyTo":"alpine.DEB.1.10.0812132126470.17688@asgard.lang.hm","subject":"Re: is gitosis secure?","fromName":"Rogan Dawes","fromEmail":"lists@dawes.za.net","sentAt":"2008-12-15T07:20:17Z","receivedAt":"2008-12-15T07:20:17Z","isPatch":false,"sender":{"key":"lists@dawes.za.net","avatar":null},"body":"david@lang.hm wrote:\n\n> \n> as a security person who doesn't like how ssh is used for everything,\n> let me list a couple of concerns.\n> \n> ssh is default allow (it lets you run any commands), you can lock it\n> down with effort.\n> \n> ssh defaults to establishing a tunnel between machines that other\n> network traffic can use to bypass your system. yes I know that with\n> enough effort and control of both systems you can tunnel over anything,\n> the point is that ssh is eager to do this for you (overly eager IMHO)\n> \n> ssh depends primarily on certificates that reside on untrusted machines.\n> it can be made to work with tokens or such, but it takes a fair bit of\n> effort.\n> \n> sshd runs as root on just about every system\n> \n> people trust ssh too much. they tend to think that anything is\n> acceptable if it's done over ssh (this isn't a technical issue, but it\n> is a social issue)\n> \n> \n> what would I like to see in an ideal world?\n> \n> something that runs as the git user, does not enable tunneling, and only\n> does the data transfer functions needed for a push. it should use\n> off-the-shelf libraries for certificate authentication and tie into PAM\n> for additional authentication.\n\nHow about a git-specific deployment/configuration of ssh? You can\ncertainly run multiple copies of SSH (on different ports), by providing\na restricted configuration file you can disable tunneling and any other\nfunctionality that you don't like.\n\nAnd if you want it to run as a non-root user, simply choose a port>1024,\nbut keep in mind that you won't be able to authenticate by password\n(IIRC, only key auth will work when running non-root), or setuid to\nthose users when they log in. Nonetheless, this could be sufficient for\ngitosis, since everything runs as the specified user anyway, and IIRC,\ngitosis wants individual SSH pubkeys to allow access.\n\n> the authentication would not be any better than with SSH, but the rest\n> would be better. I was very pleased to watch the git-daemon development,\n> and the emphisis on it running with minimum privilages and provide just\n> the functionality that was needed, and appropriately assuming that any\n> connection from the outside is hostile until proven otherwise.\n\nIn another mail, David wrote:\n\n> 1. if you are running multiple different applications that all want\n> to be exposed via port 22 (like git for 'git push') then you may need\n> to expose numerous machines. tools that use SSH don't tend to have the\n> ability to use a gateway box before they start executing commands,\n> they assume that you will SSH directly into the destination box.\n\nIn many cases, especially if the tool is unix based, you can specify (in\n~/.ssh/config) a Proxy command that is executed before the SSH protocol\nnegotiation begins, which results in stdin and stdout being connected to\nthe SSH daemon at the destination. The most common variations are the\nHTTP and Socks proxy connectors (e.g. corkscrew?), but the sky is really\nthe limit in terms of what is possible.\n\nRogan\n"},{"id":"97930","messageId":"49460CD1.70305@dawes.za.net","threadId":"16650","inReplyTo":"alpine.DEB.1.10.0812150026570.17688@asgard.lang.hm","subject":"Re: is gitosis secure?","fromName":"Rogan Dawes","fromEmail":"lists@dawes.za.net","sentAt":"2008-12-15T07:52:49Z","receivedAt":"2008-12-15T07:52:49Z","isPatch":false,"sender":{"key":"lists@dawes.za.net","avatar":null},"body":"david@lang.hm wrote:\n> On Mon, 15 Dec 2008, Rogan Dawes wrote:\n> \n>> david@lang.hm wrote:\n>>\n>>>\n>>> what would I like to see in an ideal world?\n>>>\n>>> something that runs as the git user, does not enable tunneling, and only\n>>> does the data transfer functions needed for a push. it should use\n>>> off-the-shelf libraries for certificate authentication and tie into PAM\n>>> for additional authentication.\n>>\n>> How about a git-specific deployment/configuration of ssh? You can\n>> certainly run multiple copies of SSH (on different ports), by providing\n>> a restricted configuration file you can disable tunneling and any other\n>> functionality that you don't like.\n>>\n>> And if you want it to run as a non-root user, simply choose a port>1024,\n>> but keep in mind that you won't be able to authenticate by password\n>> (IIRC, only key auth will work when running non-root), or setuid to\n>> those users when they log in. Nonetheless, this could be sufficient for\n>> gitosis, since everything runs as the specified user anyway, and IIRC,\n>> gitosis wants individual SSH pubkeys to allow access.\n> \n> IMHO this is better then exposing a 'normal' ssh daemon to the Internet\n> just to be able to do a git push. the fact that you loose authentication\n> options is not a good thing, are you sure that you cannot hook into PAM\n> authentication for this?\n\nI *think* that an unprivileged user cannot invoke PAM for accounts other\nthan its own, and most certainly cannot change to that other user\nwithout being setuid (or having the appropriate capability).\n\n\n>> In many cases, especially if the tool is unix based, you can specify (in\n>> ~/.ssh/config) a Proxy command that is executed before the SSH protocol\n>> negotiation begins, which results in stdin and stdout being connected to\n>> the SSH daemon at the destination. The most common variations are the\n>> HTTP and Socks proxy connectors (e.g. corkscrew?), but the sky is really\n>> the limit in terms of what is possible.\n> \n> as I just commented, this looks like it's a per-user config option that\n> is designed to be used as a proxy out of the network you are in to get\n> to the Internet, not to be used at the far side of a connection to get\n> to things on a remote network. as I understand it, you would need to\n> change this config file for each different destination network you need\n> to connect to.\n\nThat may be its original intention, but it can nonetheless be used for\nother purposes. Yes, you might need a different configuration for each\nnetwork that you need to access, and quite possibly for each location\nthat you need to access them from. This may result in config entry\nproliferation, but it is manageable, especially with the openssh\nwildcard syntax in the config file.\n\nman ssh_config:\n\nHost\nRestricts the following declarations (up to the next Host keyword) to be\nonly for those hosts that match one of the patterns given after the\nkeyword. If more than one pattern is provided, they should be separated\nby whitespace. A single `*' as a pattern can be used to provide global\ndefaults for all hosts. The host is the hostname argument given on the\ncommand line (i.e. the name is not converted to a canonicalized host\nname before matching).\n\ne.g\n\nHost *-home\n ProxyCommand . . . .\n\nFWIW.\n\nRogan\n"},{"id":"97928","messageId":"alpine.DEB.1.10.0812150024080.17688@asgard.lang.hm","threadId":"16650","inReplyTo":"20081215071737.GA32387@glandium.org","subject":"Re: is gitosis secure?","fromName":"","fromEmail":"david@lang.hm","sentAt":"2008-12-15T08:25:53Z","receivedAt":"2008-12-15T08:25:53Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Mon, 15 Dec 2008, Mike Hommey wrote:\n\n> On Sun, Dec 14, 2008 at 05:00:14PM -0800, david@lang.hm wrote:\n>> 1. if you are running multiple different applications that all want to be\n>> exposed via port 22 (like git for 'git push') then you may need to expose\n>> numerous machines. tools that use SSH don't tend to have the ability to\n>> use a gateway box before they start executing commands, they assume that\n>> you will SSH directly into the destination box.\n>\n> But ssh itself allows you to do proxying. See ProxyCommand in\n> ssh_config's manpage.\n\nI was not aware of that option, but it looks like it's designed to be one \nsetting for all your ssh communications, so unless you always use the same \ngateway box to get to your destination you would need to tweak your ssh \nconfig for each different thing that you are doing.\n\nDavid Lang\n"},{"id":"97936","messageId":"20081215083545.GA3666@glandium.org","threadId":"16650","inReplyTo":"alpine.DEB.1.10.0812150024080.17688@asgard.lang.hm","subject":"Re: is gitosis secure?","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2008-12-15T08:35:45Z","receivedAt":"2008-12-15T08:35:45Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Mon, Dec 15, 2008 at 12:25:53AM -0800, david@lang.hm wrote:\n> On Mon, 15 Dec 2008, Mike Hommey wrote:\n>\n>> On Sun, Dec 14, 2008 at 05:00:14PM -0800, david@lang.hm wrote:\n>>> 1. if you are running multiple different applications that all want to be\n>>> exposed via port 22 (like git for 'git push') then you may need to expose\n>>> numerous machines. tools that use SSH don't tend to have the ability to\n>>> use a gateway box before they start executing commands, they assume that\n>>> you will SSH directly into the destination box.\n>>\n>> But ssh itself allows you to do proxying. See ProxyCommand in\n>> ssh_config's manpage.\n>\n> I was not aware of that option, but it looks like it's designed to be one \n> setting for all your ssh communications, so unless you always use the \n> same gateway box to get to your destination you would need to tweak your \n> ssh config for each different thing that you are doing.\n\nTake a look at Host in the same man page.\n\nMike\n"},{"id":"97929","messageId":"alpine.DEB.1.10.0812150026570.17688@asgard.lang.hm","threadId":"16650","inReplyTo":"49460531.8010808@dawes.za.net","subject":"Re: is gitosis secure?","fromName":"","fromEmail":"david@lang.hm","sentAt":"2008-12-15T08:37:09Z","receivedAt":"2008-12-15T08:37:09Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Mon, 15 Dec 2008, Rogan Dawes wrote:\n\n> david@lang.hm wrote:\n>\n>>\n>> as a security person who doesn't like how ssh is used for everything,\n>> let me list a couple of concerns.\n>>\n>> ssh is default allow (it lets you run any commands), you can lock it\n>> down with effort.\n>>\n>> ssh defaults to establishing a tunnel between machines that other\n>> network traffic can use to bypass your system. yes I know that with\n>> enough effort and control of both systems you can tunnel over anything,\n>> the point is that ssh is eager to do this for you (overly eager IMHO)\n>>\n>> ssh depends primarily on certificates that reside on untrusted machines.\n>> it can be made to work with tokens or such, but it takes a fair bit of\n>> effort.\n>>\n>> sshd runs as root on just about every system\n>>\n>> people trust ssh too much. they tend to think that anything is\n>> acceptable if it's done over ssh (this isn't a technical issue, but it\n>> is a social issue)\n>>\n>>\n>> what would I like to see in an ideal world?\n>>\n>> something that runs as the git user, does not enable tunneling, and only\n>> does the data transfer functions needed for a push. it should use\n>> off-the-shelf libraries for certificate authentication and tie into PAM\n>> for additional authentication.\n>\n> How about a git-specific deployment/configuration of ssh? You can\n> certainly run multiple copies of SSH (on different ports), by providing\n> a restricted configuration file you can disable tunneling and any other\n> functionality that you don't like.\n>\n> And if you want it to run as a non-root user, simply choose a port>1024,\n> but keep in mind that you won't be able to authenticate by password\n> (IIRC, only key auth will work when running non-root), or setuid to\n> those users when they log in. Nonetheless, this could be sufficient for\n> gitosis, since everything runs as the specified user anyway, and IIRC,\n> gitosis wants individual SSH pubkeys to allow access.\n\nIMHO this is better then exposing a 'normal' ssh daemon to the Internet \njust to be able to do a git push. the fact that you loose authentication \noptions is not a good thing, are you sure that you cannot hook into PAM \nauthentication for this?\n\n>> the authentication would not be any better than with SSH, but the rest\n>> would be better. I was very pleased to watch the git-daemon development,\n>> and the emphisis on it running with minimum privilages and provide just\n>> the functionality that was needed, and appropriately assuming that any\n>> connection from the outside is hostile until proven otherwise.\n>\n> In another mail, David wrote:\n>\n>> 1. if you are running multiple different applications that all want\n>> to be exposed via port 22 (like git for 'git push') then you may need\n>> to expose numerous machines. tools that use SSH don't tend to have the\n>> ability to use a gateway box before they start executing commands,\n>> they assume that you will SSH directly into the destination box.\n>\n> In many cases, especially if the tool is unix based, you can specify (in\n> ~/.ssh/config) a Proxy command that is executed before the SSH protocol\n> negotiation begins, which results in stdin and stdout being connected to\n> the SSH daemon at the destination. The most common variations are the\n> HTTP and Socks proxy connectors (e.g. corkscrew?), but the sky is really\n> the limit in terms of what is possible.\n\nas I just commented, this looks like it's a per-user config option that is \ndesigned to be used as a proxy out of the network you are in to get to the \nInternet, not to be used at the far side of a connection to get to things \non a remote network. as I understand it, you would need to change this \nconfig file for each different destination network you need to connect to.\n\nDavid Lang\n"},{"id":"98004","messageId":"20081215212853.GM9772@ece.pdx.edu","threadId":"16650","inReplyTo":"20081215071737.GA32387@glandium.org","subject":"Re: is gitosis secure?","fromName":"Tait","fromEmail":"git.git@t41t.com","sentAt":"2008-12-15T21:28:53Z","receivedAt":"2008-12-15T21:28:53Z","isPatch":false,"sender":{"key":"git.git@t41t.com","avatar":null},"body":"\n> But ssh itself allows you to do proxying. See ProxyCommand in\n> ssh_config's manpage.\n\nI think that's exactly the point David Lang is making.\n\nFor the security-paranoid, maybe the approach gitosis should take\nis to develop an ssh subserver (like sftp). The possibilities for\nrestricted access and configuration are greatly expanded by such an\napproach. One could configure \"sgit\" to chroot into some account-specific\nsubdirectory. The sshd configuration can be tweaked to allow sgit access\nbut not terminal or exec request (or port forwarding) access, perhaps\ndependent on group membership.\n"},{"id":"100959","messageId":"873afgsul8.fsf@mid.deneb.enyo.de","threadId":"16650","inReplyTo":"1228813453.28186.73.camel@maia.lan","subject":"Re: is gitosis secure?","fromName":"Florian Weimer","fromEmail":"fw@deneb.enyo.de","sentAt":"2009-01-18T11:48:51Z","receivedAt":"2009-01-18T11:48:51Z","isPatch":false,"sender":{"key":"fw@deneb.enyo.de","avatar":null},"body":"* Sam Vilain:\n\n> Restricted unix shells are a technology which has been proven secure for\n> decades now.\n\nHuh? Things like scponly and rssh had their share of bugs, so I can\nsee that there is some concern. (And restricted shells used to be\ncircumvented by things like Netscape's print dialog.)\n"},{"id":"100960","messageId":"200901180650.06605.bss@iguanasuicide.net","threadId":"16650","inReplyTo":"873afgsul8.fsf@mid.deneb.enyo.de","subject":"Re: is gitosis secure?","fromName":"Boyd Stephen Smith Jr.","fromEmail":"bss@iguanasuicide.net","sentAt":"2009-01-18T12:50:06Z","receivedAt":"2009-01-18T12:50:06Z","isPatch":false,"sender":{"key":"bss@iguanasuicide.net","avatar":"https://gravatar.com/avatar/84b95eeff194b816c1568b1339e63e4b229825298664a9037b9f1ec713ead1e3?d=mp&s=160"},"body":"On Sunday 18 January 2009, Florian Weimer wrote \nabout 'Re: is gitosis secure?':\n>* Sam Vilain:\n>> Restricted unix shells are a technology which has been proven secure\n>> for decades now.\n>Huh? Things like scponly and rssh had their share of bugs, so I can\n>see that there is some concern. (And restricted shells used to be\n>circumvented by things like Netscape's print dialog.)\n\nFrom my understanding, a restricted shell is a difficult thing to escape \nfrom unless a user is able to run binaries that they have written. FWIW, \nI don't remember sftp or scponly having this particular vulnerability.\n\nEven if a user is allowed to run scripts they have written, escaping from a \nchroot is more difficult, but per-user chroots have their own \nadministrative overhead. They also might be escaped in the case of a \nsimultaneous privilege escalation bug (allowing the attacker to be root in \nthe chroot) and kernel bug (or \"chroot feature\") that gave chrooted root \nto write outside the chroot (for example, to a file they would be \nreasonably sure would be executed).\n\nI can't speak directly to gitosis' security. If users are allowed to, e.g. \nchange the hooks in their repository, there may be an issue there. I \ncertainly haven't done any sort of audit to the source code AND I do not \nhold any security certification--or even job experience in a security \nfield, yet.\n-- \nBoyd Stephen Smith Jr. ,= ,-_-. =. \nbss@iguanasuicide.net ((_/)o o(\\_))\nICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' \nhttp://iguanasuicide.net/ \\_/ \n"},{"id":"100962","messageId":"87skngoifj.fsf@mid.deneb.enyo.de","threadId":"16650","inReplyTo":"200901180650.06605.bss@iguanasuicide.net","subject":"Re: is gitosis secure?","fromName":"Florian Weimer","fromEmail":"fw@deneb.enyo.de","sentAt":"2009-01-18T13:25:04Z","receivedAt":"2009-01-18T13:25:04Z","isPatch":false,"sender":{"key":"fw@deneb.enyo.de","avatar":null},"body":"* Boyd Stephen Smith, Jr.:\n\n> On Sunday 18 January 2009, Florian Weimer wrote \n> about 'Re: is gitosis secure?':\n>>* Sam Vilain:\n>>> Restricted unix shells are a technology which has been proven secure\n>>> for decades now.\n>>Huh? Things like scponly and rssh had their share of bugs, so I can\n>>see that there is some concern. (And restricted shells used to be\n>>circumvented by things like Netscape's print dialog.)\n>\n> From my understanding, a restricted shell is a difficult thing to escape \n> from unless a user is able to run binaries that they have written. FWIW, \n> I don't remember sftp or scponly having this particular vulnerability.\n\nscponly issues due to interpretation conflicts:\n\nCVE-2002-1469 scponly does not properly verify the path when finding the (1) scp or ...\nCVE-2004-1162 The unison command in scponly before 4.0 does not properly restrict ...\nCVE-2005-4533 Argument injection vulnerability in scponlyc in scponly 4.1 and ...\nCVE-2007-6350 scponly 4.6 and earlier allows remote authenticated users to bypass ...\nCVE-2007-6415 scponly 4.6 and earlier allows remote authenticated users to bypass ...\n\nrssh has fewer such issues, only CVE-2004-1161 seems to be intrinsic\nto the program's purpose (but some of the other issues might be used\nas circumvention devices, too).\n\nThat's why I think it's not totally outlandish to assume that\nrestricted shells are usually not very helpful for\ncompartmentalization purposes.\n"},{"id":"100967","messageId":"200901180819.11642.bss@iguanasuicide.net","threadId":"16650","inReplyTo":"87skngoifj.fsf@mid.deneb.enyo.de","subject":"Re: is gitosis secure?","fromName":"Boyd Stephen Smith Jr.","fromEmail":"bss@iguanasuicide.net","sentAt":"2009-01-18T14:19:11Z","receivedAt":"2009-01-18T14:19:11Z","isPatch":false,"sender":{"key":"bss@iguanasuicide.net","avatar":"https://gravatar.com/avatar/84b95eeff194b816c1568b1339e63e4b229825298664a9037b9f1ec713ead1e3?d=mp&s=160"},"body":"On Sunday 18 January 2009, Florian Weimer wrote \nabout 'Re: is gitosis secure?':\n>* Boyd Stephen Smith, Jr.:\n>> On Sunday 18 January 2009, Florian Weimer wrote\n>>\n>> about 'Re: is gitosis secure?':\n>>>* Sam Vilain:\n>>>> Restricted unix shells are a technology which has been proven secure\n>>>> for decades now.\n>>>Huh? Things like scponly and rssh had their share of bugs, so I can\n>>>see that there is some concern. (And restricted shells used to be\n>>\n>> From my understanding, a restricted shell is a difficult thing to\n>> escape from unless a user is able to run binaries that they have\n>> written. FWIW, I don't remember sftp or scponly having this particular\n>> vulnerability.\n>\n>scponly issues due to interpretation conflicts:\n\nNot sure all these apply, but I beleive some of them do, and I want to \nleave the CVE numbers in case someone wants to look them up.\n\n>CVE-2002-1469\n>CVE-2004-1162\n>CVE-2005-4533\n>CVE-2007-6350\n>CVE-2007-6415\n>CVE-2004-1161\n--- End of CVEs to investigate ---\n\n>That's why I think it's not totally outlandish to assume that\n>restricted shells are usually not very helpful for\n>compartmentalization purposes.\n\nI mostly agree with that statement. I make the assumption that, if the \nuser can login via ssh (even under \"only\" a restricted shell) they can do \nanything a user in the same groups can do. I might be overestimating most \npeople, but I don't think I'm underestimating anyone. I do *hope* that I \nget local privilege escalations patched before they are exploited, but I \ncan't guarantee that. (I'm not sure there's really anyway to guarantee \nthat, and I'd hate to upgrade a backup offline then replace the running \ninstance. Especially if I had to go back to when the local privilege \nescalation was introduced [not just when it was \"discovered\"].)\n-- \nBoyd Stephen Smith Jr. ,= ,-_-. =. \nbss@iguanasuicide.net ((_/)o o(\\_))\nICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' \nhttp://iguanasuicide.net/ \\_/ \n"},{"id":"103026","messageId":"20090203213135.GA1970@eagain.net","threadId":"16650","inReplyTo":"200901180650.06605.bss@iguanasuicide.net","subject":"Re: is gitosis secure?","fromName":"Tommi Virtanen","fromEmail":"tv@eagain.net","sentAt":"2009-02-03T21:31:35Z","receivedAt":"2009-02-03T21:31:35Z","isPatch":false,"sender":{"key":"tv@debian.org","avatar":null},"body":"On Sun, Jan 18, 2009 at 06:50:06AM -0600, Boyd Stephen Smith Jr. wrote:\n> I can't speak directly to gitosis' security. If users are allowed to, e.g. \n> change the hooks in their repository, there may be an issue there. I \n> certainly haven't done any sort of audit to the source code AND I do not \n> hold any security certification--or even job experience in a security \n> field, yet.\n\nYou can't change hooks via gitosis, exactly for that reason.\n\nIn the future, I hope to provide ways to configure \"known safe\" hook\nbehavior. Basically something like \"export contents after push to a\nfixed subdirectory of ~git, named after the repo path\" that you can\ntoggle on/off etc, one of those for every interesting hook I\nencounter.\n\nI do not ever want the gitosis admin to be able to do anything but\ndenial of service or repository content destroying attacks. And those\ntwo capabilities are basically needed to do admin things.\n\n\nSummary: I fully expect gitosis to be more secure than a manually\nmaintained git-shell over SSH setup, mostly because it can make\nhuman errors more rare.\n\nI also fully expect SSH(+gitosis)+git-shell to be more secure than\nApache+mod_dav.\n\n-- \n:(){ :|:&};:\n"},{"id":"103027","messageId":"20090203214143.GB1970@eagain.net","threadId":"16650","inReplyTo":"1228813620.18611.41.camel@starfruit.local","subject":"Re: is gitosis secure?","fromName":"Tommi Virtanen","fromEmail":"tv@eagain.net","sentAt":"2009-02-03T21:41:43Z","receivedAt":"2009-02-03T21:41:43Z","isPatch":false,"sender":{"key":"tv@debian.org","avatar":null},"body":"On Tue, Dec 09, 2008 at 01:07:00AM -0800, R. Tyler Ballance wrote:\n> Accounts set up with keys for Gitosis are given restricted accounts\n> (from my understanding similar to how CVS or SVN operate over SSH\n> tunnels).\n\nI don't think I've ever seen a CVS used with \"virtual\"\nrestricted-shell accounts.\n\nThe svnserve --tunnel-user= support for that mode of operation was\nwritten by me, and is basically exactly the same trick as the one used\nby gitosis.\n\nBefore gitosis, I had my old SVN setup pretty much reproduced with\ngit, but then I got bored administering it and wrote gitosis to\nautomate account and access management.\n\n\nI am not aware of anyone ever finding a way to get around an svnserve\n--tunnel-user= setup. I'm not losing my sleep over the security of\nthis concept.\n\nUse an SSH gateway if you want tighter control on who gets where,\nnetwork-wise. Then you won't get non-git login attempts from the\nexternal net.\n\nOr run an extra SSH service, e.g. using Conch. As long as it respects\n~ssh and is interoperable with OpenSSH, gitosis should work just fine.\nIt can even run as the git user 100% of the time.\n\n-- \n:(){ :|:&};:\n"},{"id":"103112","messageId":"20090204121204.GA12393@cuci.nl","threadId":"16650","inReplyTo":"20090203213135.GA1970@eagain.net","subject":"Re: is gitosis secure?","fromName":"Stephen R. van den Berg","fromEmail":"srb@cuci.nl","sentAt":"2009-02-04T12:12:04Z","receivedAt":"2009-02-04T12:12:04Z","isPatch":false,"sender":{"key":"srb@cuci.nl","avatar":"https://gravatar.com/avatar/f75389059e827634d38e9df2a9b6ecbd50028b5a454442efa1c7205b7ff29c6a?d=mp&s=160"},"body":"Tommi Virtanen wrote:\n>Summary: I fully expect gitosis to be more secure than a manually\n>maintained git-shell over SSH setup, mostly because it can make\n>human errors more rare.\n\nI installed gitosis a year ago.\nThen I tried to audit the code.\nI couldn't, the whole thing is too much spaghetti code.\nI.e. the individual python routines might be well written, but there\nis no concise overview in 10 lines max which can explain to me what\nhappens which might or might not open up security holes. There are too\nmany pieces of code depending on each other.\n\nI.e. if you trust the author not to have made any mistakes, then it\nis probably secure.\nAuditing gitosis turned out to be too painful to be worth the trouble,\nso I reverted to a manually maintained git-shell solution which is so\nsimple that I can actually audit it, and therefore is provably secure\n(which gitosis is not).\n-- \nSincerely,\n Stephen R. van den Berg.\nHumor in the Court: Q: What happened then? A: He told me, he says,\n\"I have to kill you because you can identify me.\" Q: Did he kill you? A: No.\n"},{"id":"103177","messageId":"20090204182650.GC1970@eagain.net","threadId":"16650","inReplyTo":"20090204121204.GA12393@cuci.nl","subject":"Re: is gitosis secure?","fromName":"Tommi Virtanen","fromEmail":"tv@eagain.net","sentAt":"2009-02-04T18:26:50Z","receivedAt":"2009-02-04T18:26:50Z","isPatch":false,"sender":{"key":"tv@debian.org","avatar":null},"body":"On Wed, Feb 04, 2009 at 01:12:04PM +0100, Stephen R. van den Berg wrote:\n> I installed gitosis a year ago.\n> Then I tried to audit the code.\n> I couldn't, the whole thing is too much spaghetti code.\n\nHuh. It's about 1000 lines of python, with about 2000 lines of unit\ntests. It has 3 top-level operations: init, serve, run_hook. That\nstill counts as \"tiny\" in my mind. I'm sorry if following the code was\ntoo hard. I guess there's no accounting for taste.\n\n> Auditing gitosis turned out to be too painful to be worth the trouble,\n> so I reverted to a manually maintained git-shell solution which is so\n> simple that I can actually audit it, and therefore is provably secure\n> (which gitosis is not).\n\nThis word, \"provably\", tends to mean something else than what you use\nit for. Definitely a simple audit doesn't prove anything. Most\nreal-world software is complex enough to be practically unprovable for\nanything.\n\n-- \n:(){ :|:&};:\n"},{"id":"103287","messageId":"20090205075243.GA29080@cuci.nl","threadId":"16650","inReplyTo":"20090204182650.GC1970@eagain.net","subject":"Re: is gitosis secure?","fromName":"Stephen R. van den Berg","fromEmail":"srb@cuci.nl","sentAt":"2009-02-05T07:52:43Z","receivedAt":"2009-02-05T07:52:43Z","isPatch":false,"sender":{"key":"srb@cuci.nl","avatar":"https://gravatar.com/avatar/f75389059e827634d38e9df2a9b6ecbd50028b5a454442efa1c7205b7ff29c6a?d=mp&s=160"},"body":"Tommi Virtanen wrote:\n>On Wed, Feb 04, 2009 at 01:12:04PM +0100, Stephen R. van den Berg wrote:\n>> I installed gitosis a year ago.\n>> Then I tried to audit the code.\n>> I couldn't, the whole thing is too much spaghetti code.\n\n>Huh. It's about 1000 lines of python, with about 2000 lines of unit\n>tests. It has 3 top-level operations: init, serve, run_hook. That\n>still counts as \"tiny\" in my mind. I'm sorry if following the code was\n>too hard. I guess there's no accounting for taste.\n\nIt would help if there were a 10 to 60 line synopsis of what it does\nin the critical cases. I mean, I don't care about features, but I care\nabout the critical parts that interact with the shell and ssh. In order\nto audit that I need a concise 60 line max piece of code or text where\nI can get all the info from. 1000 lines for that is too much.\n\n>> Auditing gitosis turned out to be too painful to be worth the trouble,\n>> so I reverted to a manually maintained git-shell solution which is so\n>> simple that I can actually audit it, and therefore is provably secure\n>> (which gitosis is not).\n\n>This word, \"provably\", tends to mean something else than what you use\n>it for. Definitely a simple audit doesn't prove anything. Most\n>real-world software is complex enough to be practically unprovable for\n>anything.\n\nWhat I meant by \"provably secure\" in this context is that in addition\nto basic security holes already/still present in the OS, /bin/sh and ssh,\nmy scripts do not introduce extra security holes.\n\nAs a matter of fact, I replaced gitosis by two shell scripts of 31 and\n50 lines each (including empty lines). I.e. the pieces of code needing\nauditing are exactly 81 lines total.\n\nI'm not saying that gitosis has security holes, it's just that it's rather\ndifficult to assure that it doesn't, given the size.\n-- \nSincerely,\n Stephen R. van den Berg.\nAuto repair rates: basic labor $40/hour; if you wait, $60; if you watch, $80;\nif you ask questions, $100; if you help, $120; if you laugh, $140.\n"},{"id":"103294","messageId":"20090205080419.GD1970@eagain.net","threadId":"16650","inReplyTo":"20090205075243.GA29080@cuci.nl","subject":"Re: is gitosis secure?","fromName":"Tommi Virtanen","fromEmail":"tv@eagain.net","sentAt":"2009-02-05T08:04:19Z","receivedAt":"2009-02-05T08:04:19Z","isPatch":false,"sender":{"key":"tv@debian.org","avatar":null},"body":"On Thu, Feb 05, 2009 at 08:52:43AM +0100, Stephen R. van den Berg wrote:\n> It would help if there were a 10 to 60 line synopsis of what it does\n> in the critical cases. I mean, I don't care about features, but I care\n> about the critical parts that interact with the shell and ssh. In order\n> to audit that I need a concise 60 line max piece of code or text where\n> I can get all the info from. 1000 lines for that is too much.\n\nI'm kinda bad about trusting any kind of design documents. The code\nisn't going to match the design document for many months, anyway. That\nalso means I'm more likely to put effort into having the code be\nreadable, than in *separately* describing it.\n\nWhat do you think are the \"critical cases\"?\n\nrun_hook: reads config files and writes ~/.ssh/authorized_keys.\n\nserve: takes untrusted user input, checks ACLs, execs git-shell.\n\nHonestly, apart from details of how the ACLs are implemented etc,\nthat's pretty simple.\n\nSome of the code structure is historical baggage, e.g. the ACL\nmechanism can map repo names on the fly, but it should still be pretty\nsimple to just read through and get the picture.\n\nI have no real interest in writing up how SSH's authorized_keys works.\nThat belongs in OpenSSH, anyway.\n\n-- \n:(){ :|:&};:\n"}]}