On Wed, May 10, 2023 at 01:41:47PM +1000, Stuart Longland wrote:
> delivery.  I've certainly coaxed Taylor UUCP to work over SSH in the
> past, and it does work just fine.  Not sure if OpenBSD has a built-in
> UUCP, but that is an option.  It'd solve my immediate problem… but I
> figure if they're going to sit there any length of time, I might as
> well protect them from prying eyes if possible.
> 
> The aim here is not to defend against every possible attack, it's to
> defend against the most probable ones and keep people honest.

Mail is most likely leaking while in transit or sitting on servers you
have no control over. So putting lots of effort into protecting mail
on your backup MX might not make much of a difference in practice.

softraid CRYPTO or RAID1C works well for servers. It doesn't protect files
if someone gains access to the live system, or gains access to decrypted
blocks or volume key in VM memory space if you're running in a VM. But at
least the underlying disks or disk images will be unreadable. In a VM in
particular it's difficult to reliably protect data from the host system
so you'll have to trust the host.

You need a way to enter a passphrase at boot so this requires bootloader
access on the console. And a reboot happening for any reason requires
manual intervention. I am fine with those restrictions and it's been
worksing well for me on servers I run.

In any case, you could as well encrypt invididual files to make them
unreadable to people who manage to peek into the decrypted softraid
volume somehow.
For invidiual files I cannot think of tools that do this and have great
UIs. Maybe indeed try to script something around gnupg or perhaps openssl(1).
No good options come to mind...

Or accept that you'll have to use a volume to be somehow unlocked/locked
on demand and take a look at the security/encfs and security/veracrypt
ports, and vnconfig(8) -K. Nesting softraid volumes should be avoided.

Reply via email to