Re: New update to the CVS ACL patch to support user groups

[Greg A. Woods]

[ On , July 25, 2001 at 09:06:29 (-0500), address@hidden wrote: ]
> Subject: Re: New update to the CVS ACL patch to support user groups
>
> address@hidden (Greg A. Woods) writes:
> > 
> > [ On Wednesday, July 25, 2001 at 13:24:43 (+1000), Ellison, Martin [IT] 
> > wrote: ]
> > > Subject: RE: New update to the CVS ACL patch to support user groups
> > >
> > > My understanding is that this allows the users direct access to the
> > > repository (*,v) files. Correct?
> > 
> > Not explicitly, no.
> 
> If you want to use filesystem ACLs and you want the users to be able
> to manipulate them, then explicitly yes.

Well, OK, but that's what I said later.  Even without ACLs though the
access to the repository is only implicitly allowed and can be easily
deterred with a good security policy and appropriate accountability
measures (and not having so much security that users are forced to break
the rules to do their jobs).

>  The users have to be able to
> run the commands to modify permissions/ownership on those files.  They
> also need to be able to change their password and install ssh keys.

Not necessarily -- that's something that can be done for them.

> I'm not sure what you mean by "secure accountability", are you talking
> about general C2-like audit trails, or are you thinking of something
> specific with CVS?

Secure accountability simply means having real Unix user-IDs that are
authenticated and authorised by the system.  The level of detail in the
normal Unix accouning audit trail is sufficient for basic secure
accountability.  C2-style file access audit trails are only necessary if
you need that level of accountability.  Realistically you can easily
write a security policy that'll deter users from doing things they are
not supposed to do so long as you show them that you have basic
accountability measures and so long as you don't provide so much
security that it gets in their way and makes doing things the authorised
way "too hard".

> Where is CVS internally insecure?  Is this just theoretical because it
> wasn't designed that way, or do you know of specific weaknesses?

I've seen very questionable code that's likely vulnerable to any number
of attacks.  CVS still core-dumps on me regularly, a sure sign of
vulnerabilities.

> The network security is certainly a problem with pserver.  You
> shouldn't use it on an untrusted network right now.

And just how many people know how to set up a "trusted network"
properly?  Probably only a few thousand in the entire world!  Right now
you've probably only literally one way to make it work securely in all
but the smallest and most dedicated LAN environment, and that's by using
IPsec between all clients and the server.  Good luck, you'll need it!

-- 
                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <address@hidden>     <address@hidden>
Planix, Inc. <address@hidden>;   Secrets of the Weird <address@hidden>