* Hello everyone. I am lurking on this list for quite some time
now, and it is pretty sad to watch stuff like this costing
so much time and energy for everyone.
Nasser,
Erase "notepad.exe" (or maybe "notepad.com" - I would
never guess) in the machine you intend to deploy SVN on.
Rest assured that will make your server perfectly secure
this way.
Dassi, Nasser wrote:
>Because.
>
>Wouldn't it be nice to not blame the OS for everything? Wouldn't it be
>nice if write access was not the *only* way to cause havoc to an
>oh-so-precious version control solution?
>
>If manual manipulation of a physical compact disc is required to render
>the integrity of the data stored on said CD useless, then would it not
>be a similarly reassuring experience to know that the integrity of the
>version control history can only be manipulated in a couple of ways
>(i.e. destroyed disk drive, reformatting the entire disk drive, or a
>root superuser deleting the *entire* repository).
>
>But plain "write" access should not mean "oh well, integrity goes
>bye-bye" on any kind of data. If write access to the repository were
>*only* permitted and achieveable through the Subversion application, and
>not just Notepad, then that already mitigates the basic worries of
>Repository Data Integrity.
>
>**IMPORTANT**
>Instead, Subversion should create a XXX.1 file to enumerate the number
>of times a specific number was attained (if the original XXX file still
>exists). This would at the very least disallow overtly LOSING any data
>directly (because SVN overwrites the XXX file right now in an FSFS
>backend).
>
>At the very least the revision counter should not get so easily
>adjusted. In all honesty, data integrity should not get jeopardized by
>opening Notepad!
>
>Nasser Dassi
>Sr. Technical Programmer
>=========================================
>E: ndassi@141xm.com
>=========================================
>
>-----Original Message-----
>From: Sean Laurent [mailto:sean@neuronfarm.com]
>Sent: Wednesday, January 26, 2005 5:35 PM
>To: users@subversion.tigris.org
>Subject: Re: Bug? FSFS revision control
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On Wednesday 26 January 2005 04:10 pm, Dassi, Nasser wrote:
>
>
>>>>There are several ways; and giving up so easily is extremely *bad*
>>>>practice. Making a hacker think a few minutes is better than just
>>>>giving them the answer without a blink.
>>>>
>>>>
>>>1) The best way to do that is to secure the server itself.
>>>
>>>2) Security through obfuscation does not work.
>>>
>>>
>>Security through negligence works less than through obfuscation.
>>
>>Ironically, negligence carries a greater legal penalty than
>>obfuscation!!!
>>
>>
>
>I guess I'm just not seeing how modifying the FSFS backend would
>actually
>help.
>
>Let's assume an malicious user gains unauthorized access to a server.
>Perhaps
>the exploited a security hole that allowed them to run a script as an
>arbitrary user. Perhaps they cracked a user's password or worse yet,
>the
>root password. It doesn't really matter.
>
>If the hacker has write access to the Subversion repository and they
>want to
>cause harm, why would they bother to edit the revision history? As Toby
>
>Johnson already pointed out, if a user has write access to the
>repository,
>they could destroy the entire repository!
>
>The best way to prevent this is to use the existing OS access controls,
>secure
>the repository directories and restrict access to them. Why add a level
>of
>complexity to Subversion that won't help solve the problem?
>
>- -Sean
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.4 (GNU/Linux)
>
>iD8DBQFB+Br2zBEkVQQ0ejkRAiHCAKCWpS9UqiQhrm+TnybOq1ZniLeMPgCfbYxl
>9m0Ezg8Sv81dEa2nsUYUdpk=
>=UktE
>-----END PGP SIGNATURE-----
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: users-help@subversion.tigris.org
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: users-help@subversion.tigris.org
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jan 28 16:01:28 2005