info-cvs
[Top][All Lists]
Advanced

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

Linux security issues as they pertain to CVS


From: Ralph Mack
Subject: Linux security issues as they pertain to CVS
Date: Fri, 25 May 2001 08:18:01 -0400

Hello,

I've been following the discussion between Messrs. Price and Woods
with some interest but with little comprehension. 

I know what setuid() is and does fundamentally - it lets a privileged
user act as another user. It is used to perform services in behalf of
another user and actually exists for a security purpose - to ensure 
that the program can't perform actions that the user is not ordinarily 
permitted to perform. That's one edge of the sword. The other edge is 
that if the program can be induced to improperly identify the user for 
whom it is performing an action, it may inadvertently permit some other 
user to perform actions they are not ordinarily permitted to perform.

I suppose one approach (perhaps I should call it the Woods 
approach :-)) would be to treat me as a child and say "setuid() baaad - 
you aren't wise enough to manage that kind of power - forget it". Of 
course, I never liked that kind of treatment even when I was a child. 
What I much preferred, both then and now, is to understand the 
circumstances under which a powerful tool can be harmful and how to 
mitigate the risks to an acceptable level. (Yes, there is ALWAYS such 
a thing as an acceptable level of risk.)

Now it seems to me that when looking at a program I have to ask "What
actions can this program perform in a setuid() environment?" 

CVS can edit files in CVSROOT, which include some scripts that will be 
executed in the server context. This is an interesting risk, but one 
that can be more easily tightened down, at least to some extent. 
For instance, these files can be restricted fairly easily to only be 
written to by a group whose members have individual login ids and no 
pserver access.

CVS can also do what it is meant to do - edit source files under revision
control. Assuming that somebody got somebody else's pserver password by
sniffing, etc., I fail to see how this permits the user to do anything
except checkout, edit, checkin, tag, and remove files from the source 
control system, i.e typical CVS user actions. There is a risk of rogue
code getting slipped in, but this can be managed by other means. I am
assuming that the source code isn't seen as a major "trade secret" by
the owner of the CVS repository. This is pretty limited in scope.

Of course, the last 50 or 100 Linux patches I've seen from RedHat have
been from exposures where buffer overflows could be exploited to execute 
a statement from a setuid() environment. I'm sure there've probably been
a few of those fixed in CVS and I'm sure there may eventually be a few
more. This sort of thing is the security risk (deemed acceptable by most)
of working in any software environment these days. 

That's my child's-eye view of setuid(). What gaping hole did I miss?

Ralph A. Mack




reply via email to

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