From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from extdelivery1.dodo.com.au (extdelivery1.dodo.com.au [123.2.6.232]) by mail.server123.net (Postfix) with ESMTP for ; Sun, 27 Mar 2016 10:32:29 +0200 (CEST) Received: from extspam1.internal (extspam1.internal [10.20.4.14]) by extdelivery1.dodo.com.au (Postfix) with ESMTP id 6757023437 for ; Sun, 27 Mar 2016 19:32:26 +1100 (AEDT) Received: from extrelay1.dodo.com.au (extrelay1.internal [10.20.4.24]) by extspam1.internal (Postfix) with ESMTP id 8C6AA21F48 for ; Sun, 27 Mar 2016 19:32:03 +1100 (AEDT) Received: from hjbmx.ddns.net (101.106.150.122.sta.dodo.net.au [122.150.106.101]) by extrelay1.dodo.com.au (Postfix) with ESMTP id 61EEE20D08 for ; Sun, 27 Mar 2016 19:32:03 +1100 (AEDT) Received: from [192.168.0.100] (hjb.ddns.net [192.168.0.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by hjbmx.ddns.net (Postfix) with ESMTPSA id 1997D1C0F7C for ; Sun, 27 Mar 2016 18:32:03 +1000 (AEST) References: <56F6A1A2.4050805@dodo.com.au> <20160326200610.GA6499@tansi.org> <56F72F01.7020504@dodo.com.au> <20160327043355.GA10955@tansi.org> From: Hugh Bragg Message-ID: <56F79A68.8060904@dodo.com.au> Date: Sun, 27 Mar 2016 18:31:36 +1000 MIME-Version: 1.0 In-Reply-To: <20160327043355.GA10955@tansi.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [dm-crypt] concurrency List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de Thanks again for the feedback. I take you points. Actually neither virtualbox shareable disk nor shared folder are on any network so that wouldn't be a problem in those cases. In the other case of an actual network share, I see no reason why the data couldn't be shared if it was implemented to do so. ie. Decrypt/Encrypt as the point of use and always flush data immediately. It's a pity it isn't as in the new world of cloud storage, this would be very useful. I'd thought this would be obvious these days. I've seen a few solutions, but they're all proprietary and non-standard or poorly maintained. I'm investigating CryFs now, but it's non standard. encfs is good if the maintainers were more active. Hugh On 27/03/2016 2:33 PM, Arno Wagner wrote: > Hi Hugh, > > quite frankly, what you are doing is likely to corrupt your > filesystem beyond recovery pretty fast. It will also corrupt > data. Filesystems are _not_ designed to have changes on the > underlying block-layer without being notified. The only case > where this is safe is a read-only filesystem. You are tampering > with the fundamental assumptions the filesystem-designers > have to make. > > If you want a filesystem that is not read-only to be visible > in several places, you need to distribute it at or above the > filesystem layer. Nothing else works. > > That said, depending on your use-case, there may be options. > One is a read-only export and a different mechanism for > updates. You could tunnel NFS over OpenVPN or SSH or the like. > You may also be able to use rsync/rdiff-backup or even SVN > or git to synchronize data. > > But putting the raw, LUKS-encrypted block device out there, > mapping it in different machines and and then mounting > read-write it is not a viable solution and cannot be one. > Sorry. This is a case where security takes some effort that > cannot be avoided. > > Regards, > Arno > > > > > On Sun, Mar 27, 2016 at 01:53:21 CET, Hugh Bragg wrote: >> Hi Arno, >> >> Thanks very much for taking time to respond Arno. >> You're right. I'm sharing a virtual disk and trying to decrypt and mount >> that in multiple locations. >> The other thing I tried was mounting a disk image on a virtualbox shared >> folder. >> >> I don't want to need a dedicated server to deliver a decrypted >> filesystem because I don't want the decrypted data to be exposed to the >> network. I understand I could use secure communications, but this is all >> way too much overhead compared to what I'm trying to achieve. >> >> >From your response I gather that the answer is no, It doesn't support >> sharing of the raw block device with concurrent mounting. >> Is this just due to implementation or are there functional reason why >> this is so? >> >> I've been trying encfs and ecryptfs too, but they suffer from security >> and functional deficiencies. >> Is there some other solution that does support this setup? >> >> Thanks, >> Hugh >> >> On 27/03/2016 6:06 AM, Arno Wagner wrote: >>> Hi, >>> >>> in order to have a shared filesystem work, you need, well, >>> a shared filesystem! Do not under any circumstances share >>> the block-device or the LUKS-remapped decrypted block >>> device. I suspect you do soemthing like that, because >>> otherwise the question would not even arise. >>> >>> The rigth way to do this is >>> raw-block-device -> LUKS decrypted block device -> Filesystem >>> -> export of that filesystem, e.g. via NFS. >>> >>> (last two steps possibly one with other network filesystyems) >>> >>> Of course, NFS (or the network filesystem of your choice) >>> has some transactional assurances and is missing others. >>> For example, on NFS, nothing is atomic, except locks >>> or rename operation (as far as I remember). >>> >>> But if you do follow the right layering, what you have is >>> not a LUKS problem at all, but something stemming from the >>> filesystem layer and possibly wrong assumptions about the >>> assurances it offers. >>> >>> Regards, >>> Arno >>> >>> >>> >>> On Sat, Mar 26, 2016 at 15:50:10 CET, Hugh Bragg wrote: >>>> Should I be able to use Luks concurrently on a shared filesystem from >>>> different computers? >>>> Attempts so far have failed with writes not being seen from the other >>>> computer until both computers remount the filesystem or reboot. >>>> Specifically, virtualbox shareable disks and shared folders, but >>>> potentially, any nfs/cloud storage. >>>> >>>> Am I missing something or is there another tool for this case? >>>> _______________________________________________ >>>> dm-crypt mailing list >>>> dm-crypt@saout.de >>>> http://www.saout.de/mailman/listinfo/dm-crypt >> _______________________________________________ >> dm-crypt mailing list >> dm-crypt@saout.de >> http://www.saout.de/mailman/listinfo/dm-crypt