[ On Saturday, August 12, 2000 at 03:29:48 (-0400), Justin Wells wrote: ]
> Subject: Re: cvspserver has no security to start with....
>
> 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.
People do secure exchange of keys for SSH every day you idiot! Just
because you don't doesn't mean that most of the rest of the world
doesn't!
> 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.
If you cannot establish real-world identity to at least some extent then
you are literally dealing with annonymous users and you will in fact
have a more secure environment overall if you design right from the
beginning with this fact in mind (which you have not really done).
Even in MIT's former passwordless environment they still had some
(albiet extremely weak) authentication (it was honour based) and they
most definitely had established the mapping of real-world identities to
virtual system IDs.
Don't throw the baby out with the bath water!
> 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.
CVSpserver is not ever an adequate defense in a public network, not
unless you run an entirely un-authenticated (i.e. anonymous) service!
MIT had reasonable physical security -- there is no such thing on the
Internet!
CVSpserver cannot do any secure authentication and thus cannot preserve
the real to virtual identity mapping. Just because you have only weakly
established the real-world identity of your users doesn't mean you can
ignore the need to authenticate them securely on a public network!
You've already spent far more time, effort, and perhaps even real-world
$$$, in writing your deceptively insecure patch than you would have had
to spend in making SSH work successfully for even the most brain-dead of
your users.
BTW, you need to be a little more careful in how you word things. Your
second last sentence, when read in its entirety, is self contradictory.
I don't think you meant that you wanted to reduce the cost to the
attacker of performing an attack. You probably meant "reducing the cost
of a successful attack".
> 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.
NO, no, no, NO. The very first tool for containing the potential damage
of a successful attack is to not put valuable data on the same host as
the vulnerable application in the first place!
Chroot() and jail() are very sophisticated tools that are rarely used
correctly by application programmers, and sometimes not even by
experience systems programmers. If you realize the fact that writing
any setuid code is hard, then you should know that building a successful
chroot() environment is at least an order of magnitude more difficult.
> > 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.
Don't be an even worse idiot! You cannot successfully chroot() a CVS
process into a sub-directory of the CVS repository (i.e. prevent it from
seeing CVSROOT). That would defeat the entire administrative control of
CVS!
PLEASE READ WHAT I WROTE AGAIN! "chroot() does nothing to increase the
security of CVSPSERVER ITSELF". And remember "security" is all
encompassing -- it is not, and cannot be, authentication alone!
You're looking at the wonderful roof of your barn and saying something
like "well, if I can ever get all the animals in here they'll be nice
and dry." Meanwhile you forgot to put doors on the great gaping
openings in the walls and all the animals have long since run away on
you!
> 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).
This is totally irrelevant and partially incorrect. There are many
other ways to achieve the same degree of protection, and all of them
involve incredibly grealtly improved overall security.
Please go an actually read the "Orange Book" until you understand it,
and then go read as many books with the words "computer" and "security"
in their titles that you can find, and finally once you think you know
everything about this stuff read "Network Security: PRIVATE
Communication in a PUBLIC World" (Kaufman, Perlman, Speciner; Prentice
Hall; 1995). Then if you've still got any questions or bright ideas
then search out the last couple of years of proceedings of the ACM "New
Security Paradigm Workshop" and see what the most current thinking on
these topics are.
--
Greg A. Woods
+1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> <robohack!woods>
Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]>
