RE: New update to the CVS ACL patch to support user groups

[Greg A. Woods]

[ On Wednesday, July 25, 2001 at 13:24:43 (+1000), Ellison, Martin [IT] wrote: ]
> Subject: RE: New update to the CVS ACL patch to support user groups
>
> My understanding is that this allows the users direct access to the
> repository (*,v) files. Correct?

Not explicitly, no.

The implication is that the users will have shell access to the CVS
server (and thus have implicit access to the repository).  However
through a combination of various mandatory access controls and
accounting audit trails it's possible to prevent users from exercising
their ability to gain shell access to the CVS server.  The mandatory
access controls are much easier to implement securely with SSH than with
RSH too since with SSH you can force the user to only be able to run the
"cvs" command.

However it's very very important to keep in mind that CVS is not a
"secure" application in any sense of the word and so you must always
assume that a dedicated user authorised to make use of "cvs" will have
the potential ability to gain full shell access to the CVS server.  Only
accounting audit trails and external security policy can successfully
deter this to the point where it's extremely unlikely since obviously a
user running CVS will still be running a cracked shell the same user-id.

Note though that if the CVS server is a C2-secure class of system (or
better) with file access audit trails enabled, then you can force users
who access the repository directly to be accountable for their actions
(thus in combination with an external security policy deter them even
more from directly accessing the repository).  Since most such systems
also have mandatory per-file/directory access control lists too you can
further restrict users to just those modules (and even files if you're
very careful) they're allowed to manipulate (i.e. physically restrict
them from doing anything they're not already authorised to do while at
the same time deterring them from doing it directly without the
assistance and moderation of CVS).

Unfortunately CVSpserver is totally insecure.  It offers absolutely no
secure accountabilty (which allows redirection of blame), provides no
real network security (it's just a plain clear-text TCP connection), and
worst of all it affords no protection whatsoever from a dedicated
attacker since CVS itself is not internally secure.  CVS was not
designed and implemented to be run in the "pserver" style of operation
and be made responsible for authentication and authorisation as well as
auditing -- it was designed and implemented only to be run by users
authorised and authenticated by the underlying operating system.
CVSpserver should be ripped out of CVS and left behind as a futile
failed experiment.  There was never any real reason for it in the first
place (just short-sightedness), and there's even less reason for it now
in a day when secure external network acess protocols such as SSH are
widely implemented.

-- 
                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <address@hidden>     <address@hidden>
Planix, Inc. <address@hidden>;   Secrets of the Weird <address@hidden>