First, a question: How would you get this chroot wrapper to work? You
stated yourself that when using chroot, you must include the entire
functionality of the envionment into the program that sets up the environment.
You claimed in the strongest possible terms that placing executable files
within the chroot environment was evil, and yet you must have something for
the wrapper to execute after the chroot has been completed. You also stated
in the strongest possible terms that the thing that does the chrooting must
be as simple as possible, so as to provide most secure target for attack.
There seems to be a paradox in here somewhere, and I'd like to know how you
would propose to clear that up.
Second, a statement: Greg, you have a history of assuming that everyone's
requirements precisely match your own, even if they don't know it. As a
result, you fail to acknowledge the validity of additional requirements that
you don't share, and you impose your own when they're not appropriate. This
entire discussion is a prime example where you failed to understand Justin's
requirements, or you dismissed them as being unreal. You would do very well
to pay more attention to what people are saying and asking, and to use
diplomacy when posing technical challenges to their requirements or
implementations. It would also be of great benefit to the rest of us if you
recognize when you're at odds with people who have vastly different views of
the world than you, accept the disagreement, and actually offer advice to
meet some requirement that they understand much better than you do.
I happen to believe that a chroot capability has value when protecting a
repository regardless of how access is granted. The reason for this is
that, when done right, it offers a smaller and more controllable (for me)
target for the attacker. Never mind that it can't prevent or deflect all
attacks; nothing can. But it is one more weapon in the arsenal of the good
guys, and you have no valid reason to try to defeat it (provided it's
supplied as an option).
>--- Forwarded mail from [EMAIL PROTECTED]
>[ 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!
>--- End of forwarded message from [EMAIL PROTECTED]
