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

[Sylvain Beucler]

Hi,

(adding Jelmer in Cc: as he offered to provide advice on bzr setup)
Jelmer: hi, the start of the thread is here, but you probably have
enough info below:
http://lists.gnu.org/archive/html/savannah-hackers-public/2010-03/msg00019.html

On Wed, Mar 17, 2010 at 07:55:54AM +1100, Robert Collins wrote:
> 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.

The proposal is re-implementing a few things that are already there.
I got the feeling that you don't understand how it's currently run,
which makes sense since you don't have access, hence my suggestions
quoted below.


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


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


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

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?


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


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


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


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

-- 
Sylvain

signature.asc
Description: Digital signature