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

[Robert Collins]

On Wed, 2010-03-17 at 00:13 +0100, Sylvain Beucler wrote:

> > > - 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.
> 
> Well please clarify.

unix groups can be used to provide acls on repositories, so its to do
with access control, not with whether sftp or bzr+ssh is used as the
protocol.

> > > - 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.
> 
> I find it easier to reason about security when the most common access
> is secured: the non-user-modifiable shell.
> 
> Be sure to check the sv_membersh I mentioned so we talk about the same
> "restricted shell" concept (i.e. similar to rssh).

Sure. Sounds like a similar thing, though as I understand rssh it
doesn't force a command, rather it permits auditing the commands
permitted; rather a different behaviour.

> ess 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.
> 
> I don't know what "plugins" can or can't do.  Can the user run
> arbitrary commands through bzr+ssh if he has access to that directory?

plugins are arbitrary python code. They are loaded from two places: the
system python package 'bzrlib.plugins' and from the users home dir in
'~/.bazaar/plugins'. A plugin could do anything:
 - add a new smart server verb
 - attempt a local code exploit
 - write to any file the user can write to

The path that plugins are loaded from is controlled by an environment
variable, so its important that the commandline of the bzr process on
the server is strictly controlled - injecting an arbitrary environment
variable would allow loading a plugin from a non-default location.

> > We should make the directory, chown it to root:root and
> > set it to 0755
> 
> Users can bypass this with 'mv'.
> We would need to also 'chattr +i' but this technique is inconvenient.

The wouldn't be able to issue a mv with bzr as the directory is outside
the writable-path we're setting. I agree that if you gave them shell or
SFTP access they could do that. We are proposing to remove SFTP and not
give them shell access.

> > > - 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.
> 
> (I'm not at Libre Planet)
> 
> I don't have a preferred approach, you tell me how these things scale.
> For example inotify will probably hit a #descriptors limit, and
> introduce startup delays when there are many files to minitor which
> means it may miss changes.
> 
> bzr-email may be interesting depending on how plugins are generally
> run.  However if you keep SFTP access too, this might not be the safer
> approach.

I don't see any need to keep SFTP access.

> > > >   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.
> 
> That's part of why I prefer the restricted shell approach.
> 
> Controlling homedir permissions is not something natural under Unix.
> Hopefully there's a better way to just make sure bzr+ssh won't run
> hooks except ones validated by sysadmins.

I'll need to check, but manually setting the plugins path may be enough;
it depends on whether we auto-add the homedir location or not.

> > > >   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.
> 
> You're talking about combined SFTP&bzr+ssh access (unless I'm
> mistaken), so let's assume users have write access to their homedir.

SFTP access is very slow, there is no point having it when bzr+ssh is
available. If it makes it easier to do bzr+ssh in a way that you are
happy with, then we should remove SFTP. And it seems like it does to me
so far.

-Rob

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