On Mon, Aug 07, 2000 at 02:11:13PM -0400, Greg A. Woods wrote:
> The *ONLY* secure way to use cvspserver is to rip out the current crap
> in the implementation that requires it to run as root and then to run it
> only as a non-privileged unique user-id which is given permission to
> read (and only read, i.e. it must be through group ownership) the
> CVSROOT/passwd file.
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.
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.
> This of course still implies that it only be used within a secure
> network, and as such it is still of extremely limited utility and it is
> still completely unnecessary given the available alternatives that
> completely wipe it out in terms of enhanced security!
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).
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.
As for people staging attacks from my system--there's not very much for
them to work with inside the chroot(2) so I'm not too worried about it.
I may even shut off the ability to execute programs in there altogether.
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).
> > CVS pserver has always been script kiddie fodder, but my patch makes it
> > much less so:
>
> NO, it does NOT!
YES, it DOES! (Don't you feel like a kid again?)
> 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.
> > Your argument against my patch boils down to "I hate pserver, please
> > don't improve it." Ridiculous.
>
> You literally, technically, *cannot* improve it, especially when you
> misunderstand systems security, so PLEASE don't even bother trying!
Wrong again. There is only *one* problem with pserver that I cannot ever
fix, and that is the problem with passwords being sent in the clear. Every
other problem can be fixed, and every such fix is an improvement. My
recent chroot patch fixed several problems, thereby improving pserver
in several ways.
Even the problem with cleartext passwords could be fixed, but that fix
would require modifying the clients as well. In theory it would be just
as easy to modify all the clients so they use your ssh solution instead
so it's not as attractive to fix pserver completely.
On a scale of 1 to 10, pserver can never have level 10 security (so long
as the password problem remains). But before my patch it had level
3 security and now it might be a 7.
Justin
