[Top][All Lists]
[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
- Linux security issues as they pertain to CVS,
Ralph Mack <=
- Re: Linux security issues as they pertain to CVS, Larry Jones, 2001/05/25
- Re: Linux security issues as they pertain to CVS, Greg A. Woods, 2001/05/25
- Re: Linux security issues as they pertain to CVS, Mark, 2001/05/25
- Re: Linux security issues as they pertain to CVS, Greg A. Woods, 2001/05/25
- Re: Linux security issues as they pertain to CVS, Larry Jones, 2001/05/26
- Re: Linux security issues as they pertain to CVS, Greg A. Woods, 2001/05/26
- Re: Linux security issues as they pertain to CVS, Derek R. Price, 2001/05/29
- Re: Linux security issues as they pertain to CVS, Greg A. Woods, 2001/05/30