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

[Robert Collins]

On Tue, 2010-03-16 at 20:18 +0100, Sylvain Beucler wrote:
> 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.

This isn't from scratch - its adapting what we suggest bzr users do to
Savannah's security environment.

> - 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.

Neither do I, I think its orthogonal to the bzr+ssh discussion.

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

I think Karl wants to replace the command that is executed, not permit
only a subset of commands to be executed. That makes some sense to me
too, because it makes easier to reason about security.

> - 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?

We need to ensure that jrandom cannot write to ~jrandom/.bazaar/plugins.
There is nothing grey about it: If they can write to that directory they
can install plugins. If they cannot write there, then they cannot
install plugins. We should make the directory, chown it to root:root and
set it to 0755

> - 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?

There are two major alternatives:
 - an inotify based system that is very similar to the cron job approach
 - bzr-email, which can run server side (but we'll want to give it an
audit to make sure users won't be able to inject a command to run
remotely). I propose to do this during Libre Planet if bzr-email is your
preferred approach. bzr-email would run on push, so have no server load
except when a user has actually pushed something to a branch.

> >   5. (paranoia) Do 'chmod 600 ~jrandom/.ssh ~jrandom/.ssh/authorized_keys'

This isn't paranoia, and its not enough - you need
chmod 0400 ~jrandom/.ssh/authorized_keys, or else they could make a
symlink to that path, and 'append' content to the symlink to write a
new, unrestricted key.

> >   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.

Again, while bzr won't be letting them make/delete/rename files outside
of /srv/bzr, a symlink into that directory + appending to it may well
let one write a new file. Its not paranoia to enforce the things one
needs to meet the security policy.

Cheers,
Rob

signature.asc
Description: This is a digitally signed message part