info-cvs
[Top][All Lists]
Advanced

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

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


From: Mark
Subject: RE: New update to the CVS ACL patch to support user groups
Date: Fri, 27 Jul 2001 10:44:56 -0700 (PDT)

--- "Greg A. Woods" <address@hidden> wrote:
> [ 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)).

I see a difference between handing out a shell account that has write access to
the repository directory structure and someone cracking pserver to give them a
shell with such access. With pserver I have some assurance. However with people
with real accounts with UNIX write access to the repository, I have no
assurance. How do you track/monitor (in a prevent mode) activities of rm, cp,
mv, vi, chmod, etc... in the repository for people who just login to the system
and don't use CVS commands and have other legit reasons for being on the
server?

> 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.)

I've done this with pserver. (unless of course someone makes pserver cough up a
shell, which is unlikely. I've search the web many times to find documented
pserver problems/holes.)

> 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 have it setup now with pserver, readonly access to repository directory
structure, no attempts made at preventing shell access to the server.

> 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!  ;-)

They are not worried about CVS because it does not start or run or require
root. I guess their concern is root access and OS level security.

> 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.

Having real accounts is fine by me, I prefer not to maintain the passwd file.
But developers do not want them and the SA's would create them (in their own
time), but would balk at having to maintain setup and onging changes to group
memberships, then I would have to maintain sticky bits on new directories
developers create all the time. With pserver I don't have to worry about sticky
bits or group memberships (or even unix accounts ;).

> 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.

I agree, but that type of maintence can be time consuming. root still would
have to maintain group memberships as people are added and removed from
projects. (1-6 CVS servers & 10-40 projects or more and who knows how many
people, and this will grow after the first year)

> 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).

No agrument here, not in my scope of responsibility.

> 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.

the SA's consider the OS secure by their standards. They have their concerns of
sercuity and accountability on the OS (they consider the CM team owner of the
non-root pserver account). I have concerns for the physical sercurity of the
CVS repository structure, as long as the repository is reasonably secure, then
I am concerned with accountablity. I know this isn't perfect or even resaonable
by some standards, but I have to work with the environment I am in.

> > 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.  :-)

Again, back to to situation of pserver coughing up a shell. Or are there other
things?

> 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.

I can't comment on the protocol, or the rest of CVS, but the CVSROOT/*info
files are defined/maintained by the admin on the server and run on the server,
(mine) don't have any user interface (except maybe printing error messages
back). Like I said I have search the web for holes in pserver, don't think I've
found anything to worry about. Maybe I just haven't found them.

> 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.

Doesn't the OS provide security for the OS? Why should systems that run CVS as
a non-root user, compromise the security of the system? Yes, if CVS is forced
to cough up a shell, you have one as that non-root user. If that non-root
account user and group has no owner/group rights anywhere else on the system,
how much does CVS reduce the current level of OS security for the system
(whether or not SSH is used on the OS)?

I agree about accountablilty, but pserver doesn't equate to anonymous
repository access either. It does have some level of accountabitity, granted
not as much as SSH would.

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

Tryed that. root on any unix style box is reserve for the SA group. It would
take an act of God to get a unix box on the network that the SA group doesn't
own, for security purposes.

> 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!

Well I think there are enviroments for pserver, unless I find evidense the
pserver can cough up a shell in a way that is not preventable. I guess we will
just have to agree to disagree. I am not saying you are wrong, just saying I
don't see a clear and present danger to using pserver, to abandon its ease of
use, its feature set and deal with the logistics and maintenance of other 
methods.

=====
\=======================\
\==\  Mark O'Brien
\==\  CM Consultant
\==\  address@hidden
\=======================\

__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/



reply via email to

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