info-cvs
[Top][All Lists]
Advanced

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

Re: Linux security issues as they pertain to CVS


From: Ralph Mack
Subject: Re: Linux security issues as they pertain to CVS
Date: Thu, 31 May 2001 20:46:01 -0400

[Greg Woods wrote...]

> By allowing *anyone* to use CVS on your machine you are very nearly
> granting them shell access anyway!  If you do so in a totally
> unaccountable way (i.e. with pserver) then you've just lost the
> integrity (and thus the security) of your repository.

> I.e. CVS cannot guarantee that it will not allow a remote user to
> execute any arbitrary command (and indeed maybe even any arbitrary code
> whatsoever).  There is no inherent security in CVS -- anyone who can
> execute it can probably do anything as the user it executes as.

Perhaps this is what I am missing, then. How does CVS access "very
nearly grant them shell access"? By what mechanism do you see this 
happening? 

Are you assuming that there is a risk worthy of consideration that, 
since no service can be proven to not possess program bugs, and since
some bugs allow code to be injected into programs, any running service 
must be assumed to contain code that was not a part of its original 
design, code "contributed" by a hacker at runtime that may run in any 
account to which the service has access? 

The implication of this would be that no restriction in the design of 
a program is of any significance to security, since no assumptions can 
be made about the actual contents of the running code. The only factor
about a running server that is of any significance is the set of accounts 
to which it is may acquire access during execution. 

Of course, this would apply to the code implementing tunneling services
or ssh or any of a dozen other services as well, no? The fundamental 
paradox of security is that you have to trust someone in order to know 
whom to trust. :-) If we aren't worried about those services, then the
argument is really "I trust these coders not to screw up (perhaps only
because I have to) but not those coders." That's fine; but if that is 
the substance of your argument, it needs to be stated plainly. 

Or is there something more specific to CVS that I am missing? Let us
presume from the outset that reasonable precautions have been made about 
the CVSROOT directory that prevent it from being modified except in a 
local account on the system. This is a known vulnerability, dealt with 
easily enough. Is there something else in CVS that permits its users to
affect files outside of the repository?

Once we're past this point in the discussion, I'll bring up the notion of
what is or isn't considered "acceptable risk" and why.

Ralph A. Mack




reply via email to

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