You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Bob Aiello <cl...@optonline.net> on 2003/06/19 03:50:49 UTC
introducing myself...
Hi,
my name is Bob and I am a Clearcase Evangelist. Ok... so I am
a "recovering Clearcase Evangelist". I am very interested in
subversion because I would like to promote a more secure
environment for future open source CM tools. I do not believe that
CVS is appropriate for use in large scale financial services
environments. I'd like to see that subversion would provide
proper security and controls.
oh by the way I wrote about these issues in this months edition
of CM Crossroads (www.cmcrossroads.com). So please let me know if
you are interested in seeing that subversion meets the security
needs of large scale financial services firms (e.g. database
security & integrity checking, audit logs that cannot be
found - let along tampered with). I can be very specific on why
I believe that CVS cannot meet these requirements today and why
I believe that Clearcase (and other major CM tools that use
a database) can provide a more secure infrastructure.
Bob
Re: Subversion and security (was Re: introducing myself...)
Posted by Brian Behlendorf <br...@collab.net>.
On Sun, 22 Jun 2003, Brad Appleton wrote:
> Hi Bob! I'm also very experienced with ClearCase. I wonder if we can
> look at the list of requests/bugs still to implement against subversion
> and the relative priority of them, and where security falls into the
> mix. My impression is that as important as security is, there are still
> many other more fundamental features subversion needs before version 1.0
> to make it "a compelling replacement for CVS" and I don't see security
> among them.
I think the others might be exhausted on this issue (or otherwise focused
on fixing defects rather than discussing new requirements), but I'd like
to re-emphasize the point made earlier that we are bandying about the term
"security" loosely here, and in the context of an SCM solution it means
many different things.
To be clear, where "security" means:
a) preventing escalations of privilege - where someone gets the right to
do what they "shouldn't", as configured
b) minimizing the opportunity for Denial of Service attacks
c) encrypting the connection between client and server using SSL as
designed (with bonus points for client-side certs)
then I think the SVN developers all have those as priorities (at least the
CN guys do).
It sounds like Bob's primary "security" examples have been around whether
a developer can do damage or change history in such a way as to change the
repository's history irreparably. This has much more to do with how
developers can touch the database than whether the database itself is
using CVS-style flat files, SVN-style DB files, or something else.
It's true that there is one way to set up the repository, ra_local, where
every developer has a Unix account and can write to the repository
(through the SVN client or otherwise) directly. Under Unix, write privs
also mean the ability to muck at low levels, or even destroy.
But through ra_svn or ra_dav, this is just not possible, if I understand
things correctly. It's even possible to guard against this with CVS, if
you configure your CVS server to not require separate Unix logins per
developer, and only allow them to connect through the CVS server.
Some of the "security" discussion also seems to be about audit-ability -
keeping a logfile to the side of all transactions then being able to
compare that logfile to the database and check that nothing was lost.
That doesn't seem to require modifications to SVN, it sounds like a matter
of copying the Berkeley DB logfiles off to another location and running
a recovery script from time to time to make sure nothing is lost.
> BTW - have you looked at what Collabnet SourceCast does for
> CVS+Bugzilla? There is also an implementation of it that works with
> ClearCase and ClearQuest. And I hear another is in the works that uses
> Subversion and Scarab. Is not SourceCast designed to address some of the
> secure viewing/accessing issues you raised?
If the issues are related to needing a better tool to manage the concept
of users, projects, and permissions across the range of tools we provide
(today, CVS and Bugzilla, soon, SVN and Scarab, with documented means of
co-existing with Clearcase and other tools) then that's what we're here
for. We've met the above network-related security requirements with CVS,
as well as preventing the types of corruption possible with Unix-local
access to CVS (which we don't allow).
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion and security (was Re: introducing myself...)
Posted by Brad Appleton <br...@bradapp.net>.
On Thu, Jun 19, 2003 at 06:16:16PM -0400, Bob Aiello wrote:
> The important goal is to spec what we all believe that subversion
> should do. So here is what I am proposing...
[...]
> I'd rather not spam this list in a debate on CVS or ClearCase security.
> I would like to know if there is interest in making subversion a world
> class CM tool that push the envelope on security as well as other features.
Hi Bob! I'm also very experienced with ClearCase. I wonder if we can look at the list of requests/bugs still to implement against subversion and the relative priority of them, and where security falls into the mix. My impression is that as important as security is, there are still many other more fundamental features subversion needs before version 1.0 to make it "a compelling replacement for CVS" and I don't see security among them.
I'm all for discussing the encapsulation and interfaces needed in the short-term to be able to "plug in" the necessary security mechanisms later with minimal impact. I think that before Subversion tries to tackle security as you suggest it needs to tackle more of things that the existing CVS userbase would require before switching from CVS to SVN, and I think security is not near the top of that list. Most of the folks using CVS today don't have (or at least don't think they have :-) the extra security features you describe, and I see SVN needing to meet those other needs first before tackling security.
Again, I'm not saying to discuss possibilities. I do think that trying to pressure or influence security functionality to be implemented in the near term would not be best aligned with the vision and goals for SVN. Now, if some kind benefactor happens to be able to provide sufficient funding/resources to devote to security features, that situation could perhaps change :-)
BTW - have you looked at what Collabnet SourceCast does for CVS+Bugzilla? There is also an implementation of it that works with ClearCase and ClearQuest. And I hear another is in the works that uses Subversion and Scarab. Is not SourceCast designed to address some of the secure viewing/accessing issues you raised?
--
Brad Appleton <br...@bradapp.net> www.bradapp.net
Software CM Patterns (www.scmpatterns.com)
Effective Teamwork, Practical Integration
"And miles to go before I sleep." -- Robert Frost
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: introducing myself...
Posted by Bob Aiello <cl...@optonline.net>.
I agree completely Karl. (I am also withholding the deep urge
to make a joke about a CVS "security" list :-)
The important goal is to spec what we all believe that subversion
should do. So here is what I am proposing...
1) History should NOT be be kept in a (single) physical
file - it should be stored as transaction records that could not
easily be located or hacked. In database CM tools the records
are scattered throughout the repository.
2) There should be a hierarchy of events (e.g. security events, "minor"
events etc.)
3) Source files (and all of their associated revisions) should also
not be single specific files. They should be persisted as
transaction
records that are scattered throughout the database.
4) There should be referential integrity across the repository. If
someone
manages to erase 2 or 3 containers then my trusty admin utilities
should flag the loss of referential integrity.
5) Many modern CM tools allow you to use common database systems.
That means that you can use their own internal tools to accomplish
many of these objectives.
I joined this group because I have a lot of experience promoting and
supporting large scale CM tools in many large financial services firms.
Recently, I critized (on CM Crossroads) CVS based CM tools as
lacking proper security and being inappropriate for use in large scale
(global) financial services firms.
The vendor (you'll never guess who it was!) suggested that I get involved
with this effort to try to influence the development of subversion from a
security perspective. I do know C++, but I suspect that my skills as
a C++ developer are not as strong as most of you (although that doesn't
mean that I won't try!). I do have a lot of experience as a Unix Admin
(on AIX/HP-UX/Linux and a little Sun). I may turn out to be more helpful
as a tester and SQA resource. I have installed and provided hands-on support
for many largescale CM tools on many environments. I have also trained a lot
of
developers. (I know what they are going to ask and what confuses new users!)
I'd rather not spam this list in a debate on CVS or ClearCase security.
I would like to know if there is interest in making subversion a world
class CM tool that push the envelope on security as well as other features.
Also if there is a better forum to propose suggested requirements - then
please let me know!
Bob
----- Original Message -----
From: <kf...@collab.net>
To: "Martin v. Löwis" <ma...@v.loewis.de>
Cc: "Bob Aiello" <ra...@acm.org>; <de...@subversion.tigris.org>
Sent: Friday, June 20, 2003 1:46 PM
Subject: Re: introducing myself...
First, welcome Bob!
Second, just a gentle reminder (not targeted at Bob, by the way) that
this is the Subversion dev list, not the CVS security list, so please
let's try keep discussions related to Subversion. I realize it's
always a judgement call, so 'nuff said.
Thanks,
-Karl
martin@v.loewis.de (Martin v. Löwis) writes:
> Bob Aiello <cl...@optonline.net> writes:
> > oh by the way I wrote about these issues in this months edition
> > of CM Crossroads (www.cmcrossroads.com).
>
> Very interesting. However, I feel that the terminology in this article
> is confusing: protection from failures and protection against attacks
> are completely indepedent issues, and I think only one of them should
> be called "security" (i.e. the protection against attacks). The other
> is better called "safety" (as in "safety belt" - not "security belt").
>
> While I can agree that CVS lacks safety (e.g. no fault tolerance, real
> risks of corrupted databases), I fail to see why you consider it
> insecure. E.g. when used over ssh, CVS provides strong
> authentication. As a revision control system, it supports auditing by
> nature. There are some operations that are not audited, but it would
> be easy enough to disable them altogether without loss of usability.
>
> About the only thing it does not provide is non-repudation.
>
> Regards,
> Martin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: introducing myself...
Posted by kf...@collab.net.
First, welcome Bob!
Second, just a gentle reminder (not targeted at Bob, by the way) that
this is the Subversion dev list, not the CVS security list, so please
let's try keep discussions related to Subversion. I realize it's
always a judgement call, so 'nuff said.
Thanks,
-Karl
martin@v.loewis.de (Martin v. Löwis) writes:
> Bob Aiello <cl...@optonline.net> writes:
> > oh by the way I wrote about these issues in this months edition
> > of CM Crossroads (www.cmcrossroads.com).
>
> Very interesting. However, I feel that the terminology in this article
> is confusing: protection from failures and protection against attacks
> are completely indepedent issues, and I think only one of them should
> be called "security" (i.e. the protection against attacks). The other
> is better called "safety" (as in "safety belt" - not "security belt").
>
> While I can agree that CVS lacks safety (e.g. no fault tolerance, real
> risks of corrupted databases), I fail to see why you consider it
> insecure. E.g. when used over ssh, CVS provides strong
> authentication. As a revision control system, it supports auditing by
> nature. There are some operations that are not audited, but it would
> be easy enough to disable them altogether without loss of usability.
>
> About the only thing it does not provide is non-repudation.
>
> Regards,
> Martin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: introducing myself...
Posted by "Martin v. Löwis" <ma...@v.loewis.de>.
Bob Aiello <cl...@optonline.net> writes:
> oh by the way I wrote about these issues in this months edition
> of CM Crossroads (www.cmcrossroads.com).
Very interesting. However, I feel that the terminology in this article
is confusing: protection from failures and protection against attacks
are completely indepedent issues, and I think only one of them should
be called "security" (i.e. the protection against attacks). The other
is better called "safety" (as in "safety belt" - not "security belt").
While I can agree that CVS lacks safety (e.g. no fault tolerance, real
risks of corrupted databases), I fail to see why you consider it
insecure. E.g. when used over ssh, CVS provides strong
authentication. As a revision control system, it supports auditing by
nature. There are some operations that are not audited, but it would
be easy enough to disable them altogether without loss of usability.
About the only thing it does not provide is non-repudation.
Regards,
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: introducing myself...
Posted by Ben Collins-Sussman <su...@collab.net>.
Bob Aiello <cl...@optonline.net> writes:
> thanks Ben. I will start working on this over the weekend.
> Do you recommend using Unix or Windows (or both) to
> get started? (Which is more mature?)
There's no difference. Subversion uses the Apache Portable Runtime
(APR) library, which is the same portability library used by Apache
httpd. So Subversion compiles and runs anywhere apache does.
But because Subversion itself only ships with a commandline client,
I'd imagine Unix is a friendlier environment for playing with such a
thing.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: introducing myself...
Posted by Bob Aiello <cl...@optonline.net>.
thanks Ben. I will start working on this over the weekend.
Do you recommend using Unix or Windows (or both) to
get started? (Which is more mature?)
Bob
----- Original Message -----
From: "Ben Collins-Sussman" <su...@collab.net>
To: "Bob Aiello" <ra...@acm.org>
Cc: <de...@subversion.tigris.org>
Sent: Friday, June 20, 2003 12:40 AM
Subject: Re: introducing myself...
> Bob Aiello <cl...@optonline.net> writes:
>
> > Hi,
> >
> > my name is Bob and I am a Clearcase Evangelist. Ok... so I am
> > a "recovering Clearcase Evangelist". I am very interested in
> > subversion because I would like to promote a more secure
> > environment for future open source CM tools. I do not believe that
> > CVS is appropriate for use in large scale financial services
> > environments. I'd like to see that subversion would provide
> > proper security and controls.
>
> Welcome, Bob. The best way to learn about Subversion is to start
> using it for real work. The 2nd best way to learn about Subversion is
> to read the book (at svnbook.red-bean.com). If you run into questions
> or problems, ask away. Once you're more familiar with Subversion, we
> can answer your questions about its design, security, etc.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: introducing myself...
Posted by Ben Collins-Sussman <su...@collab.net>.
Bob Aiello <cl...@optonline.net> writes:
> Hi,
>
> my name is Bob and I am a Clearcase Evangelist. Ok... so I am
> a "recovering Clearcase Evangelist". I am very interested in
> subversion because I would like to promote a more secure
> environment for future open source CM tools. I do not believe that
> CVS is appropriate for use in large scale financial services
> environments. I'd like to see that subversion would provide
> proper security and controls.
Welcome, Bob. The best way to learn about Subversion is to start
using it for real work. The 2nd best way to learn about Subversion is
to read the book (at svnbook.red-bean.com). If you run into questions
or problems, ask away. Once you're more familiar with Subversion, we
can answer your questions about its design, security, etc.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: openCM
Posted by Sander Striker <st...@apache.org>.
> From: Bob Aiello [mailto:clearcaseguru@optonline.net]
> Sent: Thursday, June 19, 2003 1:46 PM
> where can I find out more about openCM?
http://www.opencm.org
You could have at least tried that and Google before asking here.
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
openCM
Posted by Bob Aiello <cl...@optonline.net>.
where can I find out more about openCM?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Re:CM Security - introducing myself...
Posted by Daniel Berlin <db...@dberlin.org>.
On Fri, 20 Jun 2003, Greg Hudson wrote:
> On Thu, 2003-06-19 at 07:42, Bob Aiello wrote:
> > modern CM tools keep the audit log as transaction records in a
> > database (instead of a physical file).
> >
> > Since the only interface is via the tool itself, it is pretty darned hard to
> > audit the history log.
>
> That's all? Because the file format isn't plain ASCII, you think it's
> more secure?
>
> It only takes one mildly clueful hacker about half an hour (or a little
> more time, if they don't have a copy of the DB software to hack on) to
> write a script to modify the audit log or remove data from the
> repository, and then every two-bit script kiddie can do the same. The
> community that can developer buffer overflow attacks is not going to be
> stymied by a well-documented binary file format, or even an undocumented
> one.
Just to make this clear: A few years ago, in the space of 3 weeks in
between classes, I reverse engineered Microsoft's PDB codeview format (it
pretends to be documented but they consider it internal so they don't
give anywhere near the necessary info to do something useful with it), as
well as their entire C++ name mangling scheme, and extended GDB to be able
to handle both.
I was just bored during that time, too. It's not like anyone was paying
me.
Entire communities have grown up around modifying undocumented data files
and formats for various games. Heck, my brother, not even close to a
programmer, used to sit with a hex editor and figure out how to hack the
save files for whatever game he was playing at the moment.
This was before one had tools besides a good hex editor that you could use
on binary files, like scripting languages supporting unpack operations,
etc.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Re:CM Security - introducing myself...
Posted by Greg Hudson <gh...@MIT.EDU>.
On Thu, 2003-06-19 at 07:42, Bob Aiello wrote:
> modern CM tools keep the audit log as transaction records in a
> database (instead of a physical file).
>
> Since the only interface is via the tool itself, it is pretty darned hard to
> audit the history log.
That's all? Because the file format isn't plain ASCII, you think it's
more secure?
It only takes one mildly clueful hacker about half an hour (or a little
more time, if they don't have a copy of the DB software to hack on) to
write a script to modify the audit log or remove data from the
repository, and then every two-bit script kiddie can do the same. The
community that can developer buffer overflow attacks is not going to be
stymied by a well-documented binary file format, or even an undocumented
one.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: CM Security - introducing myself...
Posted by "Martin v. Löwis" <ma...@v.loewis.de>.
Bob Aiello <cl...@optonline.net> writes:
> modern CM tools keep the audit log as transaction records in a
> database (instead of a physical file).
>
> Since the only interface is via the tool itself, it is pretty darned hard to
> audit the history log.
This is a very strange view of the world. Merely using a database
instead of flat files does not change the security *at all*.
> With enough permissions I could edit the history
> log for CVS (based upon it's RCS files) and you would never know.
> (The same is true if you use the Unix based sudo tool.)
With enough permissions I could edit your Oracle or DB2 database file,
on disk. I don't need to go through the Oracle library - instead, I
can just edit the files that Oracly writes (if I have the permission).
> I could also remove a header file and you also would never know. If
> you did this with any of the other industry strength CM tools (assuming
> you had gotten root) the repository would crash or at least fail it's
> integrity checking utilities.
Again, this assumes I have access to the files on the disk. With
access to the files, I can trick any other industry-strength into
believing the header file was never there.
> You can "run" but you can't "hide". I believe that this is the
> appropriate level of security for large scale financial services
> firms.
I think you are grossly mistaken in your conclusion. You can "hide"
with any other CM system just as well if you can overcome OS
limitations. Heck, I could replace the CM software *itself*.
Regards,
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re:CM Security - introducing myself...
Posted by Bob Aiello <cl...@optonline.net>.
Greg,
modern CM tools keep the audit log as transaction records in a
database (instead of a physical file).
Since the only interface is via the tool itself, it is pretty darned hard to
audit the history log. With enough permissions I could edit the history
log for CVS (based upon it's RCS files) and you would never know.
(The same is true if you use the Unix based sudo tool.)
I could also remove a header file and you also would never know. If
you did this with any of the other industry strength CM tools (assuming
you had gotten root) the repository would crash or at least fail it's
integrity checking utilities. You can "run" but you can't "hide". I believe
that this is the appropriate level of security for large scale financial
services
firms. I am hoping to contribute to this project by giving input on what
is an appropriate level of security for a financial services firm, based
upon
my own experience in the industry and involvement with related
industry groups (e.g. NY CitySPIN, NYECTF etc.).
Also, I am working on a discussion forum for CM tools security on
www.cmcrossroads.com . I would envite you all to join.
Bob
----- Original Message -----
From: "Greg Hudson" <gh...@MIT.EDU>
To: "Bob Aiello" <ra...@acm.org>
Cc: <de...@subversion.tigris.org>
Sent: Friday, June 20, 2003 1:13 AM
Subject: Re: introducing myself...
> You might be interested in OpenCM. It uses signed commits and other
> cryptographic controls to ensure security properties Subversion is (so
> far) not interested in. Though I'm not sure that's the approach you
> want to take.
>
> On Wed, 2003-06-18 at 23:50, Bob Aiello wrote:
> > (e.g. database
> > security & integrity checking, audit logs that cannot be
> > found - let along tampered with).
>
> The normal approach I know about for ensuring the integrity of audit
> logs is to send them over the network to another machine. I'm kind of
> curious how else you would propose to make it impossible to find and
> tamper with audit logs.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: introducing myself...
Posted by Greg Hudson <gh...@MIT.EDU>.
You might be interested in OpenCM. It uses signed commits and other
cryptographic controls to ensure security properties Subversion is (so
far) not interested in. Though I'm not sure that's the approach you
want to take.
On Wed, 2003-06-18 at 23:50, Bob Aiello wrote:
> (e.g. database
> security & integrity checking, audit logs that cannot be
> found - let along tampered with).
The normal approach I know about for ensuring the integrity of audit
logs is to send them over the network to another machine. I'm kind of
curious how else you would propose to make it impossible to find and
tamper with audit logs.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org