Re: CVS access control

[Tobias Brox]

address@hidden - Wed at 04:13:18PM -0400]
> >> I see nothing wrong with SSH.  Also, from what I've heard, pserver is
> >> not secure.

Ok, I've looked a bit at the documentation - pserver is not at all secure.
I'd say it would even be better off without password authentication at all
(and use pserver only where public access is wanted).

[Me]
> >I think we're miscommunicating a bit.
> >
> >If we rely on the file system for all the access control, SSH is perfect!
> 
> I think you're confusing authorization with authentication.  SSH is perfect
> for authentication.

Sorry for beeing unclear.  pserver and ssh does the authentication (who are
you?).  When I say "access control", I'm thinking of authorization (who
should be able to do what).  I do think that authentication is out of the
scope of CVS (ok, pserver _is_ already a part of CVS ... but anyway ...). 

It is certainly a common mistake to believe that a prompt with user name and
password actually is the same as access control.  I once made a system with
username and password in plain text, and no authorization control at all -
and suggested to the users that the password box just as well could be
removed because the system was completely unsecure.  Anyway, the users
insisted to keep the password box - because then it _seemed_ secure :-)

> It does not do authorization (short of minimally
> controlling what set of commands you're allowed to execute).

When "cvs" is the only command a user can use, all authorization is
practically left to CVS.  If a user can log in and do anything, all
authorization is left to the file system.

> >2. A user that can modify the ,v-files directly, can make a lot of harm -
> >including falsify old versions and corrupting the files.  You can't do any
> >irreversial harm (at least it shouldn't be possible) through CVS.
> 
> This can be controlled through SSH (judging from your email I think you
> already know how).  An alternative is to use a setgid cvs executable and
> file system permissioning.

Then we have to assume that there are no "security bugs" in CVS as of today.
Maybe my CVS documentation is a bit outdated, but it clearly states that
it's no good idea to run CVS set[ug]id, further it actually also states that
"once a user has non-read-only access to the repository, she can execute
programs on the server through a variety of means".

> >3. We might want to grant a user to commit only to a specific branch.
> 
> Would said user be able to redefine branches?  If so, then such ACLs are
> useless from a security POV.

Of course, anyone beeing denied access to certain branches should also be
denied to redefine those, it should be thought of if anyone is to implement
such a feature.  As far as I've understood, there is already some
possibility to restrict the permissions of doing branching through the
valtags file.

Well, point 1 is not a good one, point 2 can already be solved today (if we
assume cvs is "safe"), so then it's only point 3 left - I wouldn't call it
important anyway.  Authorization is certainly far out on the edge of what
can be considered within the CVS scope.

> >2. setuid'ness/setgid'ness - disallowing people to modify anything under
> >$CVSROOT, except through the CVS tool.
> 
> And how do you control who is allowed to execute the setgid cvs?

Why, if the person is already logged in, he is already authenticated.  If we
assume that some ACL system will be built into CVS, there will be no need to
restrict the execute permission, as CVS will do the authorization control.

Also, if we could assume that CVS is "safe", it might not be that critical
anyway, as it shouldn't be possible to do any irreversal damage through the
use of cvs...

> I think you misunderstood my point.  How do you control who is allowed to
> execute this setgid cvs?

Through the file system ACLs, of course.

> One way is to use file system ACLs.  Another is
> to control access to the directory that the cvs executable is in.

Restricting the directory access, that is ... at least with posix compliant
file systems.  It's certainly a bit messy, but as far as I can see, it's the
only way to do it.  It's easier to deal with a setuid binary (then again,
that's more risky), as it's possible to restrict execute permission by the
group.

> I don't know enough of the details to understand why it makes a copy of the
> archive file (this may be a RCS thing).  If you're able to stop this, then
> maybe you have a point.

Still write permission on the directory is needed, as lock files should be
created, and as the user might want to add and remove files.

What I did say in my original post in this thread, was that if somebody is
to create an ACL system within CVS, then it should be possible to tune it
down to the exact file, not to the directory.  I can't see any problems with
that.  ACL systems within CVS will of course only make sense if the cvs user
is prevented from directly accessing the repository files - thus the exact
permission on the repository directories is irrelevant.

--
Unemployed hacker
Will program for food!
http://ccs.custompublish.com/