Home directory encryption via ecryptfs is now the default in most Ubuntu variants, and it would be insane not to attempt to support it.

That said, given that my Dropbox subscription just renewed (and that Linux is pretty much the only reason I'm still using it, since there is no OneDrive client I can rely on), I am really sad this seems to be a future direction for Dropbox.

On the contrary, Ubuntu 18.04 dropped the home directory encryption entirely and now only supports full disk encryption.

Indeed: https://wiki.ubuntu.com/BionicBeaver/ReleaseNotes#Other_base...

> "The installer no longer offers the encrypted home option using ecryptfs-utils. It is recommended to use full-disk encryption instead for this release."

There was also a series of issues found by with the encryption used by ecryptfs:

https://defuse.ca/audits/ecryptfs.htm

The full disk block-based (as opposed to this file-based) encryption is really the way to go if you want a good security and performance margin.

Author of eCryptfs and EXT4 encryption chiming in.

"Series of issues?" Really? There were 3, and they were all scored "Low" by the authors for exploitability and security impact.

That said, I generally agree FDE is the way to go if your platform's constraints allow for it -- but only for security. Native EXT4 encryption will give you equal or better performance than FDE primarily because the file system metadata isn't encrypted. Which isn't to say that's a good tradeoff -- it's just the nature of the beast.

Because of performance and functionality issues (file name length, possibility of page cache inconsistency) eCryptfs shouldn't be used for anything any more.

Ah, you're right, I had it confused with a similar analysis on EncFS which had more significantly damaging findings.

https://defuse.ca/audits/encfs.htm

I wasn't even aware Ext4 had native encryption support though! I'll definitely have to give that a go. Thanks for the tip.

According to Michael Halcrow's LinkedIn [1], he was heavily involved on the EXT4 encryption:

"I was also the project lead for encryption in EXT4, which is now available as the mechanism implementing file-based encryption on Android."

[1] https://www.linkedin.com/in/michael-halcrow-1880601

There is (or at least _was_ when I last tried FDE) one major fly in this ointment: you lose the ability to reboot your machine remotely. Upon restarting it required that you enter the password, which you can only do from a local keyboard.

On Debian-based systems including Ubuntu, they offer an initrd based Dropbear (lightweight SSH server) which can be used to connect and authenticate. Involved a bit of custom scripting last I checked though, but a possible solution if that's a requirement for you.

For such systems I consider the primary root file-system to be part of the 'bootloader'. Everything that I want to keep actually secure is inside of the encrypted PVs backing LVM volumes.

Yes, this presents a security risk in that someone could (offhand I think the term is 'evil maid'?) attack the root filesystem, but they could still have done that to the bootloader anyway.

Remote interaction is then required to bring the VMs on that system up.

They could not have done that to the bootloader because of SecureBoot.

With secureboot on Linux you can secure as much or as little as you want. On my system, grub isn't even safe, only the shim that load grub is secure. But I could set it up so the kernel is secure, have the kernel only load verified initrd, and then have the initrd check the root filesystem.

I don't, but secureboot can detect changes to the root filesystem if you want it to. I think this generally requires setting the rootfs to mount readonly.

You could put a daemon on the initramfs (say, ssh) that allows you to remotely provide a key/password for decrypting the disk.

This would certainly be more work to set up than vanilla full-disk encryption, though.

Shit, so now I can't turn on my desktop remotely and supply the password through SSH later? That's a huge inconvenience.

> Shit, so now I can't turn on my desktop remotely and supply the password through SSH later? That's a huge inconvenience.

a) This hasn't ceased to work for your desktop - you can continue to do this through the upgrade cycle, as it would only affect new installs (safely converting native fs to dmcrypt isn't possible, AFAIK)

b) during an installation you could eschew FDE and opt for a PV, as I do, that you put your selected, secure LV's onto. I use Debian in preference to Ubuntu, but I'm sure they're materially identical in this case -- two physical partitions -- /boot and not-boot. /boot isn't encrypted in my case, but /, and /home (and a couple of others, though not swap of course) are LVM2 volumes sitting on top of the encrypted 'rest of the disk' partition. If you have /home only with noauto option in fstab , pointing to a an LV on the crypted partition, you could continue to do what you're doing, with the same reduced security confidence.

Debian and Ubuntu allow running Dropbear in initramfs to prompt for the FDE password

That's fantastic to know, thank you. Do you know if it's complicated to set up?

Though unfortunately if you want to dual-boot, you have to manually set up the encryption :/ As in https://askubuntu.com/a/293029/25639 – I do wish the installer could do that instead of asking dual-booters to compromise.

If it just renewed and this changes breaks your use case you can probably request a refund since your system is no longer supported.

What issues have you found with this Onedrive client[1]? I've been using it for over a year without any hiccups beyond the odd duplicate file

[1] https://skilion.github.io/onedrive/

I second this. I created my own systemd service so it runs when I’m not logged in and it’s been as reliable as Dropbox. On the one occasion (in 3 years) it did screw up, I simply ended up with two copies of the same file.

I get a terabyte free with onedrive, because of the office subscription. I wish I had a good way to utilize it on Linux.

Out of curiosity, what happens if you office subscription ends? Obviously you won't be able to sync but does onedrive have some sort of grace period to let you download your stuff and at what point would it go and completely delete your data?

If it's the business version, you have full access for 30 days, admins have access for 90 days, then it's deprovisioned (source: https://support.office.com/en-us/article/What-happens-to-my-...)

On the O365 Personal/Home or direct OneDrive plans, it looks like your data remains available but read-only for 3 months, then your account is "frozen." You can do a one-time 30-day "unfreeze" to get access to download/delete (to get under your quota), then it gets "frozen" again. Eventually it'll be deleted, but I don't see documentation for how long that takes. (source: https://support.office.com/en-us/article/what-does-it-mean-w... linked from https://support.office.com/en-us/article/OneDrive-storage-pl...)

I believe the modus operandi for most personal cloud storage providers here is to make the entire dataset read- and delete-only until the user gets enough storage space (by upgrading or deleting files) to be able to write/upload again. That, plus some incessant push messages to your client devices about upgrading, which is annoying but expected.

Office stops working if your subscription ends so most likely they will renew their subscription.

Use a flow to replicate your onedrive in Azure Files, then mount it to your Linux box: https://flow.microsoft.com/en-us/galleries/public/templates/... AND https://docs.microsoft.com/en-us/azure/storage/files/storage...

That would be very much not free

rclone mount

I use Google drive, but the Linux support was awful and I started using insync. It's about $25 for a lifetime license and I love it. I run Ubuntu with encrypted home and have for years. It works great and I highly recommend it, and I don't work there, just a happy user. The Nautilus integration is decent too.

Not trying to rain on your parade, I hope it fills your use case.

However, my IT company onboarded a media-intense client with insync and it has been nothing but a nightmare. There are hardcoded limits (like only syncing two files at a time, IIRC) that make it effectively useless for anything beyond small, personal use. It's cheap and you get what you pay for.

Not sure what your exact role is but is there a possibility to move this client from insync to rclone?

rclone is rsync for cloud storage services -- https://rclone.org/

I seldom use it, so I can't say how well it runs, but from Gnome version 3.22 if I'm not wrong, Google drive is integrated with Nautilus (the file manager) via GVfs/GIO and the couple of times I used it to share a file worked flawlessly.

YMMV ^__^;

You could use Nextcloud instead.

I recently switched to Nextcloud because Dropbox's Android app is terrible, and like it a lot. It does everything Dropbox does, I get as much space as my server has, and the apps are all better than Dropbox.

I also use Syncthing, which I am very impressed by, it works really well.

Security concerns aside, I found home directory encryption to have awful performance. It also caused issues with file name length.

If you feel comfortable with Google, Gdrive has a great client in the form of OverGrive.

And there’s always rclone. Combine that with whatever encryption you want and you’re set.

Just put /home on a separate partition and please the BOFH gods.

I'm surprised to hear anyone is still mounting home and root on the same partition, frankly. It's made my life sooo much easier since I started doing it ages ago.

The (supposed) Dropbox engineer refers to Extended Attributes.

Maybe they’re doing uncommon stuff with ’em that uncommon filesystems cannot cope with... ;)

> "It's not encrypted ext4, it's ecryptfs (which acts as a separate layer entirely, creating a virtual encrypted filesystem on top of ext4) - probably doesn't support some inotify feature or some extended attributes that aren't set correctly when used through ecryptfs."

Thanks, I updated the title.

What do you think are the chances that Dropbox “just works” on a file system on which it isn’t regularly tested but which nominally has the right feature set? I’d go with “not good”. :-)

This whole article read (to me!) as them wanting to reduce test load, and probably workarounds in their codebase.

The backing files for your ecryptfs will still get synced though, correct?

If you point it at the backing files and they're stored on a supported FS, I see no reason why they wouldn't.