Version 5 Development > Roadmap
Feature Request - Encryption
Ford Prefect:
Coming to think of it, after some time with unRAID,
I came to the conclusion that the ONE feature that finally
and ultimately will convince me that unRAID is for me,
is this one.
I know this has been discussed some time ago
and that there are some solutions (encfs, wasn't it?)
to achieve this manually.
I also can remember that it was part on the previous wishlist
but it disappeared somehow?
Motivation:
- I spend too many hours to fill my unRAID box.
In case of theft, I do not want anyone to be rewarded with my hard work
(hard-ware is OK, the next generation is waiting on the shelves for me ;D).
- I need to store private, sensitive personal information and other confidential stuff from myself and from clients.
Here I can be held reliable if someone gets his/her hands on the data.
Encryption is the only way to protect data against physical brute force attacks.
(I got a laptop ripped out of my car some weeks ago...it was encrypted....but still not a good feeling).
Currently I have to integrate into a more complex setup which involves a lot
of tools...this is not a 1-2-3-finish show at the moment.
A solution integrated with unRAID definitely will be smoother.
...using an encrypted block device (LUKS?) is preferred, since I think
an encrypted filesystem could create a performance issue.
Having to enter the passphrase manually upon startup is OK, since
I am running all IPMI boards and can securely connect from anywhere
into my network via VPN.
Currently I own two Plus keys...I can see me shut down my unRAID box
and bury the keys in the near future if I cannot find a solution to this.
This feature really would make the ultimate feature for me (and hopefully
a good feature for others). It would make a good feature to make unRAID
stand out of the crowd.
best regards,
Ford
boof:
--- Quote from: Ford Prefect on June 20, 2011, 01:02:43 AM ---...using an encrypted block device (LUKS?) is preferred, since I think
an encrypted filesystem could create a performance issue.
--- End quote ---
Have you tried encfs?
You're right in that it's not very performant (compared to block level) though if you do not use it in conjunction with unraids user shares (i.e avoid two layers of fuse) then performance isn't too bad.
You can try encfs quite easily at any time so you should be able to happily see if it will suit.
This would fix your problem in a minute. You could also look at only encrypting parts of your data (i.e your private data) which would also lower the performance penalties.
Failing that, bin unraid and go back to a standard linux distribution with dmcrypt / LUKS and look at something like flexraid or snapraid to help achieve some level of fault tolerance.
Even if encryption were on the cards in unraid I suspect you would be waiting quite a while for it to become a stable feature.
Ford Prefect:
thanks for sharing your thoughts on this one!
--- Quote from: boof on June 20, 2011, 02:12:55 AM ---
Have you tried encfs?
You're right in that it's not very performant (compared to block level) though if you do not use it in conjunction with unraids user shares (i.e avoid two layers of fuse) then performance isn't too bad.
--- End quote ---
No I did not, because of the very reason that I'd like to keep using user shares but without the penalty of nested fuse filesystems.
--- Quote ---Failing that, bin unraid and go back to a standard linux distribution with dmcrypt / LUKS and look at something like flexraid or snapraid to help achieve some level of fault tolerance.
--- End quote ---
Yes, I know...but this is what I want to avoid.
My first idea was to run dm_crypt/LUKS on a VM host and pass the de-crypted block devices to an unraid-VM, like with a KVM host.
Couldn't get it to run because of lack of drivers in unRAID and hard-coded block device-schemes in emhttp.
Qemu announced a whitepaper on virtio_scsi which would allow for scsci_passtrough. A custom kernel should do the trick by then.
--- Quote ---Even if encryption were on the cards in unraid I suspect you would be waiting quite a while for it to become a stable feature.
--- End quote ---
encryption IS a stable feature in linux...it is the lack of proper integration of architectures from unRAID and linux kernel.
for example nested block devices with dm_mod and md modules are no problem in vanilly linux.
It should be possible with unRAID-md module as well, but I think emhttp is again the problem with the need to access a physical layer.
boof:
--- Quote from: Ford Prefect on June 21, 2011, 01:25:54 AM ---No I did not, because of the very reason that I'd like to keep using user shares but without the penalty of nested fuse filesystems.
--- End quote ---
I can only suggest to try it and see what happens. I see around 20 megabytes per second writes and 30-40 reads throughput via encfs living on top of a user share. Not brilliant but not the end of the world either. Will entirely come down to your usage patterns I guess as well as (to a more limited extent) your cpu grunt and underlying disks.
--- Quote ---encryption IS a stable feature in linux...it is the lack of proper integration of architectures from unRAID and linux kernel.
for example nested block devices with dm_mod and md modules are no problem in vanilly linux.
It should be possible with unRAID-md module as well, but I think emhttp is again the problem with the need to access a physical layer.
--- End quote ---
Yes 'all' you would need to do is layer dmcrypt on top of the md devices created by the unraid drivers. *But* all that would need integration into the unraid management setup and *that* is what would take the time to be implemented, tested and become stable.
Going out on a limb it *may* be possible to build the dmcrypt modules for unraid and insert them into the kernel, install the tools and do all this yourself by hand. It's all just linux though emhttp would get unhappy with you at some point. Work roundable if you *really* want though as you don't need emhttp at all to have a functioning array.
I doubt you have to mess with the parity disk either regarding encryption which is also a bonus.
NAS:
fyi i dont have the link at hand this now but i suggested this before and Limetech signed up as it being a good idea that would come... one day.
My focus would be on encryption preventing data mining only. i.e the simplest, fastest and therefore probably the least encryption possible implementation. It all about not worrying if the kit is nicked and not some hollywood trillion bit encryption option
Navigation
[0] Message Index
[#] Next page
Go to full version