Sigh. There seem to be a few new things here, so I will answer it.
On Sat, Aug 12, 2000 at 01:37:30AM -0400, Greg A. Woods wrote:
> Without a securely authenticating real-world
> identity all the accountability audit trails and authorisation controls
> in the world (which only identify the virtual system identity, of
> course) won't help make a system secure.
True. And since nobody is really going to do what it takes to
produce authenticated ssh keys, there is not so much advantage in
ssh as you have previously mislead people into believing.
In a scenario where you are not going to have PGP key signing parties,
face to face contact, etc., with all of your developers, then a much
better approach to security is to work on limiting the risk you face.
By reducing the cost of an attack you reduce the amount you need to
spend on defense. If you reduce the cost enough, then even pserver
is an adequate defense.
Reducing the damage you face means containment. The first tool that
you should think of for containment is filesystem persmissions; and
the second tool is chroot/jail.
> Whether or not you use chroot() does nothing whatsoever to increase the
> security of cvspserver itself.
It does nothing to increase the level of authentication possible, but it
does reduce the damage that can be done. For example, since you are more
confident that the attacker won't get root, you can be more confident
that they won't be able to alter portions of the repository not
accessible to any pserver user. Commonly this would be CVSROOT, but
it could be more.
It also reduces the work you have to do following a breakin: you
don't need to reinstall the entire system, you only need to clean
up the CVS repository. Reducing the cost makes the risk more
tolerable which is an improvement in security (but not authentication).
> However since doing so within cvspserver
> itself literally forces CVS to run as root for more cycles, and since it
> also obviously adds more code that runs as root, it is almost certainly
> increasing the risks, to the entire system, of running cvspserver
> (i.e. making not just cvspserver less secure, but the entire system less
> secure than it could be otherwise!).
Read my patch. None of the code I added examines or uses user input at
all. Not hard to prove that it can't be attacked.
Of course there may be vulnerabilities in the existing pserver auth
code which *does* examine user input. I didn't see any, but I saw
some suspicious cases where errors returned by getline() are ignored
and it's not clear that string (subsequently used by things like
strcmp) will be null terminated. That should probably be fixed.
> Finally since chroot() can be used without modifying CVS itself at all
Only by giving up some or all of the following:
o Permission based limits on an attack where the attacker can
only sniff a limited nubmer of UIDs due to their location on
the network; and also loss of the ability to tell which UID
was compromised.
o Inability to use ACL's, which under pserver may not form real
security, but do act as glass walls keeping developers out of
code they shouldn't touch
I could give up the first, but not the second of these benefits.
Justin
