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
