info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ANN: cvssh - secure ext-to-pserver bridge


From: David A. Desrosiers
Subject: Re: ANN: cvssh - secure ext-to-pserver bridge
Date: Fri, 22 Feb 2002 05:46:34 -0800 (PST)

> You must only sync it in the other direction -- i.e. update the
> read-only server _from_ the master!

        Great, then once again, you make absolutely no sense.

        If I have a copy of the master, which allows anonymous read-only
access, and that copy also accepts authenticated commits (via whatever
solution you're asserting will replace a pserver implementation), and I
always push the master onto the copy, all commits are lost. Nope, not an
option.

> Sorry, but if you want any security for commit access whatsoever then
> you MUST assign unique individual system accounts to every authorised
> user.

        This is not security. Repeat that slowly to yourself. If I give
thousands of local unix-based accounts on machines to developers in Germany,
Sweden, Australia, Singapore, etc. to developers who have projects on the
server.. developers I've never met in person (nor probably never will meet
in person), how can I be sure they are the _ONLY_ person that uses their
computer? How can I be sure _THEY_ know how to secure their password,
network, credentials, directory permissions, keys? The answer is that you
can't be.

        If you can't control remote access, you must control it locally.
Using local unix-based accounts punches a _HUGE_ hole in your
otherwise-secure environment. You might as well use a shared account, and
put the username and password on your homepage.

> Accountability is one of the three primary components of security.  You
> cannot have security without having accountability.

        And handing local unix accounts to remote users you don't know
removes accountability. Next?

> I don't think you are, to put it bluntly.  You've been spouting so many
> misconceptions and falsities that I wouldn't trust you within 100 yards
> of a root password for any system I cared about.

        Well, I haven't yet seen one single plausible and functional
solution come from your direction regarding _SOLVING_ this issue you assert
exists. You have strong opinions about security, but the processes you're
suggesting people implement do more to break down security, than do to hole
it up.

        Point me to a HOWTO, some reference, something that shows
step-by-step how to implement what you're suggesting, without giving away
local accounts. Creating thousands and hundreds of thousands of local user
accounts on a system _DOES NOT SCALE_, and for each new one added,
exponentially adds even more points of failure due to pontential insecure
remote networks and machines connecting to your services.

> That's pure and simple BS.  Sourceforge uses only SSH and they have tens
> of thousands of users, if not hundreds of thousands.  Certainly it
> scales.

        Funny, they've also got it wrong, and have been hacked 6 times
_BECAUSE_ they use ssh. And, because they use shared authentication (LDAP,
last I knew) the users who have accounts on one machine have accounts on all
machines.. which is how linux.com, themes.org, and other VA domains were
simultaneously hacked by compromising accounts.

        It's _EXACTLY_ the SourceForge implementation I'm avoiding.



/d





reply via email to

[Prev in Thread] Current Thread [Next in Thread]