[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: CM Security - introducing myself...

From: Martin v. L÷wis <martin_at_v.loewis.de>
Date: 2003-06-20 20:19:09 CEST

Bob Aiello <clearcaseguru@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
Received on Fri Jun 20 20:20:22 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.