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
