[dm-crypt] concurrency

[dm-crypt] concurrency

[Hugh Bragg]

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?

Re: [dm-crypt] concurrency

[Arno Wagner]

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

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

Re: [dm-crypt] concurrency

[Hugh Bragg]

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

Re: [dm-crypt] concurrency

[Arno Wagner]

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

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

Re: [dm-crypt] concurrency

[Hugh Bragg]

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

Re: [dm-crypt] concurrency

[Arno Wagner]

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.

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.

> 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



> 
> 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
> 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

Re: [dm-crypt] concurrency

[Hugh Bragg]

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@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
>> _______________________________________________
>> dm-crypt mailing list
>> dm-crypt@saout.de
>> http://www.saout.de/mailman/listinfo/dm-crypt

Re: [dm-crypt] concurrency

[Milan Broz]

Hi,

On 03/27/2016 01:53 AM, Hugh Bragg wrote:
...
> 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.

As Arno said, dm-crypt cannot be used this way - it is not designed
to provide shared block device among servers.

On top what already mentioned, probably some combination with mechanism
to share active/active block device could work (maybe DRBD) but such
solution is quite fragile.

But there is another problem with your solution - you said that you
do not want decrypted data on the wire.

While accessing encrypted device (dmcrypt/LUKS) this simple way
will put encrypted data over your network, this solution is
NOT secure.

Anyone can use reply attack and just replace old ciphertext content
(some old already-seen data) in packets.
(Imagine it is as a snapshot of the encrypted device in time.)

You have to use encrypted network connection on top of this (SSH, VPN, ...)
to provide secure transport layer here.

Just sharing encrypted disk device over network (even if it is just
through point-to-point using iSCSI, NBD whatever) is simply not secure!

Milan

Re: [dm-crypt] concurrency

[Michael Kjörling]

On 27 Mar 2016 00:50 +1000, from hughbragg@dodo.com.au (Hugh Bragg):
> 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.

As a thought experiment, try removing LUKS from the equation. For the
purposes of what you seem to be asking, LUKS is just a part of the
physical storage layer.

Instead of [unencrypted physical storage device + LUKS container]
providing the feature "encrypted storage of user-selected data",
consider the case [self-encrypting physical storage device] which
provides the same feature "encrypted storage of user-selected data"
but this time without involving LUKS or dm-crypt.

_Would you expect what you have in mind to work after making that
single change?_

If not, then there is no reason to expect it to suddenly start working
when you introduce an additional component (LUKS) into the _physical_
storage stack. And as far as the file system is concerned, LUKS very
much _is_ a part of the physical storage stack. (There would be
nothing _architecturally_ weird with a HBA that itself runs LUKS and
exposes the decrypted container while writing the encrypted data to
the actual physical storage device. It would come with some fairly
serious design challenges if one wants to make it secure, however.)

-- 
Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)

Re: [dm-crypt] concurrency

[Hugh Bragg]

On 28/03/2016 2:52 AM, Michael Kjörling wrote:
> On 27 Mar 2016 00:50 +1000, from hughbragg@dodo.com.au (Hugh Bragg):
>> 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.
> As a thought experiment, try removing LUKS from the equation. For the
> purposes of what you seem to be asking, LUKS is just a part of the
> physical storage layer.
>
> Instead of [unencrypted physical storage device + LUKS container]
> providing the feature "encrypted storage of user-selected data",
> consider the case [self-encrypting physical storage device] which
> provides the same feature "encrypted storage of user-selected data"
> but this time without involving LUKS or dm-crypt.
>
> _Would you expect what you have in mind to work after making that
> single change?_
Yes, in the case of virtualbox storage, if the disk was self encrypting
it would work.
Sounds interesting. Are there any opensource tools that can do this? I
was expecting lvm on luks on a virtual disk to do this, but it failed.
For network shares, this wouldn't be any good. I wouldn't want to store
the key on the cloud server.
> If not, then there is no reason to expect it to suddenly start working
> when you introduce an additional component (LUKS) into the _physical_
> storage stack. And as far as the file system is concerned, LUKS very
> much _is_ a part of the physical storage stack. (There would be
> nothing _architecturally_ weird with a HBA that itself runs LUKS and
> exposes the decrypted container while writing the encrypted data to
> the actual physical storage device. It would come with some fairly
> serious design challenges if one wants to make it secure, however.)
>