On 28/03/2016 1:49 AM, Arno Wagner wrote: > On Sun, Mar 27, 2016 at 10:31:36 CEST, Hugh Bragg wrote: >> 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. > You misunderstand: While this would be useful, it is not possible. > Disk encryption has a different protection model that is, as Milan > pointed out, not secure when you share the encrypted disk over the > net. Disk encryption protects against an attacker that has access > to the encrypted disk once and the assumption is that the user > noticed that (laptop stolen, e.g.). When you put it over the net, > the attacker has access multiple times and things are not secure > anymore. It's not quite accurate to say it's not possible. Actually it is possible, it's just not very secure on its own, just like a stolen laptop. Existing applications such as Lastpass achieve a great result by keeping the key locally, using secure transfers for data and only storing encrypted data on the server storage system. > For example, SSH, OpenVPN, SSL, TLS, etc. all need to use different > encryption keys for each session in order to be secure. When you > share an encrypted block device, the key is alwasy the same and > has to be. Hence you need to tunnel the date over secure _network_ > encryption anyways. Naturally, network communications are best encrypted. A task well suited to those tools. Disk encryption shouldn't worry about such things as they are a modular component. They should also not be concerned with caching either, a task more suited to disks drivers, filesystems and applications. >> 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. > I don't know CryFs, but I know Joern Mueller-Quade and from him > I would expect the design will be good. However the actual thesis > supervisor is Jochen Rill, and I do not know him at all. > > From a very brief look at the thesis, I see that they are using > version counters (Sections 7.2.2 and 4.4.1), however I fail to > find that version counter in Table 5.2 or anywhere else for that > matter. From this and other indicators I conclude that this is > primarily a theoretical work and that while the theory is possibly > good, the implementation is at the very least shoddily described > and may not be good. > > Regards, > Arno > Yes, optimistic locking would work well in combination with something to handle contention for large files. Thanks Arno. It's good to touch base on this with someone and helps to clarify my goals. > >> 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@xxxxxxxx >>>>>> http://www.saout.de/mailman/listinfo/dm-crypt >>>> _______________________________________________ >>>> dm-crypt mailing list >>>> dm-crypt@xxxxxxxx >>>> http://www.saout.de/mailman/listinfo/dm-crypt >> _______________________________________________ >> dm-crypt mailing list >> dm-crypt@xxxxxxxx >> http://www.saout.de/mailman/listinfo/dm-crypt _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
