Re: Problem with admin privileges

[Todd Denniston]

Julian Opificius wrote:
> 
> Todd Denniston wrote:
> >
> > Big question: What do you think using :pserver: at this point, gain you and
> > your users over just :ext: over ssh?
> >
> > Because they already have (and will continue to have) valid system shell
> > login, from here it only looks like more admin trouble to setup and maintain
> > pserver, plus it probably reduces the authentication or authorization you
> > had from the ssh and system level, especially when a new pserver hole comes
> > out.
> >
> How does a hole in pserver reduce security? Is ssh protecting me or not?
>    I realize that all security is additive, but pserver would seem to be
> no more than paint on the wall of ssh, meaning that if ssh goes down,
> pserver won't help, but then again it won't hinder either.
> 
> >
> >>I have solved most of my admin problem by running admin users as their
> >>themselves using $CVSROOT/CVSROOT/passwd entries like this:
> >>  "username:password"
> >>rather than as the global cvs user:
> >>  "username:password:cvs"
> >
> > <SNIP>
> >
> > Why use the $CVSROOT/CVSROOT/passwd at all, just use the system
> > authentication fallback, it SHOULD make your life easier because only the
> > system level auth files need scrubbed when someone leaves not the system
> > level AND all the cvs repos.
> >
> 
<Moved CHUNK to below>
>
> The only reason I am using pserver is that it allows my users to have
> CVAS controlled access to the respositories without giving them dierct
> write access to them. If you can suggest another way of doing that, I'd
> be glad to use it.
> 
>  From a security perspective, my understanding is that ssh gives me
> adequate protection from invasion from the outside world, (ssh is the
> only port mapped through NAT to the server) and I have not yet
> identified a need to protect my data from malicious intent from inside,

Actually you have apparently. You are attempting to prevent your inside
users from directly accessing the repository directories.

> so I'm not really sure what the risks of pserver over ssh really are.

First lets reduce it to a pserver question, because after ssh is done
everyone is 'on the inside' using pserver.  As you say above pserver is
letting you map all your users to one UID[1] which can read and write to the
repository. As long as none of your users can login as this UID, none of
them can 'fat finger' damage any files in the repository. However if pserver
is compromised in a way that lets it become the special IUD and then allow
an arbitrary command to be executed, the damage can still be done. Though to
do it may require a malicious intent, the intent could come from either a
user or a malformed client. IIRC at least one of the recent pserver holes
would allow arbitrary command execution.


[1] Actually I am pretty sure this is now not true, because you have taken
off the :cvs on the end of your names in the $CVSROOT/CVSROOT/passwd.

Originally I was interpreting your change to the $CVSROOT/CVSROOT/passwd
file[1] to be all users, and if that was the case, then you had basically
removed the one thing pserver was getting you, however I now see that it was
only the admin accounts (which I hope are not doing double duty as developer
logins) that became themselves. This misinterpretation is the reason I
suggested that you had already removed your need for pserver.

<Moved CHUNK>
> The only reason I am using pserver is that it allows my users to have
> CVAS controlled access to the respositories without giving them dierct
> write access to them. If you can suggest another way of doing that, I'd
> be glad to use it.

As Far As I Know, you are correct, but at best you are only protecting them
from a fat fingering while in the repository and do not have malicious
intent. The first rule of the repository for users should be that if you are
not the admin you never execute any non cvs command against it. The first
rule of the repository for admins is back it up appropriately, as
hardware/network/software faults can damage the work.  With these two rules,
I believe you should have at least as good a set of protection as pserver
would get you, because you don't have developers with malicious intent and
who follow the rules :}

As long as the developers are using only :ext: cvs commands against the
repository, I believe you should still be able to meet your FAA
requirements:
"FAA-regulated environment, and my CVS respository must be secure, in that
nobody can impair the lifecycle data, and all accesses must be documented
and controlled,  i.e.e all accesses must be via the cvs server."

but would be counting on the backups to prevent you from loosing any
"lifecycle data", which is what you would be back to if they were looking at
you with strictness when there is a known hole in pserver.

In final, Yes using pserver will probably make it easier to "show" up front
that everything meets the requirements, but in the past it has been the bain
of security with cvs. I belive you are in the middle ground between the
"restricted execution of CVS" Mark D. Baushke told you about, and the
trusting developers ground of :ext: on a system they can execute more than
cvs on.  I further belive that you are only mildly protected from what you
worry about, using your method.  Where as one of the "restricted execution
of CVS" would probably allow much more of the FAA level security lock down
and logging.

if you want further reading I suggest searching the list's archive for 
Greg Woods AND pserver 
OR 
Greg Woods AND authentication AND|OR authorization.

I think the horse is dead, so I'll stop beating.

<SNIP>
> 
> As a final disclaimer: I'm an embedded software engineering manager, not
> a network guru, and the network is a means to an end, not a reason to
> live, so if I'm missing something, please feel free to snicker and roll
> your eyes - as long as you then enlighten me as to what I "should" be
> doing ;-)
> 

I am also not a network guru, am only going by what I have read, so I also
could be wrong.

> Cheers!
> 
> julian.

-- 
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane) 
Harnessing the Power of Technology for the Warfighter