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




reply via email to

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