[ On Thursday, August 10, 2000 at 22:28:18 (-0400), Justin Wells wrote: ]
> Subject: Re: cvs-nserver and latest CVS advisory (Was: patch to make CVS chroot)
>
> On Thu, Aug 10, 2000 at 12:40:20PM -0400, Greg A. Woods wrote:
> > The current implementation of cvspserver was always fatally broken. the
> > RSH method was available right from the beginning and could just as
> > easily have been implemented in every client, easier in fact than
> > writing the current broken code.
>
> The RSH method just hands out shells on the box directly. How is that a
> good idea?
The RSH method is the stepping stone that lead to "pluggable"
authentication modules, and in the unix client that's still now it works
today.
Furthermore the RSH method ensures that nobody forgets they're
effectively granting shell access to the server (as the authenticated,
authorised, and accountable real user, of course).
Finally the RSH method does not duplicate the effort necessary to do the
authentication and authorisation, nor does it duplicate the user-name to
filesystem ID mapping (i.e. see the discussion below in my second last
paragraph).
The RSH method is perfectly secure in a private network where physical
and logical access to the network medium is under complete control of
the administrators (along with of course the IP addresses and DNS
mappings). Complete With NIS or Kerberos for sharing authentication
data and user-name to user-id mappings you've got full accountability
and strong integrity. Once upon a time these caveats were essentially
true for even the academic Internet, and indeed RSH is still secure (and
more secure than telnet!) in such an environment, even if you allow for
password sniffers. Where RSH breaks down (and where SSH is necessary)
is when you cannot control physical access to the network medium, and of
course where you have inter-nets, which are by definition under separate
and possibly competetive administrative control.
Oh, and RSH is also an extremely trivial protocol to implement, and it's
very easy to borrow code for a working implementation too!
> At least pserver can be patched so it doesn't give out shells.
So if you're not giving out shells then why are you worried about doing
the chroot() then? :-)
You've gotta keep your story straight man!
(While you may be able to patch CVS so that in the cvspserver scenario,
or indeed in a carefully crafted SSH scenario, it's ``hard'' for a user
to obtain a shell, there's no guarantee that code designed with the
assumption in mind that the user already has shell access isn't going to
be fooled into giving out a shell at some unexpected time! So if you
don't want people playing with full shell environments you do indeed
have to do things to eliminate unnecessary tools, and whether you do
that by securing the system in general, or by using chroot carefully
from an independent wrapper, is more or less irrelevant. I.e. you still
have to design your security policies (and thus the technical controls
that enforce it) under the assumption that the user will be able to gain
shell access.)
> > Nobody in their right mind, i.e. nobody who has even an ounce of
> > understanding of computer security, would ever want to avoid using real
> > system IDs for commit access.
>
> For the record I agree with this. I used real system ids with pserver.
You *think* you're using real system ids with cvspserver -- but there's
a subtle difference in the way that the authorisation is done which
means that even if you match user-ids one-for-one in CVSROOT/passwd with
/etc/passwd, you're still only creating an illusion of sameness since
nothing immutable in the system guarantees the mapping remains, and
there's certainly nothing in the filesystem that'll make it use
CVSROOT/passwd as it's authorisation table! Any time there's
duplication of effort there's room for error, and where there's room for
error in something directly related to security there's risk that
security can be compromised by exploiting that error margin.
SSH leaves no room for this kind of exploit.
--
Greg A. Woods
+1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> <robohack!woods>
Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]>
