On Fri, Aug 11, 2000 at 03:07:06AM -0400, Greg A. Woods wrote:
> > 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!
Because it's the chroot() that allows you to not give out shells. First,
you can just not have bin/sh in there if you don't do anything fancy in
your CVSROOT/*info files. Second, if you do fancy stuff, you can at least
limit the attackers shell to being confined within that CVSROOT.
> > 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!
There is no subtle difference in the way authorization is done. The only
difference is that login has been debugged a lot better than any code
I'm likely to write.
There's also nothing in the filesystem that makes use of anything in /etc,
the filesystem has no knowledge of /etc/passwd or any other file on the
system. I thought you understood Unix.
> 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.
This much is true. I'm willing to accept this much risk. But stop with
the silly and wrong statements that the filesystem somehow has special
magic knowledge of something.
> SSH leaves no room for this kind of exploit.
Less room for this kind of exploit you mean. I agree that it's much less.
But then, we've all already agreed that authentication isn't such a big
deal as you keep claiming it is.
And the risk that I'll be attacked by a bug in the auth code is much less
than the risk that I'll be attacked by a properly authorized user.
Justin
