RE: Per-modules readers/writers ?

[Greg A. Woods]

[ On Monday, October 28, 2002 at 12:02:33 (-0800), Shankar Unni wrote: ]
> Subject: RE: Per-modules readers/writers ?
>
> Greg A. Woods writes:
> > 
> > Even basic unix security requires proper use of individual system accounts.
> 
> Absolutely. No argument there. The issue I was talking about was not
> authentication, but access control (authorization), using Unix accounts.
> 
> Authentication using Unix accounts is A-OK. (Use YP, LDAP, whatever..).
> Authorization, on the other hand, is also still being left to the same
> mechanism (YP or whatever), which is rather too coarse and inflexible
> (see the arguments I put forward..)

It's all part of the same thing.  In computer security you can't have
any accountability without authorisation, and to do authorisation you
have to have "strong" authentication, and to have any level of any of
the above you have to have at least an equivalent level of system
integrity protection too.

So, no matter what you want to do with access control you still have to
base it on these fundamental system supplied services, if you want to
actually have any significant level of trust in your system security.

CVS uses a one-to-one mapping files to store change history per source
file and the access controls usable with CVS are based entirely on
granting different levels of access to the directories those version
history files are stored in.  If you want finer control then you either
need to break appart your modules so that the existing accounts and
groups mechanisms can provide the necessary degree of refinement,
perhaps with multiple role accounts for each user; or maybe you can to
arrange things such that you can use C2-style filesystem ACLs on the
directories in the repository, provided you build your repository on a
system with the necessary support for filesystem ACLs (and provided
you're ready to do all the extra maintenance on such ACLs).

With CVS you simply cannot possibly have any secure control over
branches or tags or individual revisions because all those things are
part of the internal structure of the version history files.

CVS is not like bare RCS or SCCS -- you cannot securely implement a
setuid or setgid wrapper around it so that it can take over control of
authorisation.  Even with bare RCS or SCCS the use of set-id wrappers is
highly suspect and often easily bypassed by a malicious user.

Computer systems security doesn't exist just inside the box -- you have
to apply security policies out in the real world too, and its usually
those real-world policies that have the most clout.  If you want to stop
certain users from changing certain branches or tags then make it a
firing offense to do so under your overall security policy and make sure
that you have implemented good strong system security so that you can
back up your finger pointing with hard evidence and thus be able to fire
the right person whenever they do something wrong.  The "technical
control" in this case is a potentially mechanized audit that reveals the
unauthorised actions of any user.  The recovery and punishment are
implemented outside the system by "manual" procedures.

> I see that the CVSNT folks are adding CVS-level ACLs (access control
> lists), using hidden ".perms" and ".owner" files in repository
> directories that contain files. Should probably take a deeper look at
> how they implement this, and how it ties to various authentication
> mechanisms like :pserver: ..

You're welcome to -- just try not to be fooled into thinking you're
actually getting any level of enhanced or more flexible security in
return because you would not be.

-- 
                                                                Greg A. Woods

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