Re: Linux security issues as they pertain to CVS

[Mark]

I think CVS does need the "pserver junk". I may not always be
everyones first choice, but it needs to be there and maintained.
The CVS Administrator does not always have root access, thus may
not always be able to implement whatever sercurity measures he sees
fit.

I am a month into a job to set up a CM program with CVS. We
currently don't have CVS running yet. Here's the situation:

It is a large company and a lot of red tape to get anything done.
I've had all of 45 minutes with the System admin about getting CVS
setup since I started. He would prefer not running CVS running as
root, and if root has to run it they would have to own CVS, test it
and create a whole new line of red tape for
changes/updates/patches.

I want to be able to admin CVS as far removed from dependancy on
the Sys Admins as possible. I don't want to submit requests for new
users, wait on Sys Admins to test any patches to CVS I might want
to try out, create repositories as needed, control access to
repositories (unix groups), add new users, switch users about
projects, etc... I want to be free from the 15 levels of approvals
and signoffs and 1 to 4 week turnaround times.... well you get the
picture.

As for the network environment, .rhosts are not allowed, 80-90% of
the developers do NOT have UNIX logins. They are not running any
ecryption stuff, just plain NIS+. The company network is behind a
firewall and there is a level of trust, as with any company, to
give developers write access to the code. I have read lots of posts
from the archives about security and CVS client/server, and what I
got from them is that it would be great if developers just didn't
need write access, then things would be alot better. But we have to
step out from that and accept some risk so we may develop code and
be a profitable company. That said.

Now what is the least dependant way (minimal dependancy on sysadms
and other support groups) and easiest on the developers  to role
out a client/server CVS solution behind a coporate firewall,
developers do not have/want UNIX logins?

I am going to try a jailed root wrapper that setuid to a non-root
user (no passwd/no shell if possible) and setgid to the group that
owns the repository, in order to run CVS without root. This will
reduce the dependancy of the Sysadms to disk space and the wrapper
program.

I am following the procedure outlined at
http://www.unixtools.org/cvs/server-how-to.html to do this.

Has anyone tryed this? Does it work? I guess will find out.

I have seen people mention pserver can be run from a non-root used,
after hours I searching the archives, that web site was the only
real description on how to do it.

I think pserver should be improved on to reach a reasonalble secure
level or operations (I've leave that to those more experienced in
security that I). But first decide what are your security goals?
Securing root access and the OS? Securing the CVS repository?
Foolproven authentication for changes to the repository? Outside
the trusted users of CVS, and behind a corporate firewall, is
pserver at an acceptable security level, how about pserver not
running as root? What would make it a little better.

I think a good explaination of how to run pserver as a non-root
user would be good to have in the CVS manual.

I think psever (as root or non-root) may be fine for most
companies, running behind a firewall and not servicing clients from
the internet.

Just my thoughts.  Anyone have comments on the non-root jailed root
wrapper to pserver from the web site above?

Cheers,

Mark

> Combining this latter fact with the privilege re-enhancing
> problems and
> you're a sitting duck if you run CVS pserver as root.
> 
> 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.
> In that form it is devoid of all responsibilities w.r.t.
> authentication,
> authorisation, integrity and privacy.  The CVS administrator is
> free to
> choose any external RJE tool that meets their security
> requirements in
> combination with the needs of their clients (eg. rsh, ssh,
> stunnel, a
> VPN+rsh, etc.).  Let the security tools do their job and let them
> take
> responsibility for *all* security issues!


__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/