[ On Friday, August 11, 2000 at 17:51:37 (-0400), Noel L Yap wrote: ]
> Subject: Re: cvs-nserver and latest CVS advisory
>
> [EMAIL PROTECTED] on 2000.08.11 15:29:07
> >
> > Justin Wells wrote:
> > >
> > > There's zero accountability with ssh too. People just have to sound like
> > > they're nice and competent developers and have an email address that works.
> >
> > Wrong. SSH has strong authentication, which means that in a properly
> > configured Unix server environment it offers you strong accountability
>
> I think there's some confusion here somewhere between authentication and
> identification.
It would seem so. I should have addressed the major flaw in Justin's
reasoning instead of just discounting it. Let's try again:
Authentication is the means by which a secure system verifies the
identity of a user connected in a given session -- i.e. it verifies the
mapping between a virtual system identity and the real identity of the
user who was assigned the virtual system ID using some kind of secret
key or other similar technique (one-time password, challenge/response
key, etc.). Accountability and authorisation rely upon authentication
in order to match actions and permissions with those granted to the
real-world identity. 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. If you leave out any of these
pieces you have no security whatsoever for whatever you authorise any
given virtual system identity to do.
Therefore since the default cvspserver implementation has neither secure
authentication nor a guaranteed enforced one-to-one mapping of
identities to the system IDs that are used to authorise CVS for its
activities, it has absolutely no security from the get go.
Obviously if someone infiltrates your security by faking their real
identity then you don't have any way in which to hold them accountable
since you don't really know who they are. SSH will only authenticate
and authorise (and thus allow you to hold accountable) the individual
you've externally established the identity of and given authorisation to
access your system with a given virtual system identity. Identifying a
real individual by their e-mail address is obviously not secure (at
least not unless you've already authenticated their identity and you are
using PGP!) No amount of technical controls will protect you from
authorising (i.e. granting trust to) the wrong person! :-) Even
chrooting them in with the very stuff you're trying to protect obviously
isn't going to help any.
Now back to harp on the central issue against Justin's unnecessary patch
that he falsely claims enhances the security of cvspserver:
Whether or not you use chroot() does nothing whatsoever to increase the
security of cvspserver itself. 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!).
Though the use of chroot() with CVS is orthogonal to the security of
CVS, it may either increase or decrease the overall security of the
server hosting CVS depending on how well implemented it is and how
complex the resulting chroot environment is, and of course what other
threats the rest of the system faces, and what other vulnerabilities the
rest of the system might suffer.
Finally since chroot() can be used without modifying CVS itself at all
(by using a very simple already discussed wrapper that will not be at
anywhere near the same level of risk as is caused by modifying a large
and complex program and forcing it to run as root), adding chroot() to
cvspserver is definitely not going to increase its security, nor CVS's
security, and possibly not even the overall security of the entire
system!
--
Greg A. Woods
+1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> <robohack!woods>
Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]>
