Disk encryption

FreedomBox needs to offer disk encryption to the masses.

I see no docs or FAQ about disk encryption. If your SBC holds all your valuable data and somebody steals it, he’ll have it all!
OTOH, if you are not careful, you could lose it yourself.

Freedom Box should offer disk encryption. Encrypting data should be enough. Behind the scenes it could use a partition, or could create a block device and mount it (if partitioning is too much).

When encrypting, the UI would ask you for a password or let you plug in an USB to be used as decryption key. Also it would ask you size, and tell you the pros and cons in an Understandable way.
When blocked, the UI would display a message asking your encryption password or telling you to plug in your security USB drive.
Another UI should let you modify the password or USB drive.

No encryption. Not a good one, though.



Al instalar Debian, se puede elegir la opción de cifrar el disco duro. Luego se instala freedombox con normalidad. Así todo el sistema está cifrado.

Pero por un lado sólo me interesa cifrar los datos, y por otro uso una raspberry y no veo esa opción al flashear la SD.

Cockpit which is an essential part of FreedomBox is providing the functionality to Unlock/Lock and create encrypted disk mounts. It also seems to have support to modify cryptab (not sure if it allows USB keys). Could you please check it out and report what is missing and how good/bad the user experience is?

1 Like

Ok, I’ll try and report, thanks.

I’m curious… which path should I mount encrypted to secure all my freedom box users’ data?

Currently, we don’t have ability to change app data to a different disk. So, encrypted disk will be useful only for storing data for sharing, minidlna, samba, syncthing, torrents, etc. where you can choose the folder.

Well I have been doing some tests. Here is my experience.

Confusion about security and accounts

Cockpit confused me a bit. For example, unlike other apps I installed through FreedomBox, this one doesn’t autologin.

Later, I realized probably why: you can actually login with any system account, not just FB accounts.

I have 2 accounts in my FB. Let’s call them me_fb (my admin account I created in FB), and me_sudo (the account I have to perform sudo things, installing FB among others).

I’m used to disable password SSH access and let me_sudo’s password easier, since there’s no network exposure for that password. However, installing Cockpit is exactly like enabling SSH password access, so I had to change me_sudo’s password to make it more secure.

I wondered: should I just delete me_sudo and give me_fb sudo permissions? However I wasn’t able to find an answer on the subject.

So Cockpit raises some security questions that I’d like to see documented somewhere.

Cannot mount nor format

I have tried to do it as me_fb first, with no luck. So I logged out of Cockpit and logged in again as me_sudo, enabling privileged operations.

Within that mode, I’ve been unable to format a USB stick I plugged in. I also have been unable to mount or umount it. Always the same error:

Obviously I cannot format also:

I had one empty partition and I couldn’t format it encrypted also. The option is there, but it gives permission problems:

So, AFAICS there’s some problem with permissions, but I’m a sudo user doing this… How am I supposed to make it work, am I missing some specific group? :thinking:

We need to find a way to let Cockpit use sessions created by !FreedomBox.

Yes, but we can still let people carry forward their sessions to Cockpit if it allows.

Yes, it makes things simpler. Since me_fb is part of the ‘admin’ group, it can already ‘sudo’.

me_fb is the one that should have worked. Did you enable privileged operations when you logged in with it?

I typically create a FreedomBox admin account and use that to login to Cockpit. If the account issue is solved, the errors you are seeing in Cockpit should go away.

Yes, I did that, but no luck.

Might this have relation with the fact I’m installing FB in a Raspberry Pi 4B with raspbian? What files/configs/packages should be in place for this to work fine?

I’ve been thinking on another option: folder encryption. One good option is gocryptfs.

Vault has no relation with this subject, but if you ever tried it, you can see a pretty good encryption UI implementation: when you start the server, it starts “sealed” and displays a nice UI asking you to unseal the system. Once you enter the unseal passwords, it starts working normally, and authorized users have always a “seal” button.

That flow would be awesome for the freedom box. Using a folder encryption solution (instead of a block device solution as proposed above) would abstract the freedom box from the underlying partitions and specific deployment details. It could also allow the system to start normally and display a nice seal/unseal UI even when all you have is a single partition in an SD card. It could also help to decide which apps to encrypt (you want your chats and files encrypted, but maybe not your wiki). Backups could just copy raw disk data and still be secure.

What do you think about this approach?