[ On Tuesday, August 8, 2000 at 02:14:08 (-0400), Justin Wells wrote: ]
> Subject: Re: cvs-nserver and latest CVS advisory (Was: patch to make CVS chroot)
>
> So, if I do that, how do I get access control lists? Currently the only
> reason why I have to run pserver as root is so that I can hand out
> write access to my repository on a module by module basis. Core
> developers get to write to every module, but some developers are only
> permitted to write to one or two modules. I do this by putting people
> into different unix groups.
Once you have real unix user-ids then you automatically get unix groups
and the ability to control write access to various parts of the
repository by controlling which groups are allowed write access to the
repository directories which contain the files you wish to protect.
In fact you can get more powerful ACLs than unix normally offers by
default by simply switching to a type of Unix system that offers more
powerful ACLs. These types of systems are not rare and are available
specifically because there are indeed valid reasons why someone might
want
> If there is some other way I can do this, without having to rely on
> unix groups, then I don't have to run pserver as root--and that *would*
> be a big improvement.
Since the filesystem protection model is what CVS is designed to use,
there is no other way.
> You're still operating under the incorrect assumption that there is a
> significant cost to a break in. In my case, there is not. The cost is
> just the time it takes me to reinstall the box--hardly any time at all.
> I might even reinstall it from scratch every week or two just for
> fun, since it takes hardly any time at all to do (20 min or so, of
> which I need to be around for only about 5min).
You're not measuring the true costs of a successful attack.
> What's special about me is that all of the data on the box and in the
> repository has already been published to the whole world. There is no
> sensitive information there, nor even on any other machine connected
> to the same network. It's outside my firewall and I never put anything
> sensitive outside my firewall.
A covert attack could modify that data in non-obvious ways and not be
revealed until it is too late to recover fully from the attack.
> CVS "scripts" ought to be written in a CVS-specific language, containing
> some harmless built-ins (for mailing logs, etc.) plus an "exec" command.
> With a good enough set of built-ins, many installations could disable
> the "exec" capability completely. That would substantially improve the
> security of CVS even under the ssh model (you wouldn't have to trust
> that guy in .ru you just gave a login to).
Any sufficiently powerful language is effectivley Turing Complete --
i.e. will allow the cracker to do dangerous things.
> > No, my argument is that there multiple working solutions that do not
> > rely on inherently insecure techniques.
>
> None of which are simple enough for widespread use yet.
SourceForge have found SSH simple and secure enough for *VERY*
widespread use, and I concur with their findings.
--
Greg A. Woods
+1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> <robohack!woods>
Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]>
