You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Jerry Haltom <wa...@larvalstage.net> on 2003/08/11 17:15:59 UTC
Re: Protection from ROOT
I suspose basic crytpgraphy comes into play here. If the encrypted data
exists on a box, and the box must read from that data, as it would have
to in order to access it. Then understandably the key itself must exist
on the system. Accordingly, somebody who owns the system has access to
all of that. End of story!
On Tue, 2003-08-12 at 04:15, Richard in Public wrote:
> Hi
>
> I've just set up a Virtual Private Server to centralize personal and
> business info. I plan to use Subversion as my repository. My one
> concern is that, being a VPS, it is possible for my service provider to
> access my files. I don't expect this of course, but I'd be much more
> comfortable if I could encrypt sensitive information. Is it possible to
> have Subversion (or the BerkleyDB configured to) encrypt the data that
> it stores? I'm assuming that the SSL stuff is only useful for
> protecting against data in transfer.
>
> Thanks,
>
> Richard Hoberman
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
--
Jerry Haltom
Feedback Plus, Inc.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Protection from ROOT
Posted by Jack Repenning <jr...@collab.net>.
At 12:15 PM -0500 8/11/03, Jerry Haltom wrote:
>I suspose basic crytpgraphy comes into play here. If the encrypted data
>exists on a box, and the box must read from that data, as it would have
>to in order to access it. Then understandably the key itself must exist
>on the system.
It is usual to work around this problem by having the user provide
the key at runtime. Or the key that decrypts the keyring, or some
level of indirection.
But even if the key is stored on the server, it can be stored in some
"obscure" form. This is not infinitely secure, but then nothing is
(that, too, is basic cryptography, isn't it?). Obfuscated key
storage does significantly raise the level of attack necessary, and
at the least, can cross things over some line that allows
non-technical protections to come into play (i.e., lawyers and
contracts).
But no, I don't think we can do this today ;-)
--
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835-8090
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Protection from ROOT
Posted by Florin Iucha <fl...@iucha.net>.
On Tue, Aug 12, 2003 at 01:02:06AM +0300, lamikr_mdk wrote:
> Florin Iucha wrote:
> >The root on you box can sniff all incoming/outgoing packets. He has
> >access to the stored data. He can do what he wants, and you won't even
> >know it!
>
> How about adding some unique attributes inside messages sent between
> client and server. Root could not steal them because the data send in
> and out would be crypted by the ssh.
And how do you know ssh is not trojaned?
> >Root can install a trojaned subversion.
>
> Is it any change to sign the application running in the server?
How do you know you are talking with the signed app?
> Hmm, you
> are right, I do not have any idea how to do that. Not sure whether using
> a similar kind of idea than in the XBoxes which requires applications
> running to be signed with a certain key, would save from the hostile
> root. (So that we could somehow check that the plugin application we are
> running in the server is ok version)
>
> >Root can scrub a key from the memory, or from the swap.
> >
> >Root can load a trojaned block device.
> >
> >Root can run your application under a debugger.
> >
> >If there is some hope is in compartimentalization at the OS level. I
> >am not sure how you can enforce that remotely...
>
> I must confess that I do not either. Especially swap and memory are hard
> to protect. But this is interesting and fun topic... I need some time to
> think just for fun.
Read Bruce Schneier's books, "Secrets and Lies" and "Applied Cryptography".
Cheers,
florin
--
Don't question authority: they don't know it either!
Re: Protection from ROOT
Posted by lamikr_mdk <la...@aragorn.kortex.jyu.fi>.
Florin Iucha wrote:
> STFW: man-in-the-middle
>
> The root on you box can sniff all incoming/outgoing packets. He has
> access to the stored data. He can do what he wants, and you won't even
> know it!
How about adding some unique attributes inside messages sent between
client and server. Root could not steal them because the data send in
and out would be crypted by the ssh.
> Root can install a trojaned subversion.
Is it any change to sign the application running in the server? Hmm, you
are right, I do not have any idea how to do that. Not sure whether using
a similar kind of idea than in the XBoxes which requires applications
running to be signed with a certain key, would save from the hostile
root. (So that we could somehow check that the plugin application we are
running in the server is ok version)
> Root can scrub a key from the memory, or from the swap.
>
> Root can load a trojaned block device.
>
> Root can run your application under a debugger.
>
> If there is some hope is in compartimentalization at the OS level. I
> am not sure how you can enforce that remotely...
I must confess that I do not either. Especially swap and memory are hard
to protect. But this is interesting and fun topic... I need some time to
think just for fun.
Mika
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Protection from ROOT
Posted by Florin Iucha <fl...@iucha.net>.
STFW: man-in-the-middle
The root on you box can sniff all incoming/outgoing packets. He has
access to the stored data. He can do what he wants, and you won't even
know it!
Root can install a trojaned subversion.
Root can scrub a key from the memory, or from the swap.
Root can load a trojaned block device.
Root can run your application under a debugger.
If there is some hope is in compartimentalization at the OS level. I
am not sure how you can enforce that remotely...
Cheers,
florin
On Mon, Aug 11, 2003 at 08:37:43PM +0300, lamikr_mdk wrote:
> I think that is not neccessary true. How about following sequence?
>
> A) Saving data
> --------------
> 1) You connect to the server with ssh kind connection --> Data between
> client and your server is crypted.
> 2) You transfer some data to the application over ssh secured crypto
> pipe to the subversion crypto-plugin.
> 3) Subversion crypto-plugin crypts the data immediately with your
> asymmetric public key to the servers database. (Data can be decrypted
> only with your private key)
>
> B) Retrieving data
> ------------------
> 1) You connect to the server with ssh kind connection --> Data between
> client and your server is crypted.
> 2) You pass your private key for the subversion plugin over ssh secured
> crypto pipe (Ie only subversion plugin can receive information from your
> private key)
> 3) Subversion crypto plugin encryptes the data in the server by using
> your private key and sends it for you over ssh secured pipe
>
> Mika
>
>
> Jerry Haltom wrote:
> >I suspose basic crytpgraphy comes into play here. If the encrypted data
> >exists on a box, and the box must read from that data, as it would have
> >to in order to access it. Then understandably the key itself must exist
> >on the system. Accordingly, somebody who owns the system has access to
> >all of that. End of story!
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
--
Don't question authority: they don't know it either!
Re: Protection from ROOT
Posted by lamikr_mdk <la...@aragorn.kortex.jyu.fi>.
Yes something like this it should happen.
Unfortunately I do not know is there plugins available :-(
I have just subscriped to this mailing list in order to find out more
from the subversion. (Wondering whether it is stable enought that I
could but my project under it.)
Does anybody know does there exist any library/framework supporting the
secure authentication schema described below. (In addition I think it
would need a somekind of time label crypted inside the authentication
message)
Mika
Richard in Public wrote:
> This is exactly the sort of sequence that I had in mind... does this
> Subversion crypto-plugin exist? Searching Google, Subversion dev/user
> mail archives and the Subversion Guide reveal nothing. Would love to
> hear more!
>
> I'm also trying to figure out whether the encryption stage could be
> handled outside svn. Obviously, this means that all data is binary from
> an efficiency point of view - I'm guessing that minor pre-encryption
> changes became big post-encryption changes, causing large deltas?
>
> I'd have to do merging outside too, but that's not a big problem. Any
> obvious problems with this approach?
>
> lamikr_mdk wrote:
>
>> I think that is not neccessary true. How about following sequence?
>>
>> A) Saving data
>> --------------
>> 1) You connect to the server with ssh kind connection --> Data between
>> client and your server is crypted.
>> 2) You transfer some data to the application over ssh secured crypto
>> pipe to the subversion crypto-plugin.
>> 3) Subversion crypto-plugin crypts the data immediately with your
>> asymmetric public key to the servers database. (Data can be decrypted
>> only with your private key)
>>
>> B) Retrieving data
>> ------------------
>> 1) You connect to the server with ssh kind connection --> Data between
>> client and your server is crypted.
>> 2) You pass your private key for the subversion plugin over ssh
>> secured crypto pipe (Ie only subversion plugin can receive information
>> from your private key)
>> 3) Subversion crypto plugin encryptes the data in the server by using
>> your private key and sends it for you over ssh secured pipe
>>
>> Mika
>>
>>
>> Jerry Haltom wrote:
>>
>>> I suspose basic crytpgraphy comes into play here. If the encrypted data
>>> exists on a box, and the box must read from that data, as it would have
>>> to in order to access it. Then understandably the key itself must exist
>>> on the system. Accordingly, somebody who owns the system has access to
>>> all of that. End of story!
>>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
Re: Protection from ROOT
Posted by lamikr_mdk <la...@aragorn.kortex.jyu.fi>.
I think that is not neccessary true. How about following sequence?
A) Saving data
--------------
1) You connect to the server with ssh kind connection --> Data between
client and your server is crypted.
2) You transfer some data to the application over ssh secured crypto
pipe to the subversion crypto-plugin.
3) Subversion crypto-plugin crypts the data immediately with your
asymmetric public key to the servers database. (Data can be decrypted
only with your private key)
B) Retrieving data
------------------
1) You connect to the server with ssh kind connection --> Data between
client and your server is crypted.
2) You pass your private key for the subversion plugin over ssh secured
crypto pipe (Ie only subversion plugin can receive information from your
private key)
3) Subversion crypto plugin encryptes the data in the server by using
your private key and sends it for you over ssh secured pipe
Mika
Jerry Haltom wrote:
> I suspose basic crytpgraphy comes into play here. If the encrypted data
> exists on a box, and the box must read from that data, as it would have
> to in order to access it. Then understandably the key itself must exist
> on the system. Accordingly, somebody who owns the system has access to
> all of that. End of story!
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org