Re: CVS woes: .cvspass
[ On Friday, August 6, 2004 at 19:27:57 (+0300), Delian Krustev wrote: ]
> Subject: Re: CVS woes: .cvspass
>
> Your mails are getting longer and longer. Please try saying more
> in less words next time. Thank You.
Unfortunately it seems I have to be very careful and very explicit with
my words or else you evidently misunderstand what I am trying to say. :-)
I.e. the more words I use the less likely you are to misinterpret them,
assuming you do read them all quite carefully. ;-)
> There's nothing like "fundamental security model". Not in unix/linux, nor
> in CVS. I suppose You're talking about UID/GID based security.
I'm talking about _the_ fundamental security model of unix(like)
systems. And there certainly is one -- it's quite well known and very
well documented, completely with a patent that's been signed over to the
public domain.
I don't know what _you_ might mean by the phrase "UID/GID based
security". I'm talking about the basic concepts of computing system
security and network security and how they relate to implementing a
secure CVS repository on a unix(like) system with network client/server
access.
> I'll repeat myself. Security could be guaranteed on different layers.
No, I'm sorry but you're still very wrong in this case. As I've already
tried to say two different ways already it is simply not possible to
guarantee any security whatsoever for a CVS repository using CVSpserver
by piling together different, dis-contiguous, dis-connected layers of
security on top of it. What you have proposed directly violates the,
basic, fundamental, underlying security model of all unix(like) systems.
You will be left with no accountability whatsoever.
IPsec can only be used to protect virtual circuts that might happen to
have to travel over insecure networks. However IPsec does not, and by
design cannot, have any part to play in the user-level security required
for implementing a secure CVS repository. Even using host-based IPsec
and making the assumption that each user can be uniquely identified by
the client host he or she is connecting from there's still no
accountability for those user's actions on the server side when some
poor afterthought of a hack like CVSpserver is used.
SSH can also be used to provide the same level of protection, with the
added fact that SSH integrates directly into the security model of the
underlying system and thus no other security mechanisms such as those
used by RSH are needed to use SSH with CVS (or rather SSH already
incorporates those security mechanisms within itself). However SSH
relies on the fact that in a secure environment every user will have a
unique system identity just as would be done if CVS were used on a
standalone non-networked secure multi-user system.
> The local access to the repository requires each commiter to have direct
> r/w access to each of the directories inside the repository. This gives
> him the power to compromise it in anyway he likes. The commits performed
> by locally executed cvs command are performed by creating/renaming/unlinking
> files.
Hmmm.... what you've said suggests that you need to go back and try to
understand the basic underlying security model of the system that CVS
was designed and implemented to run on top of before you consider the
implications of what I'm trying to say.
Note further that this model I'm talking about applies to many similar
applications, including but not limited in any way to other file-based
version control systems such as RCS, SCCS, TCCS, Aegis, and so on.
Indeed as you say local access to the repository is required for each
CVS user.
In some scenarios it would indeed be easy for an authorised user to go
in and mess about direclty with the repository files in order to
compromise them. However the potential for compromise that you speak of
is mitigated almost entirely by the nature of the application and how it
is used. It is after all in fact the goal of CVS to provide mediated,
shared, access to the common repository files. I won't go into how this
mitigation works as all that's important in this discussion is to point
out that it's not relevant to why IPsec does not, and cannot, do what
you suggest.
What this means though is that CVS, by design and by its implementation,
relies _entirely_ on the underlying operating system for all of its
security.
As you hint CVS is no different in how it must be viewed from a security
perspective than any text editor or compiler or spreadsheet calculator.
CVS cannot safely be made responsible for the security of the repository
any more than a text editor could be -- yet that is exactly what the
CVSpserver hack attempts to do. Any and all ways of using CVSpserver
try to turn CVS into the security application that it was not designed
to be.
Something like IPsec can only be used to provide security for the
inter-host connections that might be used to interact with a CVS
repository -- IPsec does not, and cannot, make something like CVSpserver
into a security application.
There's also a very blatant fact of history to consider:
The evidence of CVS' failings as a security application have been
splattered all over this very forum only quite recently, and it should
be clear to anyone experienced with security software who has taken even
a casual look inside of CVS that those previous compromises I refer to
are only the tip of the inevitable and proverbial iceberg that anyone
(mis)using CVSpserver is guaranteed to eventually run square into. CVS
simply cannot ever be a safe part of any security infrastructure or
application. It was not designed to do this and it was certainly not
implemented to do this. Any and all attempts to use CVSpserver and/or
other hastily cobbled together security hacks on top of the basic CVS
code are bound to fail, sometimes catastrophically, and no amount of
tweaking or auditing the CVS code will ever remove these risks
sufficiently for such use.
CVSpserver cannot, and must not under any circumstances, regardless of
whether IPsec or similar is used with it, be used for anything but
totally anonymous access to a copy of a CVS repository.
Would you make your text editor responsible for authenticating and
authorizing user accesses and accounting for their actions? Do you
think IPsec could somehow make it safe to do this with your text editor?
--
Greg A. Woods
+1 416 218-0098 VE3TCP RoboHack <woods@xxxxxxxxxxx>
Planix, Inc. <woods@xxxxxxxxxx> Secrets of the Weird <woods@xxxxxxxxx>