is gitosis secure?

is gitosis secure?

[Thomas Koch]

Sorry for the shameless subject, but I presented gitosis yesterday to
our sysadmin and he wasn't much delighted to learn, that write access to
repositories hosted with gitosis would need SSH access.

So could you help me out in this discussion, whether to use or not to
use gitosis? 
Our admin would prefer to not open SSH at all outside our LAN, but
developers would need to have write access also outside the office.

Best regards,
-- 
Thomas Koch, Software Developer
http://www.koch.ro

Young Media Concepts GmbH
Sonnenstr. 4
CH-8280 Kreuzlingen
Switzerland

Tel    +41 (0)71 / 508 24 86
Fax    +41 (0)71 / 560 53 89
Mobile +49 (0)170 / 753 89 16
Web    www.ymc.ch

Re: is gitosis secure?

[Sam Vilain]

On Tue, 2008-12-09 at 09:56 +0100, Thomas Koch wrote:
> Sorry for the shameless subject, but I presented gitosis yesterday to
> our sysadmin and he wasn't much delighted to learn, that write access to
> repositories hosted with gitosis would need SSH access.
> 
> So could you help me out in this discussion, whether to use or not to
> use gitosis? 
> Our admin would prefer to not open SSH at all outside our LAN, but
> developers would need to have write access also outside the office.

Restricted unix shells are a technology which has been proven secure for
decades now.  If you use git-shell, you are keeping the secure part of
SSH - the authentication and encryption - and restricting the SSH access
part to the bare minimum required for useful access to the required
services.

ie ... it all comes down to the shell you give those 'login' users as to
what they can do.

Sam.

Re: is gitosis secure?

[Florian Weimer]

* Sam Vilain:

> Restricted unix shells are a technology which has been proven secure for
> decades now.

Huh?  Things like scponly and rssh had their share of bugs, so I can
see that there is some concern.  (And restricted shells used to be
circumvented by things like Netscape's print dialog.)

Re: is gitosis secure?

[Boyd Stephen Smith Jr.]

[-- Attachment #1: Type: text/plain, Size: 1651 bytes --]

On Sunday 18 January 2009, Florian Weimer <fw@deneb.enyo.de> wrote 
about 'Re: is gitosis secure?':
>* Sam Vilain:
>> Restricted unix shells are a technology which has been proven secure
>> for decades now.
>Huh?  Things like scponly and rssh had their share of bugs, so I can
>see that there is some concern.  (And restricted shells used to be
>circumvented by things like Netscape's print dialog.)

From my understanding, a restricted shell is a difficult thing to escape 
from unless a user is able to run binaries that they have written.  FWIW, 
I don't remember sftp or scponly having this particular vulnerability.

Even if a user is allowed to run scripts they have written, escaping from a 
chroot is more difficult, but per-user chroots have their own 
administrative overhead.  They also might be escaped in the case of a 
simultaneous privilege escalation bug (allowing the attacker to be root in 
the chroot) and kernel bug (or "chroot feature") that gave chrooted root 
to write outside the chroot (for example, to a file they would be 
reasonably sure would be executed).

I can't speak directly to gitosis' security.  If users are allowed to, e.g. 
change the hooks in their repository, there may be an issue there.  I 
certainly haven't done any sort of audit to the source code AND I do not 
hold any security certification--or even job experience in a security 
field, yet.
-- 
Boyd Stephen Smith Jr.                     ,= ,-_-. =. 
bss@iguanasuicide.net                     ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.net/                      \_/     

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: is gitosis secure?

[Florian Weimer]

* Boyd Stephen Smith, Jr.:

> On Sunday 18 January 2009, Florian Weimer <fw@deneb.enyo.de> wrote 
> about 'Re: is gitosis secure?':
>>* Sam Vilain:
>>> Restricted unix shells are a technology which has been proven secure
>>> for decades now.
>>Huh?  Things like scponly and rssh had their share of bugs, so I can
>>see that there is some concern.  (And restricted shells used to be
>>circumvented by things like Netscape's print dialog.)
>
> From my understanding, a restricted shell is a difficult thing to escape 
> from unless a user is able to run binaries that they have written.  FWIW, 
> I don't remember sftp or scponly having this particular vulnerability.

scponly issues due to interpretation conflicts:

CVE-2002-1469   scponly does not properly verify the path when finding the (1) scp or ...
CVE-2004-1162   The unison command in scponly before 4.0 does not properly restrict ...
CVE-2005-4533   Argument injection vulnerability in scponlyc in scponly 4.1 and ...
CVE-2007-6350   scponly 4.6 and earlier allows remote authenticated users to bypass ...
CVE-2007-6415   scponly 4.6 and earlier allows remote authenticated users to bypass ...

rssh has fewer such issues, only CVE-2004-1161 seems to be intrinsic
to the program's purpose (but some of the other issues might be used
as circumvention devices, too).

That's why I think it's not totally outlandish to assume that
restricted shells are usually not very helpful for
compartmentalization purposes.

Re: is gitosis secure?

[Boyd Stephen Smith Jr.]

[-- Attachment #1: Type: text/plain, Size: 2114 bytes --]

On Sunday 18 January 2009, Florian Weimer <fw@deneb.enyo.de> wrote 
about 'Re: is gitosis secure?':
>* Boyd Stephen Smith, Jr.:
>> On Sunday 18 January 2009, Florian Weimer <fw@deneb.enyo.de> wrote
>>
>> about 'Re: is gitosis secure?':
>>>* Sam Vilain:
>>>> Restricted unix shells are a technology which has been proven secure
>>>> for decades now.
>>>Huh?  Things like scponly and rssh had their share of bugs, so I can
>>>see that there is some concern.  (And restricted shells used to be
>>
>> From my understanding, a restricted shell is a difficult thing to
>> escape from unless a user is able to run binaries that they have
>> written.  FWIW, I don't remember sftp or scponly having this particular
>> vulnerability.
>
>scponly issues due to interpretation conflicts:

Not sure all these apply, but I beleive some of them do, and I want to 
leave the CVE numbers in case someone wants to look them up.

>CVE-2002-1469
>CVE-2004-1162
>CVE-2005-4533
>CVE-2007-6350
>CVE-2007-6415
>CVE-2004-1161
--- End of CVEs to investigate ---

>That's why I think it's not totally outlandish to assume that
>restricted shells are usually not very helpful for
>compartmentalization purposes.

I mostly agree with that statement.  I make the assumption that, if the 
user can login via ssh (even under "only" a restricted shell) they can do 
anything a user in the same groups can do.  I might be overestimating most 
people, but I don't think I'm underestimating anyone.  I do *hope* that I 
get local privilege escalations patched before they are exploited, but I 
can't guarantee that.  (I'm not sure there's really anyway to guarantee 
that, and I'd hate to upgrade a backup offline then replace the running 
instance.  Especially if I had to go back to when the local privilege 
escalation was introduced [not just when it was "discovered"].)
-- 
Boyd Stephen Smith Jr.                     ,= ,-_-. =. 
bss@iguanasuicide.net                     ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.net/                      \_/     

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: is gitosis secure?

[Tommi Virtanen]

On Sun, Jan 18, 2009 at 06:50:06AM -0600, Boyd Stephen Smith Jr. wrote:
> I can't speak directly to gitosis' security.  If users are allowed to, e.g. 
> change the hooks in their repository, there may be an issue there.  I 
> certainly haven't done any sort of audit to the source code AND I do not 
> hold any security certification--or even job experience in a security 
> field, yet.

You can't change hooks via gitosis, exactly for that reason.

In the future, I hope to provide ways to configure "known safe" hook
behavior. Basically something like "export contents after push to a
fixed subdirectory of ~git, named after the repo path" that you can
toggle on/off etc, one of those for every interesting hook I
encounter.

I do not ever want the gitosis admin to be able to do anything but
denial of service or repository content destroying attacks. And those
two capabilities are basically needed to do admin things.


Summary: I fully expect gitosis to be more secure than a manually
maintained git-shell over SSH setup, mostly because it can make
human errors more rare.

I also fully expect SSH(+gitosis)+git-shell to be more secure than
Apache+mod_dav.

-- 
:(){ :|:&};:

Re: is gitosis secure?

[Stephen R. van den Berg]

Tommi Virtanen wrote:
>Summary: I fully expect gitosis to be more secure than a manually
>maintained git-shell over SSH setup, mostly because it can make
>human errors more rare.

I installed gitosis a year ago.
Then I tried to audit the code.
I couldn't, the whole thing is too much spaghetti code.
I.e. the individual python routines might be well written, but there
is no concise overview in 10 lines max which can explain to me what
happens which might or might not open up security holes.  There are too
many pieces of code depending on each other.

I.e. if you trust the author not to have made any mistakes, then it
is probably secure.
Auditing gitosis turned out to be too painful to be worth the trouble,
so I reverted to a manually maintained git-shell solution which is so
simple that I can actually audit it, and therefore is provably secure
(which gitosis is not).
-- 
Sincerely,
           Stephen R. van den Berg.
Humor in the Court:  Q: What happened then?  A: He told me, he says,
"I have to kill you because you can identify me."  Q: Did he kill you?  A: No.

Re: is gitosis secure?

[Tommi Virtanen]

On Wed, Feb 04, 2009 at 01:12:04PM +0100, Stephen R. van den Berg wrote:
> I installed gitosis a year ago.
> Then I tried to audit the code.
> I couldn't, the whole thing is too much spaghetti code.

Huh. It's about 1000 lines of python, with about 2000 lines of unit
tests. It has 3 top-level operations: init, serve, run_hook. That
still counts as "tiny" in my mind. I'm sorry if following the code was
too hard. I guess there's no accounting for taste.

> Auditing gitosis turned out to be too painful to be worth the trouble,
> so I reverted to a manually maintained git-shell solution which is so
> simple that I can actually audit it, and therefore is provably secure
> (which gitosis is not).

This word, "provably", tends to mean something else than what you use
it for. Definitely a simple audit doesn't prove anything. Most
real-world software is complex enough to be practically unprovable for
anything.

-- 
:(){ :|:&};:

Re: is gitosis secure?

[Stephen R. van den Berg]

Tommi Virtanen wrote:
>On Wed, Feb 04, 2009 at 01:12:04PM +0100, Stephen R. van den Berg wrote:
>> I installed gitosis a year ago.
>> Then I tried to audit the code.
>> I couldn't, the whole thing is too much spaghetti code.

>Huh. It's about 1000 lines of python, with about 2000 lines of unit
>tests. It has 3 top-level operations: init, serve, run_hook. That
>still counts as "tiny" in my mind. I'm sorry if following the code was
>too hard. I guess there's no accounting for taste.

It would help if there were a 10 to 60 line synopsis of what it does
in the critical cases.  I mean, I don't care about features, but I care
about the critical parts that interact with the shell and ssh.  In order
to audit that I need a concise 60 line max piece of code or text where
I can get all the info from.  1000 lines for that is too much.

>> Auditing gitosis turned out to be too painful to be worth the trouble,
>> so I reverted to a manually maintained git-shell solution which is so
>> simple that I can actually audit it, and therefore is provably secure
>> (which gitosis is not).

>This word, "provably", tends to mean something else than what you use
>it for. Definitely a simple audit doesn't prove anything. Most
>real-world software is complex enough to be practically unprovable for
>anything.

What I meant by "provably secure" in this context is that in addition
to basic security holes already/still present in the OS, /bin/sh and ssh,
my scripts do not introduce extra security holes.

As a matter of fact, I replaced gitosis by two shell scripts of 31 and
50 lines each (including empty lines).  I.e. the pieces of code needing
auditing are exactly 81 lines total.

I'm not saying that gitosis has security holes, it's just that it's rather
difficult to assure that it doesn't, given the size.
-- 
Sincerely,
           Stephen R. van den Berg.
Auto repair rates: basic labor $40/hour; if you wait, $60; if you watch, $80;
if you ask questions, $100; if you help, $120; if you laugh, $140.

Re: is gitosis secure?

[Tommi Virtanen]

On Thu, Feb 05, 2009 at 08:52:43AM +0100, Stephen R. van den Berg wrote:
> It would help if there were a 10 to 60 line synopsis of what it does
> in the critical cases.  I mean, I don't care about features, but I care
> about the critical parts that interact with the shell and ssh.  In order
> to audit that I need a concise 60 line max piece of code or text where
> I can get all the info from.  1000 lines for that is too much.

I'm kinda bad about trusting any kind of design documents. The code
isn't going to match the design document for many months, anyway. That
also means I'm more likely to put effort into having the code be
readable, than in *separately* describing it.

What do you think are the "critical cases"?

run_hook: reads config files and writes ~/.ssh/authorized_keys.

serve: takes untrusted user input, checks ACLs, execs git-shell.

Honestly, apart from details of how the ACLs are implemented etc,
that's pretty simple.

Some of the code structure is historical baggage, e.g. the ACL
mechanism can map repo names on the fly, but it should still be pretty
simple to just read through and get the picture.

I have no real interest in writing up how SSH's authorized_keys works.
That belongs in OpenSSH, anyway.

-- 
:(){ :|:&};:

Re: is gitosis secure?

[R. Tyler Ballance]

[-- Attachment #1: Type: text/plain, Size: 1477 bytes --]

On Tue, 2008-12-09 at 09:56 +0100, Thomas Koch wrote:
> Sorry for the shameless subject, but I presented gitosis yesterday to
> our sysadmin and he wasn't much delighted to learn, that write access to
> repositories hosted with gitosis would need SSH access.

Accounts set up with keys for Gitosis are given restricted accounts
(from my understanding similar to how CVS or SVN operate over SSH
tunnels). 

The sysadmins here at Slide also had similar frustrations/concerns about
using Gitosis, but we were able to convince them that keys were a far
better solution than keyboard-interactive login sessions over HTTPS for
Subversion.

We're using gitosis with plenty of developers (coming up on 50) and
haven't had any issues with security (yet, crossed fingers). We even
have some accounts that are able to read but not write, i.e. they can
clone and pull, but not push back up to the central repository. YMMV.

> 
> So could you help me out in this discussion, whether to use or not to
> use gitosis? 
> Our admin would prefer to not open SSH at all outside our LAN, but
> developers would need to have write access also outside the office.

I recommend using VPN if the need to push/pull while outside of the
office (more fun solutions include SSH gateways that tunnel outside to
inside). Otherwise, why could they not simply commit locally, etc, and
then when they come into the office push/pull?

Cheers
-- 
-R. Tyler Ballance
Slide, Inc.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: is gitosis secure?

[Tommi Virtanen]

On Tue, Dec 09, 2008 at 01:07:00AM -0800, R. Tyler Ballance wrote:
> Accounts set up with keys for Gitosis are given restricted accounts
> (from my understanding similar to how CVS or SVN operate over SSH
> tunnels).

I don't think I've ever seen a CVS used with "virtual"
restricted-shell accounts.

The svnserve --tunnel-user= support for that mode of operation was
written by me, and is basically exactly the same trick as the one used
by gitosis.

Before gitosis, I had my old SVN setup pretty much reproduced with
git, but then I got bored administering it and wrote gitosis to
automate account and access management.


I am not aware of anyone ever finding a way to get around an svnserve
--tunnel-user= setup. I'm not losing my sleep over the security of
this concept.

Use an SSH gateway if you want tighter control on who gets where,
network-wise. Then you won't get non-git login attempts from the
external net.

Or run an extra SSH service, e.g. using Conch. As long as it respects
~ssh and is interoperable with OpenSSH, gitosis should work just fine.
It can even run as the git user 100% of the time.

-- 
:(){ :|:&};:

Re: is gitosis secure?

[Sverre Rabbelier]

On Tue, Dec 9, 2008 at 09:56, Thomas Koch <thomas@koch.ro> wrote:
> Our admin would prefer to not open SSH at all outside our LAN, but
> developers would need to have write access also outside the office.

What safer to connect to the LAN than with SSH? What _would_ your
system admin be happy with using?

-- 
Cheers,

Sverre Rabbelier

Re: is gitosis secure?

[Nix]

On 9 Dec 2008, Sverre Rabbelier spake thusly:

> On Tue, Dec 9, 2008 at 09:56, Thomas Koch <thomas@koch.ro> wrote:
>> Our admin would prefer to not open SSH at all outside our LAN, but
>> developers would need to have write access also outside the office.
>
> What safer to connect to the LAN than with SSH? What _would_ your
> system admin be happy with using?

telnet. I do not jest, this is our sysadmins' stated reasons for not
opening the git port and for tweaking their (mandatory) HTTP proxy to
block HTTP traffic from git.

(Telnet over some horrible impossibly slow buggy proprietary VPN.
It takes >5min to bring up a single connection.)

Do not underestimate the stupidity and hideboundedness of undertrained
system administrators, for it is vast.

Re: is gitosis secure?

[Sverre Rabbelier]

On Sat, Dec 13, 2008 at 17:23, Nix <nix@esperi.org.uk> wrote:
> telnet. I do not jest, this is our sysadmins' stated reasons for not
> opening the git port and for tweaking their (mandatory) HTTP proxy to
> block HTTP traffic from git.

I don't know what to say to this :P.

> (Telnet over some horrible impossibly slow buggy proprietary VPN.
> It takes >5min to bring up a single connection.)

I feel for you man, try and get that guy fired and have them hire some
_real_ sysadmins!

> Do not underestimate the stupidity and hideboundedness of undertrained
> system administrators, for it is vast.

This is beyond doubt.

-- 
Cheers,

Sverre Rabbelier

Re: is gitosis secure?

[Sitaram Chamarty]

On 2008-12-13, Nix <nix@esperi.org.uk> wrote:
> telnet. I do not jest, this is our sysadmins' stated reasons for not
> opening the git port and for tweaking their (mandatory) HTTP proxy to
> block HTTP traffic from git.

Wow -- my sympathies!

But on occasion, when real or imaginary issues prevented me
from making a live connection, I have used "git bundle" to
do the job.  Not as satisfactory as a real connection, but
when you have a proper, non-fast-forwarding, repo as the
"mother ship", git bundle with some custom procmail scripts
on both sides can work OK enough.

To do that with a public repo you'd have to mirror that on a
home machine and let your restricted environment work
against that.

> Do not underestimate the stupidity and hideboundedness of undertrained
> system administrators, for it is vast.

These same administrators also underestimate (i) the number
of well connected home machines and (ii) the idea that on
his own machine, everyone is root.

Most of these blocks are "default allow", and your home IP
is not on that list and they don't have the smarts to figure
out that you're getting around their blocks :-) Add dynamic
IP and a dyndns hostname (and dyndns has a hundred or so 2nd
level domains to choose your 3rd level hostname from!) and
clueless admins don't stand a chance.

[sorry this is so badly off-topic...]

Re: is gitosis secure?

[david]

this is really a reply to an earlier message that I deleted.

the question was asked 'what would the security people like instead of 
SSH'

as a security person who doesn't like how ssh is used for everything, let 
me list a couple of concerns.

ssh is default allow (it lets you run any commands), you can lock it down 
with effort.

ssh defaults to establishing a tunnel between machines that other network 
traffic can use to bypass your system. yes I know that with enough effort 
and control of both systems you can tunnel over anything, the point is 
that ssh is eager to do this for you (overly eager IMHO)

ssh depends primarily on certificates that reside on untrusted machines. 
it can be made to work with tokens or such, but it takes a fair bit of 
effort.

sshd runs as root on just about every system

people trust ssh too much. they tend to think that anything is acceptable 
if it's done over ssh (this isn't a technical issue, but it is a social 
issue)


what would I like to see in an ideal world?

something that runs as the git user, does not enable tunneling, and only 
does the data transfer functions needed for a push. it should use 
off-the-shelf libraries for certificate authentication and tie into PAM 
for additional authentication.

the authentication would not be any better than with SSH, but the rest 
would be better. I was very pleased to watch the git-daemon development, 
and the emphisis on it running with minimum privilages and provide just 
the functionality that was needed, and appropriately assuming that any 
connection from the outside is hostile until proven otherwise.


what would I do with current tools?

I would say that developers working from outside should VPN into the 
company network before doing the push with SSH rather than exposing the 
SSH daemon to the entire Internet.

in the medium term, if the git-over-http gets finished, I would like to 
see a seperate cgi created to allow push as well. http is overused as a 
tunneling protocol, but it's easy to setup a server that can't do anything 
except what you want, so this tunneling is generally not a threat to 
servers (it's a horrible threat to client systems)

David Lang

Re: is gitosis secure?

[martin]

Dear David.
Why do you trust VPN more than the SSH?
I ask because I have just removed the "first VPN then SSH" solution in 
favor for a SSH only solution using Gitosis just to get rid of the VPN 
which I believe is less secure than SSH (well until I read you comments 
below).
I thought I was doing something right for once but maybe I'm not?
Thanks and best regards
Martin

david@lang.hm wrote:
> this is really a reply to an earlier message that I deleted.
>
> the question was asked 'what would the security people like instead of 
> SSH'
>
> as a security person who doesn't like how ssh is used for everything, 
> let me list a couple of concerns.
>
> ssh is default allow (it lets you run any commands), you can lock it 
> down with effort.
>
> ssh defaults to establishing a tunnel between machines that other 
> network traffic can use to bypass your system. yes I know that with 
> enough effort and control of both systems you can tunnel over 
> anything, the point is that ssh is eager to do this for you (overly 
> eager IMHO)
>
> ssh depends primarily on certificates that reside on untrusted 
> machines. it can be made to work with tokens or such, but it takes a 
> fair bit of effort.
>
> sshd runs as root on just about every system
>
> people trust ssh too much. they tend to think that anything is 
> acceptable if it's done over ssh (this isn't a technical issue, but it 
> is a social issue)
>
>
> what would I like to see in an ideal world?
>
> something that runs as the git user, does not enable tunneling, and 
> only does the data transfer functions needed for a push. it should use 
> off-the-shelf libraries for certificate authentication and tie into 
> PAM for additional authentication.
>
> the authentication would not be any better than with SSH, but the rest 
> would be better. I was very pleased to watch the git-daemon 
> development, and the emphisis on it running with minimum privilages 
> and provide just the functionality that was needed, and appropriately 
> assuming that any connection from the outside is hostile until proven 
> otherwise.
>
>
> what would I do with current tools?
>
> I would say that developers working from outside should VPN into the 
> company network before doing the push with SSH rather than exposing 
> the SSH daemon to the entire Internet.
>
> in the medium term, if the git-over-http gets finished, I would like 
> to see a seperate cgi created to allow push as well. http is overused 
> as a tunneling protocol, but it's easy to setup a server that can't do 
> anything except what you want, so this tunneling is generally not a 
> threat to servers (it's a horrible threat to client systems)
>
> David Lang
> -- 
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: is gitosis secure?

[david]

On Sun, 14 Dec 2008, martin wrote:

> Dear David.
> Why do you trust VPN more than the SSH?
> I ask because I have just removed the "first VPN then SSH" solution in favor 
> for a SSH only solution using Gitosis just to get rid of the VPN which I 
> believe is less secure than SSH (well until I read you comments below).
> I thought I was doing something right for once but maybe I'm not?
> Thanks and best regards
> Martin

in part it's that a VPN is a single point of control for all remote 
access.

If you use ssh you end up exposing all the individual machines

1. data leakage of just what machines exist to possibly hostile users.

2. the many machines are configured seperatly, frequently by different 
people. this makes it far more likely that sometime some machine will get 
misconfigured.

3. people who are focused on providing features have a strong temptation 
to cut corners and just test that the feature works and not test that 
everything that isn't supposed to work actually doesn't work. as a 
result, in many companies there is a deliberate seperation (and tension) 
between a group focused on controlling and auditing access and one that is 
focused on creating fucntionality and features.

also from a polical/social point of view everyone recognises that if you 
grant someone VPN access you are trusting them, but people don't seem to 
think the same way with ssh.

David Lang

> david@lang.hm wrote:
>> this is really a reply to an earlier message that I deleted.
>> 
>> the question was asked 'what would the security people like instead of SSH'
>> 
>> as a security person who doesn't like how ssh is used for everything, let 
>> me list a couple of concerns.
>> 
>> ssh is default allow (it lets you run any commands), you can lock it down 
>> with effort.
>> 
>> ssh defaults to establishing a tunnel between machines that other network 
>> traffic can use to bypass your system. yes I know that with enough effort 
>> and control of both systems you can tunnel over anything, the point is that 
>> ssh is eager to do this for you (overly eager IMHO)
>> 
>> ssh depends primarily on certificates that reside on untrusted machines. it 
>> can be made to work with tokens or such, but it takes a fair bit of effort.
>> 
>> sshd runs as root on just about every system
>> 
>> people trust ssh too much. they tend to think that anything is acceptable 
>> if it's done over ssh (this isn't a technical issue, but it is a social 
>> issue)
>> 
>> 
>> what would I like to see in an ideal world?
>> 
>> something that runs as the git user, does not enable tunneling, and only 
>> does the data transfer functions needed for a push. it should use 
>> off-the-shelf libraries for certificate authentication and tie into PAM for 
>> additional authentication.
>> 
>> the authentication would not be any better than with SSH, but the rest 
>> would be better. I was very pleased to watch the git-daemon development, 
>> and the emphisis on it running with minimum privilages and provide just the 
>> functionality that was needed, and appropriately assuming that any 
>> connection from the outside is hostile until proven otherwise.
>> 
>> 
>> what would I do with current tools?
>> 
>> I would say that developers working from outside should VPN into the 
>> company network before doing the push with SSH rather than exposing the SSH 
>> daemon to the entire Internet.
>> 
>> in the medium term, if the git-over-http gets finished, I would like to see 
>> a seperate cgi created to allow push as well. http is overused as a 
>> tunneling protocol, but it's easy to setup a server that can't do anything 
>> except what you want, so this tunneling is generally not a threat to 
>> servers (it's a horrible threat to client systems)
>> 
>> David Lang
>> -- 
>> To unsubscribe from this list: send the line "unsubscribe git" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> 
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: is gitosis secure?

[Jakub Narebski]

david@lang.hm writes:
> On Sun, 14 Dec 2008, martin wrote:
> 
> > Dear David.
> > Why do you trust VPN more than the SSH?
> > I ask because I have just removed the "first VPN then SSH" solution
> > in favor for a SSH only solution using Gitosis just to get rid of
> > the VPN which I believe is less secure than SSH (well until I read
> > you comments below).
> > I thought I was doing something right for once but maybe I'm not?
> > Thanks and best regards
> > Martin
> 
> in part it's that a VPN is a single point of control for all remote
> access.
> 
> If you use ssh you end up exposing all the individual machines
> 
> 1. data leakage of just what machines exist to possibly hostile users.

Errr... what? One of established practices is expose only _one_
machine to outside; you have to SSH to gateway.
 
> 2. the many machines are configured seperatly, frequently by different
> people. this makes it far more likely that sometime some machine will
> get misconfigured.

See above.

> 3. people who are focused on providing features have a strong
> temptation to cut corners and just test that the feature works and not
> test that everything that isn't supposed to work actually doesn't
> work. as a result, in many companies there is a deliberate seperation
> (and tension) between a group focused on controlling and auditing
> access and one that is focused on creating fucntionality and features.

And that differs from VPN in what way?

> also from a polical/social point of view everyone recognises that if
> you grant someone VPN access you are trusting them, but people don't
> seem to think the same way with ssh.

Errr... what?  I think everybody knows that unrestricted SSH access
(without limiting done by shell used) means that you trust user.

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: is gitosis secure?

[david]

On Sun, 14 Dec 2008, Jakub Narebski wrote:

> david@lang.hm writes:
>> On Sun, 14 Dec 2008, martin wrote:
>>
>>> Dear David.
>>> Why do you trust VPN more than the SSH?
>>> I ask because I have just removed the "first VPN then SSH" solution
>>> in favor for a SSH only solution using Gitosis just to get rid of
>>> the VPN which I believe is less secure than SSH (well until I read
>>> you comments below).
>>> I thought I was doing something right for once but maybe I'm not?
>>> Thanks and best regards
>>> Martin
>>
>> in part it's that a VPN is a single point of control for all remote
>> access.
>>
>> If you use ssh you end up exposing all the individual machines
>>
>> 1. data leakage of just what machines exist to possibly hostile users.
>
> Errr... what? One of established practices is expose only _one_
> machine to outside; you have to SSH to gateway.

that works for sysadmin access to a box, it doesn't work for git push 
(unless that box also happens to be your git repository). multiply by a 
few dozen different applications that all take the attitude 'just us SSH 
and you are secure' and you end up with a bunch of machines that _have_ to 
be exposed via SSH.

>> 2. the many machines are configured seperatly, frequently by different
>> people. this makes it far more likely that sometime some machine will
>> get misconfigured.
>
> See above.
>
>> 3. people who are focused on providing features have a strong
>> temptation to cut corners and just test that the feature works and not
>> test that everything that isn't supposed to work actually doesn't
>> work. as a result, in many companies there is a deliberate seperation
>> (and tension) between a group focused on controlling and auditing
>> access and one that is focused on creating fucntionality and features.
>
> And that differs from VPN in what way?

the VPN is typically (but not always) run by the group who is focused on 
controlling and auditing access.

>> also from a polical/social point of view everyone recognises that if
>> you grant someone VPN access you are trusting them, but people don't
>> seem to think the same way with ssh.
>
> Errr... what?  I think everybody knows that unrestricted SSH access
> (without limiting done by shell used) means that you trust user.

you would be surprised.

I'm not saying that SSH is bad for all uses by any means. I'm responding 
to the people who seemd to be thinking that anyone who didn't like the 
'use SSH' option are luddites and just don't know what they are doing. 
different networks can have different stances and all be right (for their 
environment)

David Lang

Re: is gitosis secure?

[martin]

david@lang.hm wrote:
> On Sun, 14 Dec 2008, martin wrote:
>
>> Dear David.
>> Why do you trust VPN more than the SSH?
>> I ask because I have just removed the "first VPN then SSH" solution 
>> in favor for a SSH only solution using Gitosis just to get rid of the 
>> VPN which I believe is less secure than SSH (well until I read you 
>> comments below).
>> I thought I was doing something right for once but maybe I'm not?
>> Thanks and best regards
>> Martin
>
> in part it's that a VPN is a single point of control for all remote 
> access.
>
> If you use ssh you end up exposing all the individual machines
>
> 1. data leakage of just what machines exist to possibly hostile users.
>
> 2. the many machines are configured seperatly, frequently by different 
> people. this makes it far more likely that sometime some machine will 
> get misconfigured.
>
> 3. people who are focused on providing features have a strong 
> temptation to cut corners and just test that the feature works and not 
> test that everything that isn't supposed to work actually doesn't 
> work. as a result, in many companies there is a deliberate seperation 
> (and tension) between a group focused on controlling and auditing 
> access and one that is focused on creating fucntionality and features.
>
> also from a polical/social point of view everyone recognises that if 
> you grant someone VPN access you are trusting them, but people don't 
> seem to think the same way with ssh.
>
> David Lang
>

I opened port 22 in the firewall to just those hosts that I need to 
reach, which is one in this case...the rest of the machines I cannot reach.
I did a brief port scan and the thing is silent... so I don't think I 
reveal any of the other hosts... but I should not say is it's secure 
with your measures...

Your point two I don't understand...   If you are in charge of the 
firewall you also know what machines you let people reach. If these 
machines are numerous then I think there is a management problem 
somewhere else...


Point 3 is correct but I fail to see how this is less of a problem with 
VPN than SSH.

Thanks and Best regards
Martin

Re: is gitosis secure?

[david]

On Sun, 14 Dec 2008, martin wrote:

> david@lang.hm wrote:
>> On Sun, 14 Dec 2008, martin wrote:
>> 
>>> Dear David.
>>> Why do you trust VPN more than the SSH?
>>> I ask because I have just removed the "first VPN then SSH" solution in 
>>> favor for a SSH only solution using Gitosis just to get rid of the VPN 
>>> which I believe is less secure than SSH (well until I read you comments 
>>> below).
>>> I thought I was doing something right for once but maybe I'm not?
>>> Thanks and best regards
>>> Martin
>> 
>> in part it's that a VPN is a single point of control for all remote access.
>> 
>> If you use ssh you end up exposing all the individual machines
>> 
>> 1. data leakage of just what machines exist to possibly hostile users.
>> 
>> 2. the many machines are configured seperatly, frequently by different 
>> people. this makes it far more likely that sometime some machine will get 
>> misconfigured.
>> 
>> 3. people who are focused on providing features have a strong temptation to 
>> cut corners and just test that the feature works and not test that 
>> everything that isn't supposed to work actually doesn't work. as a result, 
>> in many companies there is a deliberate seperation (and tension) between a 
>> group focused on controlling and auditing access and one that is focused on 
>> creating fucntionality and features.
>> 
>> also from a polical/social point of view everyone recognises that if you 
>> grant someone VPN access you are trusting them, but people don't seem to 
>> think the same way with ssh.
>> 
>> David Lang
>> 
>
> I opened port 22 in the firewall to just those hosts that I need to reach, 
> which is one in this case...the rest of the machines I cannot reach.
> I did a brief port scan and the thing is silent... so I don't think I reveal 
> any of the other hosts... but I should not say is it's secure with your 
> measures...
>
> Your point two I don't understand...   If you are in charge of the firewall 
> you also know what machines you let people reach. If these machines are 
> numerous then I think there is a management problem somewhere else...

two things here

1. if you are running multiple different applications that all want to be 
exposed via port 22 (like git for 'git push') then you may need to expose 
numerous machines. tools that use SSH don't tend to have the ability to 
use a gateway box before they start executing commands, they assume that 
you will SSH directly into the destination box.

2. many people take the attitude that SSH is secure, period, end of 
statement. so they think that every machine should be able to be contacted 
via SSH, and you can then use SSH to do any other functionality on any 
machine that you can dream up. a small minority of people try to minimize 
what boxes are exposed directly (you are one of them), but most don't

David Lang

Re: is gitosis secure?

[Mike Hommey]

On Sun, Dec 14, 2008 at 05:00:14PM -0800, david@lang.hm wrote:
> 1. if you are running multiple different applications that all want to be 
> exposed via port 22 (like git for 'git push') then you may need to expose 
> numerous machines. tools that use SSH don't tend to have the ability to  
> use a gateway box before they start executing commands, they assume that  
> you will SSH directly into the destination box.

But ssh itself allows you to do proxying. See ProxyCommand in
ssh_config's manpage.

Mike

Re: is gitosis secure?

[david]

On Mon, 15 Dec 2008, Mike Hommey wrote:

> On Sun, Dec 14, 2008 at 05:00:14PM -0800, david@lang.hm wrote:
>> 1. if you are running multiple different applications that all want to be
>> exposed via port 22 (like git for 'git push') then you may need to expose
>> numerous machines. tools that use SSH don't tend to have the ability to
>> use a gateway box before they start executing commands, they assume that
>> you will SSH directly into the destination box.
>
> But ssh itself allows you to do proxying. See ProxyCommand in
> ssh_config's manpage.

I was not aware of that option, but it looks like it's designed to be one 
setting for all your ssh communications, so unless you always use the same 
gateway box to get to your destination you would need to tweak your ssh 
config for each different thing that you are doing.

David Lang

Re: is gitosis secure?

[Mike Hommey]

On Mon, Dec 15, 2008 at 12:25:53AM -0800, david@lang.hm wrote:
> On Mon, 15 Dec 2008, Mike Hommey wrote:
>
>> On Sun, Dec 14, 2008 at 05:00:14PM -0800, david@lang.hm wrote:
>>> 1. if you are running multiple different applications that all want to be
>>> exposed via port 22 (like git for 'git push') then you may need to expose
>>> numerous machines. tools that use SSH don't tend to have the ability to
>>> use a gateway box before they start executing commands, they assume that
>>> you will SSH directly into the destination box.
>>
>> But ssh itself allows you to do proxying. See ProxyCommand in
>> ssh_config's manpage.
>
> I was not aware of that option, but it looks like it's designed to be one 
> setting for all your ssh communications, so unless you always use the 
> same gateway box to get to your destination you would need to tweak your 
> ssh config for each different thing that you are doing.

Take a look at Host in the same man page.

Mike

Re: is gitosis secure?

[Tait]

> But ssh itself allows you to do proxying. See ProxyCommand in
> ssh_config's manpage.

I think that's exactly the point David Lang is making.

For the security-paranoid, maybe the approach gitosis should take
is to develop an ssh subserver (like sftp). The possibilities for
restricted access and configuration are greatly expanded by such an
approach. One could configure "sgit" to chroot into some account-specific
subdirectory. The sshd configuration can be tweaked to allow sgit access
but not terminal or exec request (or port forwarding) access, perhaps
dependent on group membership.

Re: is gitosis secure?

[Sitaram Chamarty]

On 2008-12-14, david@lang.hm <david@lang.hm> wrote:
> On Sun, 14 Dec 2008, martin wrote:
>> Why do you trust VPN more than the SSH?
> in part it's that a VPN is a single point of control for all remote 
> access.
>
> If you use ssh you end up exposing all the individual machines

Need not be true.  None of my internal servers aer even
accessible from the outside world; they're all in RFC1918
space and there's only one gateway.  This *is* my single
point of control.

I can setup different port numbers to forward to different
internal servers (ssh, http, whatever I wish); that may
sound like a form of "exposing" but in reality it's a lot
*more* restrictive than setting up a VPN and granting access
to it.

I actually don't like VPNs; they imply that you're "inside"
the network in some way, and I hate blurring that
distinction.  If I'm outside, I want to be acutely aware of
it, and the fact that I can't even ping one of the inside
hosts or see what's on it, or do anything other than what is
specifically allowed by the gateway, is one way of ensuring
this.

Re: is gitosis secure?

[david]

On Sun, 14 Dec 2008, Sitaram Chamarty wrote:

> On 2008-12-14, david@lang.hm <david@lang.hm> wrote:
>> On Sun, 14 Dec 2008, martin wrote:
>>> Why do you trust VPN more than the SSH?
>> in part it's that a VPN is a single point of control for all remote
>> access.
>>
>> If you use ssh you end up exposing all the individual machines
>
> Need not be true.  None of my internal servers aer even
> accessible from the outside world; they're all in RFC1918
> space and there's only one gateway.  This *is* my single
> point of control.
>
> I can setup different port numbers to forward to different
> internal servers (ssh, http, whatever I wish); that may
> sound like a form of "exposing" but in reality it's a lot
> *more* restrictive than setting up a VPN and granting access
> to it.

if you setup multiple inbound redirects for SSH (be they different IP 
addresses or different ports), then you have the exact same situation as 
those machines being accessed directly.

> I actually don't like VPNs; they imply that you're "inside"
> the network in some way, and I hate blurring that
> distinction.  If I'm outside, I want to be acutely aware of
> it, and the fact that I can't even ping one of the inside
> hosts or see what's on it, or do anything other than what is
> specifically allowed by the gateway, is one way of ensuring
> this.

this is the mindset about SSH that I don't like. I see allowing SSH in as 
blurring that distinction.

With a VPN you aren't blurring it, you _are_ letting the person into your 
network. it's not appropriate to do this for everyone, but in the initial 
post the desire was to have trusted company employees working remotely 
push data to the repository. In that scenerio a VPN makes sense. If you 
were doing a distributed opensource project it would probably not make 
sense to allow contributers that you only know via e-mail to VPN into a 
network to do their push (it can be agued that they shouldn't be doing a 
push at all, but that's a workflow discussion ;-)

many people who would never allow a person to VPN into a network seem to 
have no problem with that same person useing SSH to login to a machine on 
that same network (and usually without trying to setup a limited shell). 
In my opinion SSH and VPN access are both in the same category.

In both cases you can limit what the person you are granting access can 
do. with a VPN you would use a firewall to control what they can access 
after connecting to the VPN, with SSH you have to have the server they are 
connecting to configured to limit what they can do.

VPNs tend to have better tools for auditing access and doing strong 
authentication other than certificates (even certificate plus password is 
better than just certificate). cerificates are good and useful, but they 
aren't always enough by themselves.

there have been a number of breeches over the last few years that have 
resulted from one client machine with SSH being comprimized and the 
credentials then used to hop to other machines, gather other credentials 
to then use to comprimize other machines, etc. while I am sure that there 
have also been networks comprimized via VPN, I haven't heard of any 
daisy-chain type attacks involving VPN access.

SSH is a monoculture. there is essentially only one implementation that is 
used (although there are patches to it in some cases), and while it is 
pretty good, any problems with it give you no options. with VPNs there are 
many implementations, if any one has a problem it's possible to replace it 
(painful to change out clients, but possible)


David Lang

Re: is gitosis secure?

[Jakub Narebski]

david@lang.hm writes:

> this is really a reply to an earlier message that I deleted.
> 
> the question was asked 'what would the security people like instead of
> SSH'
> 
> as a security person who doesn't like how ssh is used for everything,
> let me list a couple of concerns.
> 
> ssh is default allow (it lets you run any commands), you can lock it
> down with effort.

How is VPN better than that?
 
> ssh defaults to establishing a tunnel between machines that other
> network traffic can use to bypass your system. yes I know that with
> enough effort and control of both systems you can tunnel over
> anything, the point is that ssh is eager to do this for you (overly
> eager IMHO)

How is VPN better than that?

> ssh depends primarily on certificates that reside on untrusted
> machines. it can be made to work with tokens or such, but it takes a
> fair bit of effort.

There probably VPN differs...

> sshd runs as root on just about every system

And VPN doesn't?

[...]

The idea with using SSH was, I think, that it is easier and better to
use existing solution for authentication and authorization than roll
your own (see the case of CVS pserver, and Subversion svnserve).
-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: is gitosis secure?

[david]

On Sun, 14 Dec 2008, Jakub Narebski wrote:

> david@lang.hm writes:
>
>> this is really a reply to an earlier message that I deleted.
>>
>> the question was asked 'what would the security people like instead of
>> SSH'
>>
>> as a security person who doesn't like how ssh is used for everything,
>> let me list a couple of concerns.
>>
>> ssh is default allow (it lets you run any commands), you can lock it
>> down with effort.
>
> How is VPN better than that?
>
>> ssh defaults to establishing a tunnel between machines that other
>> network traffic can use to bypass your system. yes I know that with
>> enough effort and control of both systems you can tunnel over
>> anything, the point is that ssh is eager to do this for you (overly
>> eager IMHO)
>
> How is VPN better than that?
>
>> ssh depends primarily on certificates that reside on untrusted
>> machines. it can be made to work with tokens or such, but it takes a
>> fair bit of effort.
>
> There probably VPN differs...
>
>> sshd runs as root on just about every system
>
> And VPN doesn't?

you aren't having the VPN software running commands passed to it by the 
outside world.

> [...]
>
> The idea with using SSH was, I think, that it is easier and better to
> use existing solution for authentication and authorization than roll
> your own (see the case of CVS pserver, and Subversion svnserve).

I'm not saying that it's good to roll your own from scratch, you need to 
use libraries that have been examined and validated, but SSH is a swiss 
army knife, it's designed to do lots of things, and when you are exposing 
things to the outside world you want them to be as limited as possible to 
limit the damage that they can do.

David Lang

Re: is gitosis secure?

[Rogan Dawes]

david@lang.hm wrote:

> 
> as a security person who doesn't like how ssh is used for everything,
> let me list a couple of concerns.
> 
> ssh is default allow (it lets you run any commands), you can lock it
> down with effort.
> 
> ssh defaults to establishing a tunnel between machines that other
> network traffic can use to bypass your system. yes I know that with
> enough effort and control of both systems you can tunnel over anything,
> the point is that ssh is eager to do this for you (overly eager IMHO)
> 
> ssh depends primarily on certificates that reside on untrusted machines.
> it can be made to work with tokens or such, but it takes a fair bit of
> effort.
> 
> sshd runs as root on just about every system
> 
> people trust ssh too much. they tend to think that anything is
> acceptable if it's done over ssh (this isn't a technical issue, but it
> is a social issue)
> 
> 
> what would I like to see in an ideal world?
> 
> something that runs as the git user, does not enable tunneling, and only
> does the data transfer functions needed for a push. it should use
> off-the-shelf libraries for certificate authentication and tie into PAM
> for additional authentication.

How about a git-specific deployment/configuration of ssh? You can
certainly run multiple copies of SSH (on different ports), by providing
a restricted configuration file you can disable tunneling and any other
functionality that you don't like.

And if you want it to run as a non-root user, simply choose a port>1024,
but keep in mind that you won't be able to authenticate by password
(IIRC, only key auth will work when running non-root), or setuid to
those users when they log in. Nonetheless, this could be sufficient for
gitosis, since everything runs as the specified user anyway, and IIRC,
gitosis wants individual SSH pubkeys to allow access.

> the authentication would not be any better than with SSH, but the rest
> would be better. I was very pleased to watch the git-daemon development,
> and the emphisis on it running with minimum privilages and provide just
> the functionality that was needed, and appropriately assuming that any
> connection from the outside is hostile until proven otherwise.

In another mail, David wrote:

> 1. if you are running multiple different applications that all want
> to be exposed via port 22 (like git for 'git push') then you may need
> to expose numerous machines. tools that use SSH don't tend to have the
> ability to use a gateway box before they start executing commands,
> they assume that you will SSH directly into the destination box.

In many cases, especially if the tool is unix based, you can specify (in
~/.ssh/config) a Proxy command that is executed before the SSH protocol
negotiation begins, which results in stdin and stdout being connected to
the SSH daemon at the destination. The most common variations are the
HTTP and Socks proxy connectors (e.g. corkscrew?), but the sky is really
the limit in terms of what is possible.

Rogan

Re: is gitosis secure?

[david]

On Mon, 15 Dec 2008, Rogan Dawes wrote:

> david@lang.hm wrote:
>
>>
>> as a security person who doesn't like how ssh is used for everything,
>> let me list a couple of concerns.
>>
>> ssh is default allow (it lets you run any commands), you can lock it
>> down with effort.
>>
>> ssh defaults to establishing a tunnel between machines that other
>> network traffic can use to bypass your system. yes I know that with
>> enough effort and control of both systems you can tunnel over anything,
>> the point is that ssh is eager to do this for you (overly eager IMHO)
>>
>> ssh depends primarily on certificates that reside on untrusted machines.
>> it can be made to work with tokens or such, but it takes a fair bit of
>> effort.
>>
>> sshd runs as root on just about every system
>>
>> people trust ssh too much. they tend to think that anything is
>> acceptable if it's done over ssh (this isn't a technical issue, but it
>> is a social issue)
>>
>>
>> what would I like to see in an ideal world?
>>
>> something that runs as the git user, does not enable tunneling, and only
>> does the data transfer functions needed for a push. it should use
>> off-the-shelf libraries for certificate authentication and tie into PAM
>> for additional authentication.
>
> How about a git-specific deployment/configuration of ssh? You can
> certainly run multiple copies of SSH (on different ports), by providing
> a restricted configuration file you can disable tunneling and any other
> functionality that you don't like.
>
> And if you want it to run as a non-root user, simply choose a port>1024,
> but keep in mind that you won't be able to authenticate by password
> (IIRC, only key auth will work when running non-root), or setuid to
> those users when they log in. Nonetheless, this could be sufficient for
> gitosis, since everything runs as the specified user anyway, and IIRC,
> gitosis wants individual SSH pubkeys to allow access.

IMHO this is better then exposing a 'normal' ssh daemon to the Internet 
just to be able to do a git push. the fact that you loose authentication 
options is not a good thing, are you sure that you cannot hook into PAM 
authentication for this?

>> the authentication would not be any better than with SSH, but the rest
>> would be better. I was very pleased to watch the git-daemon development,
>> and the emphisis on it running with minimum privilages and provide just
>> the functionality that was needed, and appropriately assuming that any
>> connection from the outside is hostile until proven otherwise.
>
> In another mail, David wrote:
>
>> 1. if you are running multiple different applications that all want
>> to be exposed via port 22 (like git for 'git push') then you may need
>> to expose numerous machines. tools that use SSH don't tend to have the
>> ability to use a gateway box before they start executing commands,
>> they assume that you will SSH directly into the destination box.
>
> In many cases, especially if the tool is unix based, you can specify (in
> ~/.ssh/config) a Proxy command that is executed before the SSH protocol
> negotiation begins, which results in stdin and stdout being connected to
> the SSH daemon at the destination. The most common variations are the
> HTTP and Socks proxy connectors (e.g. corkscrew?), but the sky is really
> the limit in terms of what is possible.

as I just commented, this looks like it's a per-user config option that is 
designed to be used as a proxy out of the network you are in to get to the 
Internet, not to be used at the far side of a connection to get to things 
on a remote network. as I understand it, you would need to change this 
config file for each different destination network you need to connect to.

David Lang

Re: is gitosis secure?

[Rogan Dawes]

david@lang.hm wrote:
> On Mon, 15 Dec 2008, Rogan Dawes wrote:
> 
>> david@lang.hm wrote:
>>
>>>
>>> what would I like to see in an ideal world?
>>>
>>> something that runs as the git user, does not enable tunneling, and only
>>> does the data transfer functions needed for a push. it should use
>>> off-the-shelf libraries for certificate authentication and tie into PAM
>>> for additional authentication.
>>
>> How about a git-specific deployment/configuration of ssh? You can
>> certainly run multiple copies of SSH (on different ports), by providing
>> a restricted configuration file you can disable tunneling and any other
>> functionality that you don't like.
>>
>> And if you want it to run as a non-root user, simply choose a port>1024,
>> but keep in mind that you won't be able to authenticate by password
>> (IIRC, only key auth will work when running non-root), or setuid to
>> those users when they log in. Nonetheless, this could be sufficient for
>> gitosis, since everything runs as the specified user anyway, and IIRC,
>> gitosis wants individual SSH pubkeys to allow access.
> 
> IMHO this is better then exposing a 'normal' ssh daemon to the Internet
> just to be able to do a git push. the fact that you loose authentication
> options is not a good thing, are you sure that you cannot hook into PAM
> authentication for this?

I *think* that an unprivileged user cannot invoke PAM for accounts other
than its own, and most certainly cannot change to that other user
without being setuid (or having the appropriate capability).


>> In many cases, especially if the tool is unix based, you can specify (in
>> ~/.ssh/config) a Proxy command that is executed before the SSH protocol
>> negotiation begins, which results in stdin and stdout being connected to
>> the SSH daemon at the destination. The most common variations are the
>> HTTP and Socks proxy connectors (e.g. corkscrew?), but the sky is really
>> the limit in terms of what is possible.
> 
> as I just commented, this looks like it's a per-user config option that
> is designed to be used as a proxy out of the network you are in to get
> to the Internet, not to be used at the far side of a connection to get
> to things on a remote network. as I understand it, you would need to
> change this config file for each different destination network you need
> to connect to.

That may be its original intention, but it can nonetheless be used for
other purposes. Yes, you might need a different configuration for each
network that you need to access, and quite possibly for each location
that you need to access them from. This may result in config entry
proliferation, but it is manageable, especially with the openssh
wildcard syntax in the config file.

man ssh_config:

Host
Restricts the following declarations (up to the next Host keyword) to be
only for those hosts that match one of the patterns given after the
keyword.  If more than one pattern is provided, they should be separated
by whitespace.  A single `*' as a pattern can be used to provide global
defaults for all hosts.  The host is the hostname argument given on the
command line (i.e. the name is not converted to a canonicalized host
name before matching).

e.g

Host *-home
   ProxyCommand . . . .

FWIW.

Rogan

Re: is gitosis secure?

[Jakub Narebski]

Sitaram Chamarty <sitaramc@gmail.com> writes:
> On 2008-12-13, Nix <nix@esperi.org.uk> wrote:

> > telnet. I do not jest, this is our sysadmins' stated reasons for not
> > opening the git port and for tweaking their (mandatory) HTTP proxy to
> > block HTTP traffic from git.
> 
> Wow -- my sympathies!
> 
> But on occasion, when real or imaginary issues prevented me
> from making a live connection, I have used "git bundle" to
> do the job.  Not as satisfactory as a real connection, but
> when you have a proper, non-fast-forwarding, repo as the
> "mother ship", git bundle with some custom procmail scripts
> on both sides can work OK enough.

Perhaps one would be interested in adding bundle support to gitweb.
The problem is in the interface, but I think in simplest case gitweb
could present 'bundle' link along snapshot link(s) in the 'heads' view
(showing branches), which link would generate bundle for a given
branch, starting from latest annotated tag.  But this is only for
download...
 
Another solution would be to help with "smart" HTTP protocol,
i.e. git-over-http solution.  This would hopefully change signature so
at least for some time it would pas proxy filters.  Also only for
download.


BTW. is outgoing SSH transport (from network to outside) blocked as
well?
-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: is gitosis secure?

[Nix]

On 14 Dec 2008, Jakub Narebski spake thusly:
> BTW. is outgoing SSH transport (from network to outside) blocked as
> well?

*No* ports are open. All they have is a (non-transparent) buggy HTTP
proxy. These guys really don't get the Internet, despite their sales
literature banging on endlessly about it.

Looks like a lot of git-bundling is in my future.

Re: is gitosis secure?

[david]

On Mon, 15 Dec 2008, Nix wrote:

> On 14 Dec 2008, Jakub Narebski spake thusly:
>> BTW. is outgoing SSH transport (from network to outside) blocked as
>> well?
>
> *No* ports are open. All they have is a (non-transparent) buggy HTTP
> proxy. These guys really don't get the Internet, despite their sales
> literature banging on endlessly about it.
>
> Looks like a lot of git-bundling is in my future.

no ports being open and a non-transparent HTTP proxy doesn't tell me that 
they don't get the Internet. They could get the Internet just fine and be 
suitably paranoid about it. Controlling outbound traffic is actually a 
good thing in the current era of botnets (it prevents any of the machines 
in that company from participating in a botnet if they can't reach the 
command system)

the fact that the proxy is buggy could be an issue (I'm curious about what 
types of bugs you are running into, what you see as a bug may not be)



if there is a business reason for the developers on that network to be 
accessing resources on the Internet there should be a way to request that 
the appropriate ports get opened. if the answer from the security folks is 
'no' you should ask them why not and what could be done to get the job 
done.

it may be that they don't want to provide access out from a bunch of 
desktops. If that is the case it may be appropriate to build a box to put 
into the DMZ that pulls from the upstream and then the inside desktops 
pull from this gateway system.


the saying goes "don't attribute to malice what can be explained by 
incompetence", but along the same lines in the security field, don't 
attribute to incompetence what can be explained by people doing their jobs 
that are ignorant of the requirements. they may also be operating under 
constraints that you don't know about.

David Lang

Re: is gitosis secure?

[Asheesh Laroia]

On Mon, 15 Dec 2008, Nix wrote:

> On 14 Dec 2008, Jakub Narebski spake thusly:
>> BTW. is outgoing SSH transport (from network to outside) blocked as 
>> well?
>
> *No* ports are open. All they have is a (non-transparent) buggy HTTP 
> proxy. These guys really don't get the Internet, despite their sales 
> literature banging on endlessly about it.

If that's the only way you can access the network, you can take advantage 
of the way HTTP proxies deal with HTTPS: they typically let it through 
byte for byte.

"connect.c is the simple relaying command to make network connection via 
SOCKS and https proxy. It is mainly intended to be used as proxy command 
of OpenSSH."

Run sshd on port 443, use connect.c, and you're set.

(Except for some really smart SSL-aware HTTP proxies that verify that it's 
an SSL connection of some kind.  In theory, you could then sslwrap your 
sshd and then be set.)

-- Asheesh.

-- 
Q:	Why did the astrophysicist order three hamburgers?
A:	Because he was hungry.

Re: is gitosis secure?

[david]

On Sun, 14 Dec 2008, Asheesh Laroia wrote:

> On Mon, 15 Dec 2008, Nix wrote:
>
>> On 14 Dec 2008, Jakub Narebski spake thusly:
>>> BTW. is outgoing SSH transport (from network to outside) blocked as well?
>> 
>> *No* ports are open. All they have is a (non-transparent) buggy HTTP proxy. 
>> These guys really don't get the Internet, despite their sales literature 
>> banging on endlessly about it.
>
> If that's the only way you can access the network, you can take advantage of 
> the way HTTP proxies deal with HTTPS: they typically let it through byte for 
> byte.
>
> "connect.c is the simple relaying command to make network connection via 
> SOCKS and https proxy. It is mainly intended to be used as proxy command of 
> OpenSSH."
>
> Run sshd on port 443, use connect.c, and you're set.
>
> (Except for some really smart SSL-aware HTTP proxies that verify that it's an 
> SSL connection of some kind.  In theory, you could then sslwrap your sshd and 
> then be set.)

although, if the company is doing this as a deliberate security measure 
(as opposed to not knowing what they are doing), setting up a bypass like 
this can get you fired for deliberatly bypassing a security device.

also, examples of people going to this sort of effort to bypass security 
policies end up with employees being trusted less.

you are far better off going through channels and discussing what you are 
trying to do and why.

David Lang

Re: is gitosis secure?

[Garry Dolley]

On Tue, Dec 09, 2008 at 09:56:48AM +0100, Thomas Koch wrote:
> Sorry for the shameless subject, but I presented gitosis yesterday to
> our sysadmin and he wasn't much delighted to learn, that write access to
> repositories hosted with gitosis would need SSH access.
> 
> So could you help me out in this discussion, whether to use or not to
> use gitosis? 
> Our admin would prefer to not open SSH at all outside our LAN, but
> developers would need to have write access also outside the office.

If your admin doesn't want to open SSH to the outside, then the
people who need it would need to VPN into your LAN first.  That's
how I do it on networks that don't allow any traffic from the
outside.

But like someone else ask, what alternative *would* your admin
prefer?  I'd rather use SSH than a yet-to-be-proven-secure
alternative app.

-- 
Garry Dolley
ARP Networks, Inc.                          http://www.arpnetworks.com
Data center, VPS, and IP transit solutions  (818) 206-0181
Member Los Angeles County REACT, Unit 336   WQGK336
Blog                                        http://scie.nti.st