[Top][All Lists]
[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: |
Fri, 25 May 2001 22:57:29 -0400 |
Greg,
> Some of the systems that allow this are buggy. Others are broken by
> design (the system will not let a process permanently discharge its
> privileged state). I have made changes to my NetBSD kernel which I
> believe prevent this from ever happening (at the expense of totally
> eliminating the ill-designed system calls which allow it in the first
> place), but even with those changes I would still not feel safe
> enough to run CVS as root from inetd (i.e. as a non-anonymous
> pserver).
This is interesting and you obviously have a lot of experience in this
area - can you elaborate either here or via private eMail? What system
calls? What design flaws? Is Linux one of the systems to which you refer?
I want to understand the mechanism well enough to avoid problems in
coding wherever possible and to identify and correct problems in other
folks' code that I encounter. Forewarned is forearmed.
> Worst of all of course is the fact that CVS does not need pserver
> junk. It works entirely perfectly with any external remote job
> execution tool.
And any external remote job execution tool will also presumably be
using setuid() to ensure that it follows the rules because that is
how any daemon does it, right? Its chief advantage is that rje tools
tend to be more closely examined because the cost (and benefit, I
suppose, to some) of a hole in such a tool is proportionally higher.
However, I am beginning to understand Mr. Price's argument...
It occurs to me that :pserver brings one valuable thing to the table
that other mechanisms do not. It recognizes that there are two kinds
of CVS user identity - the user identity through which source changes
as tracked by CVS, and the operating system user account used to
determine permissions.
In other modes of access, the operating system user identity becomes
the sole user identity tracked by CVS, since there is no other
identity to be found. This "identity of identities" :-) is a problem
for many environments.
System administrators want exclusive control of system user account
creation. They don't want to deal with user accounts for individual
CVS users - CVS users come and go at an alarming rate especially on
open source projects - the road to Linux was paved with good
intentions - and system administrators aren't equipped to deal with
user account management at faster than the typical corporate hire/fire
rate.
They would rather delegate CVS user identity management to someone
closely associated with the repository they are serving, someone who
can't create user accounts or groups, only assign CVS users to
existing user accounts. CVS users under the same system account have
the same access to the same files and belong to the same groups.
However, CVS is open source and can change. An access mode that uses
something external and well-examined to secure the connection and
verify account access safely (or better yet provides hooks to do so)
but separately manages and secures the user identity within CVS would
be of great value. It could even continue to use the familiar
CVSROOT/passwd file for the latter role.
Now is that what Mr. Price did or did he do something else?
Ralph
- Re: Linux security issues as they pertain to CVS, (continued)
- 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
- Re: Linux security issues as they pertain to CVS, Greg A. Woods, 2001/05/25
- Re: Linux security issues as they pertain to CVS, Derek R. Price, 2001/05/29
- RE: Linux security issues as they pertain to CVS,
Ralph Mack <=
RE: Linux security issues as they pertain to CVS, Thornley, David, 2001/05/29
Re: Linux security issues as they pertain to CVS, Ralph Mack, 2001/05/31