On 21 Jun 2007, at 00:51, Michael Williams wrote:
>
>>
>
> Perhaps I'm asking the wrong question(s)? Basically I want to know
> the following:
>
> -- Can an application (regardless of OS) support encryption of all
> its activities -- disk writing, memory access, etc. without the
> need for the OS to dictate an encrypted environment?
No. The CPU has to be able to read the contents of memory locations
without having to decrypt each access individually. I don't think
it's practical to encrypt the address space of a program without
hardware support and as long as the address space of a program is
plain text, any kernel level process can read it.
>
> I realize a lot of people don't want or need this, but I would like
> it. Believe it or not, I'm not the most paranoid person on my
> team. I'm absolutely not opposed to getting my hands dirty and
> writing it myself, but I was hoping for a bit of community
> direction (technical, not personal ;))before I dove in. I really
> don't believe on-disk encryption is any less reasonable than TLS,
> SSL, or SSH encryption. Perhaps you're right, perhaps another
> application should handle it, but that would still leave SVN
> "vulnerable" and that's what I'm trying to prevent. I'm looking
> for an encrypted process from beginning to end.
Let's say that a solution acceptable to you is possible (and I could
imagine something that comes close e.g. subversion encrypts/decrypts
files as it writes/reads them). You've got to estimate how much it
is going to cost for you to implement this solution - your time is
not free. Then you've got to compare the cost of implementing your
solution to buying and hosting your own box including getting a fixed
IP address. Note that the cost of implementing your solution
includes maintenance and porting it to new releases of subversion
unless you can persuade the svn developers to accept your patch. You
might find it's cheaper to just get your own box and host it
yourself. That's what I'd do. That way you can
1) protect against theft - encrypt the file system
2) protect against remote FTP attacks - disable ftp access for the
svn user and root.
3) protect against malicious root access - you are the only one with
the root password.
There is fundamentally no way to protect against malicious
administrator access except by only employing trustworthy
administrators.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jun 21 11:52:44 2007