Encrypted share

TrueNAS General
, ,
1

Is it possible to have a network share, where the files themselves are encrypted so that not even the admin (me) has access to them? I was thinking of iSCSI, and have the client put whatever encrypted file system on it, but it has the limitation of only allowing a single client at a time. Some users have multiple computers, and would require constant unmounting and remounting between them. There was also the possibility to create a virtual disk image on the share and mount that, but it also seems to have problems with simultaneous access (unless read-only).

Is there some client-side software that encrypts individual files on-the-fly? The specific client that requested this is using Macs.

2

This requires having client encrypt the data before sending to the NAS (not transport encryption, but actual encrypted data). You’re not going to be able to change a NAS setting to accomplish this.

3

What is the threat model for this request?

  • prevent users from stealing data? They already have access.
  • prevent you as admin from stealing data? As an admin you already have access.
  • protect the data when the NAS gets stolen? Just steal a client computer as well.

Please ask your client about their specific problem and their reason for their request.

And: I don’t know of any commercial software integrating tightly into the os and do file-by-file encryption. Apple uses volume encryption.
Their threat model is:

  1. Protect user data when a device is stolen.
  2. Devalue stolen and locked devices in order to reduce theft
4

It’s possible to do this with Nextcloud–it isn’t a “shared folder” in the normal sense, but if you enable its end-to-end encryption, only the client apps for the appropriate accounts can read the data for those accounts.

Not if it’s encrypted on-disk, and you don’t have the key.

1 Like
5

I don’t really understand your first two stealing scenarios. If the files are encrypted on the server, nobody else has access. The stated goal was that not even the admin won’t have access, in which case the admin per definition won’t have access.

Also the third one is questionable, as you yourself stated, Apple’s threat model is to protect user data when device is stolen. Even if the keys are stored on the drive, it’s behind volume encryption.

Anyway, it’s just that some family members don’t like the idea that I’m able to snoop around their files

6

What about VeraCrypt?

You would be limited to a maximum size (or set size) for each VeraCrypt volume, and the volume could be a file that is hosted via an SMB share.

Not sure how nicely it will play with ZFS underneath, especially if your pool is comprised of RAIDZ vdevs instead of mirrors.

7

A native solution on Macs is possibly to create encrypted sparsebundle volumes on the client (using Disk Utility) and store them on an SMB share. When they want write access they could double-click on the sparsebundle file to mount it (after entering your password).

I haven’t done anything more than basic smoke-test. You’d want to carefully validate behavior (especially in multi-client scenario). Basic testing indicates the sparsebundle can only be opened by one client at a time, but you’d need to validate behavior for situations like reconnect after sleeping, power outage, etc, etc.

8

I’m an avid user of encrypted sparsebundles. They work great for single users, provided you have some patience. Mounting can take time and a long time I ago I had one become scrambled in a power failure / system crash (not on the TrueNAS).

So I’m a big fan of expandable, compressed, and encrypted sparsebundles for applications such as WORM archives since the resultant bands take up less space, replicate a lot faster via rsync than the underlying small files would, and are secure even if the media fall into the wrong hands.

Not as much benefit with larger files like images that won’t compress and so on. Not sure one breaks speed records writing to a sparsebundles either. (Isn’t Time Machine using encrypted, expandable, compressed sparsebundles?)

But if the admin is not supposed to have access to usable data, I suggest the user has to encrypt it before it lands on your NAS.

1 Like
9

Encryption depends on how you configured the time machine backup when you first created it.

One of general problems BTW with hosting encrypted volumes in this way is coordinating snapshots with when the volume is in a quiesced state. It took some work to add logic for this for our “multi-user time machine” shares (coordinating dataset snapshots with when time machine backup completes). If a share is just hosting various sparsebundle volumes that clients are consuming, then if one gets corrupted (or user needs to recover file) it becomes a guessing game as to whether a particular snapshot will work.

10

About 10% of the time I try to run rsync backups of actively-used Time Machine sparsebundles, CCC errors out due to files being in use, etc. So, I just run CCC at a later time and wait until I get a non-error.

I have no doubt that coordinating snapshots and Time Machine must have been a very tricky issue to get right.

11

Yeah, I suppose that’s an interesting point. An admin could in theory write a script that checks which files are reported as having the sparsebundle lock held by an SMB client, and save that somewhere with information about the snapshot (so known-bad sparsebundles would be visible).

root@truenas[/home/admin/pyadmin_tools]# midclt call smb.status LOCKS '[["filename", "$", "sparsebundle/lock"]]' '{"select": ["service_path", "filename"]}' | jq
[
  {
    "service_path": "/mnt/dozer/SHARE",
    "filename": "Stuff.dmg.sparsebundle/lock"
  }
]
1 Like
12

I think I found a solution for the original problem: gocryptfs. There seems to be multiple alternatives for this kind of solution, so might try different ones if this doesn’t work.

This also seems to work well with my existing off-site backup using Syncthing, as it can just sync the individual encrypted files.