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" <ghudson@MIT.EDU>
To: "Bob Aiello" <raiello@acm.org>
Cc: <dev@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
Received on Fri Jun 20 13:43:10 2003