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

[Greg A. Woods]

[ On Wednesday, July 25, 2001 at 12:18:14 (-0700), Mark wrote: ]
> Subject: RE: New update to the CVS ACL patch to support user groups
>
> Just preventing write access, (cp, mv, chmod, etc...) (ls, cd, cat, etc.. are
> okay)

Well then I'm sorry, but you don't have any such assurance now that
people can't mess directly with the repository files with cvspserver.
The repository is effectively wide open because there's no guarantee
that CVS user's can't get shell access to the server, and since you
don't have real Unix accounts for every user you've got little to no
real accountability (all the possible audit trails are easily
obliterated by the same CVS user(s)).

Only with careful configuration of SSH and careful auditing of all
access and accounting logs can you provide sufficient deterrent and
control against people accessing the repository directly.  (You can't do
this with cvspserver and you can't easily do this with RSH either.)

In addition if you make using CVS easy to use in the "proper" and
authorised way you'll drastically reduce the likelyhood any authorised
user will bypass using CVS to manipulate the repository.  In fact in any
relatively tight-nit development group you probably don't have to worry
about trying to overtly block shell access to the repository machine.
There are many legitimate reasons for people to do read-only direct
accesses to the repository files.

> I don't know about issuing UNIX accounts to Windows developers for the sole
> purpose of accessing the CVS server. I work in a large company. Support from
> the (understaffed) Unix Admins is not really available (they have there hands
> full with clearcase and supporting production environments, and adding to 
> their
> taskload (if they are willing to accept it)is not a way to win their support 
> on
> real issues) and they don't want to be bothered with aditional tools to
> support. The SA's don't want CVS running as root so they don't have to support
> it and don't care that CVS pserver runs as the same non-root user for 
> everyone.

Well, any Unix admin worth their salt will know that Unix users need to
be assigned proper individual Unix user-IDs, etc.  I'm sure if you
explain it to them in terms of all developers being normal unix users,
not in terms of CVS alone, you'll be able to show them that creation of
Unix accounts for all developers is a necessary prerequisite to having a
secure CVS repository.

Even if you don't use SSH, but instead only RSH, you must still have one
unique Unix account for every developer.  I'm sure though that if you
get your SAs talking about systems security they'll immediately discount
RSH as a viable alternative (even if they do so for all the wrong
reasons) and they'll quickly jump on the SSH bandwagon.  Just be sure to
moderate their enthusiasm.  You'll want to ensure that what's
implemented is still usable -- you don't want them forcing users to type
a password or passphrase for every connection (which is pointless
anyway, unless perhaps the client is a portable computer, since the
sever must implicitly trust the client computer hardware, software,
etc., lest a trojan-type program or device masquerade as the user).

> To have the SA's create and maintain unix accounts (groups memberships)
> countinually for all users is a drain on everyone.

Creating proper Unix accounts is far less of a drain than having some
internal user go rogue and perpetrate a damaging attack that'll hurt
everyone!  TANSTAAFL!  ;-)

If your SAs are smart enough not to want CVS runing as root then you're
probably half-way to convincing them that every user needs a unique
personal system account.  Creating unique system accounts for everyone
can actually make an SA's job easier, at least so long as everyone's
expectations are properly managed.

The most effort required to manage a CVS repository on a Unix host
is actually in the maintenance of correct ownerships and permissions in
the repository, and this only really becomes a burden on the superuser
when the repository resided on a system that requires superuser access
to "chown" a file or directory.  Even though "chown" only needs to be
restricted when filesystem quotas are implemented, many systems which
support quotas restrict chown regardless of whether quotas are enabled
and in use or not, which is silly and frustrating, but that's life.

> Also, if SSH requires root
> to install and maintain, thats and additional burdon (unless I can do this
> without root) on the SA's.

If your systems don't already have SSH installed then it's high time
they did.  Any system that's connected in any way to any public network
really should have started using SSH exclusively a couple of years ago,
if not before.  Nobody on such a connected network should be using
telnet, rsh, ftp, and the like, even only internally.  Only on a really
tiny and carefully firewalled network (eg. my own personal network at
home, where both inbound and outbound telnets, etc., are all blocked)
should such insecure protocols ever be allowed.  If the company network
on which your CVS server host resides is anywhere near as large as you
say the company itself is then it's well beyond being tiny and carefully
firewalled (no matter what your network admins might try to claim).

> All things considered, pserver is a very nice and
> attractive way to handle things. If I could take on SSH admin myself (without
> root) and could handle repostory write access like pserver readers/writers
> (without having to deal with unix groups), then I would be willing to consider
> the startup costs of setting up real accounts for windows developers on the
> UNIX side.

Obviously doing SSH admin yourself without root access is simply not
possible.  You normally have to have root (or equivalent) access to
create Unix accounts.  You can't really have SSH without having Unix
accounts.  You can't have any degree of real security at all without
Unix accounts.  Accountability is one of the cornerstones of systems
security and you can't have accountability without having a unique
system ID for every user.

> I currently do not have any problems. We are on a private network behind a
> firewall.

An often quoted statistic suggests that over 80% of known (reported)
attacks are by inside users already authorised for some degree of access
to the network or system being attacked.  You won't know you have a
problem until it's too late, an then you'll have a very big problem.  :-)

Most of the work one does w.r.t. systems security is preventative.  You
have to do it up front or you gain nothing whatsoever.  You can't
prevent the horses from escaping by shutting the barn door after they
have run off!

> If pserver was riped out of CVS, what functionality/features would go
> with it? Since .rhost files are commonly banded at companies from what I have
> seen, what is left if pserver is removed from CVS C/S protocol?

CVS can use any external remote job execution tool.  SSH, RSH, SRP,
Stunnel, etc., all come to mind.  All of them require real Unix accounts
on the server though.  All of them require that the server trust the
client and vice versa.  Some of them also require that the network be
physically and logically secure (but not SSH or SRP or Stunnel).

> I am begining to think that my setup with non-root pserver is the simplest for
> my environment.

It might be the simplest, but it's also just about as insecure as if it
were running as root -- the real problems are not in the server starting
as root -- they're in the protocol, the rest of CVS, and all of the
programs that might be invoked from CVSROOT/*info files.  Having the
server start as root just makes the attacks more interesting and the
rewards (to the attacker) more enticing.

> Thats just it. I don't want to mess with Unix accounts and especially
> maintenance of group lists. I don't have root access. At my current job this 
> is
> not a reasonable implementation of CVS. Is there any other c/s CVS setup
> besides pserver doesn't depend on root to maintain accounts or group lists?
> This is a feature that pserver provides.

If you want a secure CVS server you really Really REALLY must have Unix
accounts.  They're the cornerstone for the Unix security model (and
indeed for any host-based security on any multi-user system!).  You want
to have real system accounts because you can't have real security
without them.  In order to provide privacy and integrity you must be
able to securely identify the entities who you authorise to perform
various operations on your data.  You can't hold anyone accountable for
their actions if you can't prove concretely who they are.  You can't
prove who ran a given process (or if you have C2-style filesystem access
audit trails wo modified a given file) unless you have a one-to-one
correspondence between system accounts and real-world users.

> maybe at a different job where I may have root on the server or the SA's are
> more responsive, and the number of projects and developers are smaller and
> don't move around as much, I can forgo pserver setup. but pserver should not 
> be
> riped out of CVS. It has its uses. there are ups and down to everything. 

How about setting up a separate CVS server machine that you manage
yourself?

> Thanks, this is good to know and I will try it out.

Good luck!  Don't be afraid to post any new questions, but please do try
to decipher the relative manuals first!  ;-)

> But I still think
> (non-root) pserver has its place and uses

No, there really is no place for cvspserver.  There never ever was.
Even if you don't want *any* security you can still use simple remote
job execution tools external to CVS.  Every book on TCP/IP programming
contains at least one example of how to write such a tool!

> IMHO, pserver is better than sgid
> bits on cvs binaries

Making CVS set-ID is a guaranteed recipie for disaster.  Never ever make
any program set-ID unless it was specifically designed to handle the
responsibility and unless that's the only thing it's designed to do.

> or trying to keep up with set bits on directories and ACL
> access controls

Maintaining filesystem permissions bits is a necessary part of all CVS
repository administration (well, not the full ACL stuff -- that's only
an optional feature you might want in very specific scenarios).

> or patching CVS to do these things.

CVS works just fine with SSH or RSH, etc.  :-)

-- 
                                                        Greg A. Woods

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