[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Security options :-(

From: Keith Refson
Subject: Security options :-(
Date: Tue, 17 Dec 2002 19:31:39 +0000

Phil R Lawrence 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.
 > > 
 > > The cvs user id and group id need to be different from all
 >  > other login users. And set permissions for repository such
 >  > that the cvs user and group only are given write
 >  > permissions. This should suffice
 > And then what?  Use pserver to map the existing user ids to the cvs id?
 > I have been trying to figure out a secure way to set this thing up, but 
 > each way seems to have big drawbacks.
 > Method 1
 >    description:
 >    - users SSH into existing accounts.
 >    - repository has group permissions that allow users to
 >      check in and out, etc.
 >    drawback:
 >    - users can modify the history files, because they are
 >      located in the same dir as source files.  Audit function
 >      is thus compromised.
 > Method 2
 >     description:
 >     - pserver via SSH
 >     drawback:
 >     - "any CVSpserver user can trivially spoof any other
 >       at several levels." --Greg A. Woods
 >       Thus audit function is again compromised.

I recently set up a remote access repository using a third method,
which may help:

Method 3: 
   - users SSH into a single existing account.
   - Account is set up using a restricted shell (actually restricted
     bash) allowing use of the command "cvs" only.
   - Authorization is using ssh2 public key authorization.  To permit
     a user he sends me his public key which I add to the
     ".ssh/authorized_keys" file.
   - Authorization files, root directory etc are NOT owned by the user
     so they can't be modified.
   - repository has group permissions that allow users to
     check in and out, etc. as required.

   - I can manage a  number of users easily, allowing or withdrawing
     access at any time. No account creation necessary.
   - Users can't do anything the CVS command won't allow them to, and
     do NOT have login access.

   - All checkins appear to be from the same  CVS account, rendering
     CVS user checkin audit useless.
   - CVS account Login directory, .ssh dir and other files must be
     owned by root (otherwise ssh won't allow access). Permissions
     management for the files must be carefullly setup if CVS account
     access is to be administered by a non-root user.

Dr Keith Refson, 
Building R3
Rutherford Appleton Laboratory
Oxfordshire OX11 0QX

reply via email to

[Prev in Thread] Current Thread [Next in Thread]