git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rogan Dawes <lists@dawes.za.net>
To: david@lang.hm
Cc: Sitaram Chamarty <sitaramc@gmail.com>, git@vger.kernel.org
Subject: Re: is gitosis secure?
Date: Mon, 15 Dec 2008 09:20:17 +0200	[thread overview]
Message-ID: <49460531.8010808@dawes.za.net> (raw)
In-Reply-To: <alpine.DEB.1.10.0812132126470.17688@asgard.lang.hm>

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

  parent reply	other threads:[~2008-12-15  7:23 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-09  8:56 is gitosis secure? Thomas Koch
2008-12-09  9:04 ` Sam Vilain
2009-01-18 11:48   ` Florian Weimer
2009-01-18 12:50     ` Boyd Stephen Smith Jr.
2009-01-18 13:25       ` Florian Weimer
2009-01-18 14:19         ` Boyd Stephen Smith Jr.
2009-02-03 21:31       ` Tommi Virtanen
2009-02-04 12:12         ` Stephen R. van den Berg
2009-02-04 18:26           ` Tommi Virtanen
2009-02-05  7:52             ` Stephen R. van den Berg
2009-02-05  8:04               ` Tommi Virtanen
2008-12-09  9:07 ` R. Tyler Ballance
2009-02-03 21:41   ` Tommi Virtanen
2008-12-09  9:38 ` Sverre Rabbelier
2008-12-13 16:23   ` Nix
2008-12-13 18:07     ` Sverre Rabbelier
2008-12-14  2:26     ` Sitaram Chamarty
2008-12-14  5:40       ` david
2008-12-14  9:42         ` martin
2008-12-14 11:25           ` david
2008-12-14 10:51             ` Jakub Narebski
2008-12-15  0:54               ` david
2008-12-14 11:02             ` martin
2008-12-15  1:00               ` david
2008-12-15  7:17                 ` Mike Hommey
2008-12-15  8:25                   ` david
2008-12-15  8:35                     ` Mike Hommey
2008-12-15 21:28                   ` Tait
2008-12-14 11:42             ` Sitaram Chamarty
2008-12-15  1:20               ` david
2008-12-14 10:40         ` Jakub Narebski
2008-12-15  0:50           ` david
2008-12-15  7:20         ` Rogan Dawes [this message]
2008-12-15  8:37           ` david
2008-12-15  7:52             ` Rogan Dawes
2008-12-14 10:47       ` Jakub Narebski
2008-12-15  0:14         ` Nix
2008-12-15  1:29           ` david
2008-12-15  5:24           ` Asheesh Laroia
2008-12-15  6:32             ` david
2008-12-09 19:18 ` Garry Dolley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=49460531.8010808@dawes.za.net \
    --to=lists@dawes.za.net \
    --cc=david@lang.hm \
    --cc=git@vger.kernel.org \
    --cc=sitaramc@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).