RE: Security setup

[Walter, Jan]

Larry Jones writes:
> Mike Ayers writes:
> > 
> >     Here's a bit of a challenge for the list.  We need to 
> set up a CVS
> > repository on a Linux server such that the users can't modify the 
> > files, except through proper CVS operations.  The catch?  They are 
> > currently permitted to log into the server.  Is there a way to seal 
> > off the repository without banning them from logging in?  
> It has not 
> > been said that there is no option to prevent login, but if 
> I can avoid 
> > that option, it would be preferrable.  Suggestions?
> 
> Rewrite CVS?  Seriously, as I've said many times before, CVS 
> was designed to facilitate cooperative work, it was *not* 
> designed to enforce security in any way, shape, or form.  Any 
> attempt to make it do so is doomed to fail.

I think we need to differentiate between "really bullet-proof security" and
"reasonable security" - after all, security is also there to protect users
from themselves, with no malicious intent required. I would also fathom that
this is the cause of most data loss.

For Mike I'll detail the environment here - semi-secure, not ill-will proof
by any means, but enough to prevent someone from accidentally doing a lot of
harm to the repository.

The cvsroots live in /home/cvs, owned by user cvs, and group cvs. This
directory is only readable by that account.

Pserver runs with the cvs user permissions, and each user (whether or not
they have a local shell account or not) has a user ID and password for the
repository in the CVSROOT/passwd. The format "userid:password:cvs" in the
passwd file, meaning the pserver will not su to the user's id that has
logged in, and thus has permissions to the directories and stuff. The
password file is not part of the repository (i.e. No ,v file) and so cannot
get checked out and broken.

The cvsroots are backed up twice a day to a tar file, and the one in the
evening gets pushed over to the server with the tape drive for a backup.

Bullet-proof? No. Works? Yes. Would I put this setup on the Internet?
Absolutely not.

- Users cannot fiddle with the ,v files in the repository withouth su'ing to
cvs (if they have the password) or root.
- Local or remote cvs access possible
- Password changes are a pain in the #$%
- pserver runs though xinetd, and connections are logged the usual way

Now, you could tighten this up a great deal, like block access to the
pserver from all but localhost (since it's safe to assume that anyone with
shell access is trusted to some extent) and limit your exposure, or require
stuff like ssh certificates and all that for external connections.

Cheers,

Jan