Re: [Savannah-hackers-public] [sr #107077] Setting up bzr+ssh on Savannah.

[Sylvain Beucler]

Hi,

I won't be at Libre Planet, so discussion will probably remain on this
list.

- My main critic is that you're designing a system from scratch, but
the goal is to integrate it well at Savannah.

- Most of your setup sounds good, and it's pretty to close to what's
currently installed (consider that bzr+ssh had been running in the
past, before we switched to SFTP).  I suggest you take a look at
sftp://bzr.sv.gnu.org:/ , browse around and explain what needs to be
changed.  I can also provide root access which would be easier: who's
gonna maintain the changes?

- I don't understand the roal of a 'bzrusers' group.

- Shell restriction is better done with a restricted shell, rather
than using 'command='.  Check /usr/local/bin/sv_membersh.

- Plugins:

The basic security principles at Savannah are:

* sysadmins determine what commands the user can run (so they have no
  chance of running a custom exploit)

* security still needs to be solid if the user gets local access

* we consider 4 levels of access:
  1. restricted shell
  2. restricted shell + filesystem-level access
  3. local access
  4. root

  No escalation should happen.

  CVS typically fails, because filesystem-level (2.) access gives you
  access to commit hooks, so you can run arbitrary commands, i.e.
  local access (3.).  Same for SVN.  In addition, in CVS, (2.)  gives
  you the right to mess with pserver users (if pserver runs as root),
  which gives you (3.) - and even (4.) until recently.  Hence CVS and
  SVN don't get filesystem-level access: no SFTP.

  Likewise, Git could work with sftp or rsync, but in that case we
  would disable git-shell (SSH) access so that people couldn't run
  hooks that they installed with SFTP.  Instead, Git users gets no
  filesystem-level access, which means the hooks directory is under
  sysadmin control.

Bzr is typically a candidate to move to "no-SFTP" depending on what it
does with plugins.  You recently explained that only system-wide
(/usr/lib/.../plugins) plugins should be able to run; however there's
still a grey area about: a) ~jrandom/.bazaar/plugins and b) user
plugins configuration.  Can you detail what these permits, in
particular in the light of the access levels I described?


- commit mail notifications: can you detail what options we have to
run commit mail notifications?  Typically CVS/SVN/Git/Hg use commit
hooks, bzr currently uses 1 cronjob per branch which I'm not sure
would scale (but I might be wrong).  Do you see alternatives?

-- 
Sylvain

On Tue, Mar 16, 2010 at 01:01:03PM -0400, Karl Fogel wrote:
> >> 1) Reopen SR #107077 (it's currently marked "closed", yet has much
> >>    recent discussion and planning).
> 
> Done now.
>  
> >> 2) With bzr developer Robert Collins, write up a plan for exactly how
> >>    to provide Bazaar bzr+ssh:// access securely on Savannah.  This
> >>    will involve taking various steps mentioned in SR #107077.  Start
> >>    at https://savannah.gnu.org/support/?107077#comment20 and read
> >>    upwards if you're curious.
> 
> Okay, below is an implementation plan.  Robert Collins has helped with
> advice on this; I'm CC'ing him here in case I mess anything up.
> 
> I'm assuming we already have an id_rsa.pub or id_dsa.pub from every
> potential committer, or that we can easily get committers' public keys
> by having them submit it through the Savannah web interface.
> 
> On bzr.sv.gnu.org:
> 
>   1. Create a new group 'bzrusers'.
>   
>   2. Do 'chgrp -R bzrusers /srv/bzr && chmod -R g+w /srv/bzr'
>   
>      (/srv/bzr is the top of our Bazaar "shared repository", right?)
>   
>   3. For each committer Jennifer Random, create a Unix account 'jrandom'
>      and put her in the group 'bzrusers'.  Her shell should be /bin/sh
>      (not /bin/false), but the account should have no login password --
>      i.e., use "*" in the encrypted password field in /etc/shadow or
>      whatever.  All authentication will be done via SSH, and we will
>      allow only a restricted command set there (see below).
>   
>   4. In ~jrandom/.ssh/authorized_keys, put this line:
>   
>      command="/usr/bin/bzr serve --inet --allow-writes --directory=/src/bzr" 
> ssh-rsa <<<LONG BASE64 PUBLIC KEY>>> address@hidden
>   
>      NOTE: everything from "ssh-rsa ..." on is either from id_rsa.pub as
>      supplied by jrandom, or is a dedicated-use public key supplied by
>      jrandom.  In the latter case, jrandom would have something like
>      this in .ssh/config on the client side:
>   
>      Host bzr.sv.gnu.org
>         IdentityFile ~/.ssh/savannah_id_rsa
>   
>   5. (paranoia) Do 'chmod 600 ~jrandom/.ssh ~jrandom/.ssh/authorized_keys'
>   
>   6. (paranoia) Make sure that /usr/lib/python2.*/bzrlib/plugins/ is not
>      writeable by jrandom -- though it shouldn't matter, since SSH
>      access is restricted to bzr only and bzr is restricted to the
>      /bzr/srv directory (via the "--directory" option).
>   
>   7. (paranoia) Make sure ~jrandom/.bazaar/plugins does not exist or is
>      not writeable by jrandom.  
>   
>      NOTE: We may someday put real plugins in there, or make it a
>      symlink to a shared plugin directory controlled by the sysadmins.
>      But in any case jrandom should not be able to configure it.
>   
> On the client side:
> 
>   Commands like these should now work, assuming /bzr/srv/projectname
>   exists and has a 'trunk' branch (e.g., projectname is "emacs"):
> 
>   $ bzr branch bzr+ssh://address@hidden/projectname/trunk
>   $ cd trunk
>   $ echo "Hello, world!" > foo
>   $ bzr add foo
>   $ bzr commit -m "Add file 'foo'."
>   $ bzr push --remember bzr+ssh://address@hidden/projectname/trunk
>   Pushed up to revision <<<N>>>.
>   $ 
> 
>   NOTES:
> 
>   If the remote branches were not created with the --no-trees option, or
>   'bzr remove-tree' has not been run on them, then the client will get a
>   warning like this:
> 
>     This transport does not update the working tree of:
>     bzr+ssh://address@hidden/projectname/trunk/. See 'bzr help
>     working-trees' for more information.
> 
>   I assume we configure all our branches on the server to not have
>   working trees, so this won't be an issue.
> 
>   Also, note that even if jrandom has Unix password-based access on the
>   remote server, it will not work with this Bazaar configuration...
> 
>   address@hidden's password: *********
>   bzr: ERROR: Not a branch: "bzr+ssh://address@hidden/testproj/".
> 
>   ...because the key Bazaar line is in ~jrandom/.ssh/authorized_keys, so
>   authentication must happen via SSH private/public key.
> 
> That's the plan.  It may need to be tweaked, depending on the situation
> on bzr.sv.gnu.org, but I think the rough outline is about right.
> Comments welcome.  Both Robert and I will be at the GNU hacker meetup in
> Boston; we're happy to help make this happen then, if not sooner.
> 
> -Karl

signature.asc
Description: Digital signature