Re: CVS woes: .cvspass
[ On Thursday, August 5, 2004 at 12:52:10 (+0300), Delian Krustev wrote: ]
> Subject: Re: CVS woes: .cvspass
>
> On Wednesday 04 August 2004 23:35, Greg A. Woods wrote:
> > Nope, sorry, but that's just not possible, at least not with CVS pserver.
>
> What's not possible ? Using IPSEC ?!
It's not possible to "secure" CVSpserver using IPsec. Period.
I.e. it's just not logically possible, using CVSpserver, do do what you
said could be done. To do so violates the fundamental security model of
CVS and the Unix(like) systems it runs upon.
IPsec can only secure the inter-host network links and thus make it
possible to securely use CVS via remote job protocols such as RSH (which
use host-level security techniques and assume their virtual circuits are
already secure) instead of requriring SSH. IPsec does not operate at
the user level and even if it did you'd still require unique system
identities for every individual human user.
Note that even pushing the IPsec implementation away from the host
kernel and onto a gateway router implies blindly accepting many more
assumptions about the security of the local area network.
> I'm not sure what You mean by "human user".
The whole point of security, i.e. authentication, authorisation, and
accountability, is to relate all internal system activity back to real,
verified, authorised, individual human users.
I use the common phrase "human user" to differentiate the real people
who use a system from the identities they assume, or rather are given,
inside of a computing system environment.
It is fundamental that each system account be used by one and only one
unique human user. Without this condition accountability is impossible
(at least for the users of that shared user-ID) unless it's provided by
some external means (e.g. a security guard at the door of the
Tempest-level room where the computer is located who is instructed to
securely record every access to the computer, and who is capable of
securely performing this duty).
It is also fundamental that every system activity performed by a human
user be performed using a unique-per-human _system_ level identity. If
you do not meet this condition then you are violating the fundamental
security model of the system and all bets are off, all warrantees null
and void, etc.
(note that a single human individual can assume multiple system
identities without compromising accountability -- it's only not secure
to have multiple humans assume a single system identity)
> The users in cvs doesn't have
> to be mapped to system users(CVSROOT/passwd).
That's true at some level, but it's a (common) fallacy as well, and it
begins with a faulty foundation from the get go.
CVS only works securely with real, individual, unique-per-human, system
level user-IDs, and where the CVS processes on the server run using the
system identity of the human user they are acting on behalf of.
If your human users are not using unique internal _system_ level
representations of their unique identities then you have no secure
ground to stand on in the first place.
I.e. the mere concept of using cvspserver (and thus CVSROOT/passwd) is a
non-starter if you are worried in any way about the security of your CVS
repository. CVS users (the real humans using CVS) _MUST_ use unique
system user identities in order that you can even begin to consider the
state of the security of your CVS repository. CVSROOT/passwd entries do
not equate to real system identities even if they map identically to
real system identities because use of CVSROOT/passwd in that way implies
running CVS as root and that's not secure in any way whatsoever
(i.e. not by design and not by implementation).
There are no if's, and's, or but's about it -- this is really _really_
fundamental computer security basics. CVS security, by design and by
the way CVS is implemented, relies _entirely_ on system security and
unique system level identities. Running CVS as root, or having all CVS
users access one system account by way of CVSpserver with CVS running as
that one system account, leaves CVS without any secure accountability
whatsoever, while at the same time providing numerous holes big enough
for CVS users to drive big Mac trucks through at each other, if not
indeed also through to root level compromises in the former scenario.
Like I'm sure I've said many times before, CVSpserver should never ever
be used for anything but totally anonymous (and presumably read-only)
access to a CVS repository, and hopefully that pserver accessible
repostitory is also only an untrusted copy of the real CVS repository
that the developers have write access to, and hopefully the system it
runs on has the sole purpose of providing anonymous pserver access, or
at least the identity it runs under is totally untrusted within that
system.
Let me say it again the other way around for the benefit of clarity:
Only ever use CVSpserver for totally _anonymous_ access.
> There's a site outhere. It's sf.net . They demonstrate, with the number
> of projects being hosted there (with pserver access), You're not right
> again.
They demonstrate nothing of the sort (at least not with their CVSpserver
offering).
In the scenario you speak of sf.net has no real requirement for
accountability -- their offerning using CVSpserver is effectively the
same as providing anonymous access. Sf.net doesn't care who the real
humans are in this case -- they simply do their best (which isn't always
perfect) to keep whole projects from interfering with each other. (and
their none-too-rare failings have been directly attributable to this
particular mis-use of CVS -- i.e. their "lame" attempt to use CVS as
part of their security infrastructure)
Meanwhile, IIUC, sf.net does also offer secure SSH access to systems
hosting CVS repositories and they use true system identities for eash
SSH account, and presumably with this offering there's normally one (or
maybe more) unique system accounts for every real human using this
service, though of course the responsibility of verifying the uniqueness
of system identities will be on the shoulders of the CVS project admins,
and perhaps not on sf.net themselves. I.e. if two human users share an
account there's only their peers within their project to account to and
sf.net only attempts to provide the minimum level of _system_ security
necessary for their users to police each other.
Either way sf.net is a big enough target that if they have not
implemented their services securely and within the security model
provided by their underlying systems then we'll likely hear about the
result here in this forum.
> On the other side, people's stupidity is endless. I won't be surprised
> to see private keys posted in a public forum. This, ofcourse, could
> be nothing but a reason for admiration.
No disagreement there! :-)
--
Greg A. Woods
+1 416 218-0098 VE3TCP RoboHack <woods@xxxxxxxxxxx>
Planix, Inc. <woods@xxxxxxxxxx> Secrets of the Weird <woods@xxxxxxxxx>