Hm, so when using Nextcloud, is the db itself encrypted or something?
All my devices are encrypted.
Access to the decrypted data requires RAM access, i.e. cold boot attack. Or access to the server via ssh (fail2ban, strong keys) or the admin or user nextcloud accounts (again with strong passwords and possibly TOTP or webauthn).
I already fiddled with the required Nextcloud Addons for TOTP and it worked great. Webauthn is an Android/GrapheneOS limitation poorly, maybe that gets fixed some day.
The issue of course is upgrades. I should do a second post on that topic. There are solutions for that, like mounting encrypted partitions and running Nextcloud on there. This could be automated.
For the obvious raid attack, I would have a udev rule that detects when AC is disconnected and then performs a clean shutdown.
poVoq@slrpnk.net 5 weeks ago
No the Nextcloud DB is not excrypted, but neither is your LUKS file system while the computer is running. Anyone getting access to the server while it is running, can access all the data unencrypted. For a server this is the much more likely scenario than for a Laptop, which might get stolen while turned off.
At-rest disk encryption is useful for servers in co-location hosting, where a 3rd party might be able to pull a disk from the system, or if you are a large data-center that regularly discards old drives with customer data, and you want to ensure that no 3rd party can access that data from the discarded drives.
boredsquirrel@slrpnk.net 5 weeks ago
Yes the threat model is people pulling out the drive, of course.
How should they get access to the server when it is running? You still need to connect to it and log in, which wouldnt be the case.
poVoq@slrpnk.net 5 weeks ago
It is possible that people get access to your server while it is running via known or unkown software vulnerabilities, but that isn’t really the point… all I am saying is that if you host your server at home, it is unlikely that at-rest disk-encryption does you any good and it certainly doesn’t help to protect against illicit remote access.
What it does “help” is preventing you from remotely accessing your own server if it rebooted for some reason… and many other such footguns that you will experience sooner or later.
boredsquirrel@slrpnk.net 5 weeks ago
Yes this is true. That is why a separate method would be needed, to log into and hand the password to the LUKS decrypt of the server.
I heard Debian can do this with ssh in the initramfs?
Sounds like a hella pain of course.
Alternatively I thought about using a security key to unlock, and in scenarios where I am worried about getting hardware stolen, I can pull it out and need to manually enter the password.