Re: CVS access control

[Greg A. Woods]

[ On Thursday, September 27, 2001 at 20:08:45 (+0400), Tobias Brox wrote: ]
> Subject: Re: CVS access control
>
> I'm quite sick of internet banking services where the bank (of course)
> states "this solution is 100% secure!".  Most of the services I've seen have
> no security at all against possible trojan horses at the client computers -
> anyone with root permissions and enough knowledge and skills might hijack
> the session.

Not to mention almost no real authentication of the client user in the
first place....

> To get back to where this discussion started - we were discussing
> possibilities for adding ACL into cvs.  If CVS had ACLs, and they were
> securly implemented, it wouldn't help at all, you said, because the user
> anyway could go directly to the repository and do whatever he liked.  That's
> not so true - the _documentation_ must clearly tell about this possibility,
> and what countermeasures the system administrator might do to cover it up.

Some database engines (well, actually, most of the good ones) implement
internal ACLs on tables and records because in a carefully designed
database (i.e. application using a database), such ACLs can make it much
easier to implement a security policy that specifies detailed privacy,
integrity, and accountability for given data and data relationships.

However as yet nobody's really identified any generic security policy
requirements for CVS that cannot be implemented with filesystem ACLs.
The best that's been presented so far are some generic process level
controls which would not necessarily be applied on a per-file basis,
such as the right to create or delete tags.  The "cvsadmin" feature
could be extended or duplicated to cover tagging.  It wouldn't be any
more secure than the "cvsadmin" feature is of course, but it would
provide a simple way to provide run-time visible security policy
guidelines which could be more properly enforced with less stringent
technical controls such as accountability audits.

Finally, you're right about qualifying the "securely implemented" part,
but perhaps not for the reasons you think.  None of the proposals for
ACLs in CVS have considered the issue of secure implementation.  Perhaps
that's because deep down people realise that any such consideration
would prove that trying to securely implement ACLs in CVS would either
require a fundamental ground-up re-design; or would not be possible at
all.  CVS was knowingly designed _without_ security in mind and it
definitely shows.  This isn't necessarily a bad thing, but it does place
very certain limits on what kinds of security features can be
successfully added to CVS (i.e. hardly any! ;-).

In the end one really has to wonder what's to be gained by trying to add
internal ACL support to a versioning system.  Several far more important
factors mitigate this need, and I would claim mitigate it into nothing.
For one a versioning system is, by definition, providing a detailed
audit trail that can very very very easily be used to enforce
accountability (and any user who doesn't realise this and thus instantly
realise the risk of trying to do something they're not explicitly
authorised to do is probably not sane in the first place! :-)  Another is
of course that the level of trust between the members of a group working
on a given module in a given repository is necessarily much higher than
it would ever be in the example of a group of users using a database
application.

(having accountability in CVS of course presumes you never use cvspserver :-)

> Still - security through obscurity /is/ better than no security at all!

Nope, not true at all.  Security by obscurity leads to a false sense of
security, and as pretty well every rational sane person in North America
should realise by now there's really nothing worse than a false sense of
security!

-- 
                                                        Greg A. Woods

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