Re: what's to stop a developer from nuking the repository?

[xyzzy]

Mark,

Thanks for your cogent and lucid explanation.  You cleared up a lot for me.

Please see in-line comments and questions.

On Sunday 29 February 2004 5:59 pm, Mark D. Baushke wrote:
> address@hidden writes:
> > The problem is that the cvs directory is on the same machine as all
> > the other server stuff including user's server home directories.
>
> What you describe is a non-optimal setup. Do try to use a dedicated
> machine which does not allow general purpose logins to it.
>
>    If possible,
>
>      - Use a dedicated machine for your cvs server.
>      - Allow access via ssh only.
>      - Provide only stub home directories with a .ssh/authorized_keys
>        file that gives them their public key and restrists the command
>        they are able to run to the pathname to the 'cvs' command only.
>
> If a special-purpose machine with a minimal environment for users is not
> possible, then you may need to take a bit more care about how cvs is
> being used.

Unfortunately, the reality of my environment is such that I must have 
everything on one machine.  I do not control the server farm.

>
> I have known others to make the cvs executable be set-gid to a 'cvs'
> group and for all directories to be owned by a user 'cvs' and group
> 'cvs' and have 'u=rwx,g=rwxs,o=' (2770) permissions for all directories.
> This does not get around the problem that files committed or new
> directories added will be owned by the user who made the change, so
> those files and directories may need a periodic cron job to change
> ownership in the tree of directories and ,v files. However, it may be
> mitigated somewhat by the user not being able to 'see' the files under
> the repository hierarchy as they are not in the group 'cvs' which only
> cvs is able to see. The downside is that you need to be very careful
> with taint checks for the verifymsg/commitinfo/loginfo/taginfo scripts.

So, what you are saying here is that if the cvs executable is set-gid to a 
group that do NOT have the users in it, those users can still commit, 
checkout, etc, but will not be able to see the directory hierarchy aside from 
the cvs root?

I don't understand what you mean by 'taint checks' and how they apply here.  
Do you have any sort of URL reference so I can RTFM?

>
> > Thus, a user can access the server via a simple 'ssh', then do 'cd
> > /cvs' and have free rein due to the permissions set below.
> >
> > 1. How do you enforce a restricted shell with a chroot prison?  A hacked
> > version of ssh?
>
> While possible, I don't think a chroot prison is necessary and a
> standard version of ssh should work. However, if others are already
> using this method, perhaps they can be more forthcoming in its
> description...
>
> > 2. How do I muck with the permissions so that developers can't even
> > read, much less write to the cvs directory, but not damage regular cvs
> > access?
>
> As the user will likely 'own' any files that have just been operated on
> via a commit or tag operation, unless you have some sort of hack that
> changes the ownership of files as a part of the log_accum step, it seems
> unlikely that this will do you much good at all. However, if the
> top-level directories that own your repository are only able to be
> penetrated by a cvs executable due to its set-gid nature, that may give
> you some minor protection (I still believe a dedicated machine is a
> better solution).
>
> > That is, the system-wide passwd file has a user named "cvsaccess"
> > ("not his real name" :-)
>
> Are you talking about an :ext: user or a :pserver: user?

:pserver: definitely.

>
> > Then, /etc/group has a group named 'cvs' with cvsaccess as well as all
> > other users that need access to CVS attached to that group.
> >
> > 'cvsaccess' is also listed in the CVSROOT/writers file.
>
> The writers files is intended to be a :pserver: feature... let me be
> clear, I know that many people use :pserver:.
>
> Note: I do not consider the :pserver: feature to be useful for anything
> other than anonymous read-only access to a mirror of the master
> repository. It was and is a fairly insecure hack that I would rather see
> removed from cvs. So, I am probably the wrong person to ask about how to
> use it to allow writers...
>
> > All objects in the /cvs directory are owned by cvsaccess/cvs with all
> > files having 444 permissions, the directories having 775 permissions. 
> > This is a mess.  Since the same user that accesses the main server via
> > ssh has write permissions due to membership in the 'cvs' group, this
> > allows nuking of the repository files.  How do I fix this?
>
> One way is to ensure that the users are only given access to the 'cvs'
> command via SSH on login.

This I can't do since the machine is intended to be wide open (relatively) to 
all users.  It's an internal server with home directories, etc...

>
> > Also, would it help if I enforced a provision that all users access cvs
> > using :ext: only via ssh?  How would this work with WinCVS users?
>
> Yes. If only ssh access may be granted to the machine, it is possible to
> use the command= feature of the OpenSSH .ssh/authorized_keys file to
> restrict the command the user is able to run to that of 'cvs server'
> which is desirable to limit the ways in which the user may fiddle with
> files in the repository.

Again, see above.  I can't restrict the user to what commands he/she may run.

I was thinking about a different set of users, thus giving each human two ids, 
one for general server access and the other strictly for CVS over ssh.  We 
are a small operation so the id duplication is not that big of a deal, except 
for getting everyone to update themselves (generating new keys, making a new 
user on each local machine with the required home and .ssh directories).  
THEN, I can limit this other user, and play with permissions to restrict as 
needed.  Is this a viable plan?  Is anybody else doing something like this?

This seems to be a bit of a design limitation for CVS, no?

>
> Both cvs.exe and TortoiseCVS users on windows boxes seem to have been
> able to use PuTTY and Pageant (PuTTY's ssh agent) to access cvs servers
> using :ext: over the SSHv2 protocol.
>
>       Enjoy!
>       -- Mark