Volumio security Hardening

Hi everyone, this thread is meant to discuss about what needs to be done to enance Volumio’s security, which is something we care a lot. The thing is that we need to find a good mix between reasonable security practices and usability, and this is not always simple.

The first step we’ll be undertaking in this sense is SSH hardening. Since right now SSH is ON by default and with an hardcoded password, we feel the urgency to change this, but at the same time mantain the comfort for tinkerers (and developers).
So this is our idea (thanks to Joe which helped us define this):

1st boot, SSH will be always ON with default password (volumio)
From 2nd boot and on, SSH will be off
At this point, there will be 2 ways to enable it:

  • put a file in /boot part named sshenable and if the content is not blank, the content will be the pw
  • Use a button on the /dev UI to enable SSH with an authenticated CSRF (so it won’t be possible to create hardcoded script to enable it)
    if you enable SSH, the first time you connect we ask to change the pw (unless it has been specified in the sshenable file)

What do you guys think?

Hi
i’m not an expert in anything, and particularly not inLinux, SSH or security.

as far as i understood, the method#1 looks well adapted for me , because as using SSH means you have something in mind , you probably already know how to put a file on volumio /boot

to put the file in /boot, i can do it from a windows network (network /volumio/drag & drap a file ?"
or can i go by filezilla ?

thanks again for the work done
eric

  • I would never put the cleartext password in a file. That’s a non-starter.
  • With ssh turned off, I don’t know how you would put a file in /boot . If there is a way to do that (without authenticating first), then you have bigger problems.
  • Requiring users to access the /dev UI in order to (re)enable SSH sounds like a good plan. Prompting them to change the password at first login is also a standard thing to do. Will this screw up plugin installation, or are those problems a thing of the past?

Another step in securing Volumio is turning off Samba, if (as in my setup) it’s not being used.

Good tip about Samba, we’ll add it.
The rationale of putting the file in boot is: when you flash volumio, if you want SSH and know what you’re doing, simply create the file in the first partition (which is FAT32 and therefore accessible by any PC, Mac or Linux). It’s mainly thought for us developers, to troubleshoot issues

Maybe a better approach would be a slightly more comprehensive one.

It would make sense to require authentication for the administrative functions of the UI (/plugin/system_controller-system , /plugin/system_controller-network , etc). Anyone on the LAN can play music, but you’d need an Administrator password to change the configuration.

Part of the initial setup, then, would be setting an Administrator password in the UI.

You could then set than to be the password of the “volumio” user (which would be needed to log in via the SSH interface).

It still might be worthwhile being able to toggle the SSH interface on and off, via the (authenticated) UI. But this would kill two birds with one stone: securing the Administrative UI and setting a (non-obvious) password for the volumio user.

As to turning off Samba, this is not just theoretical. Here’s a more verbose explanation. As far as I can tell, the prerequisites for a successful exploit:

  • configure shared files to have write privileges, and
  • use known or guessable server paths for those files.

are satisfied (though I’d be happy to be told I’m wrong ).

At the very simplest level, changing the user password from the default ‘volumio’ would be the bigest single improvement that could be made…

If you want to disable ssh unless there is a file in /boot (like Raspbian), that’s fine, but I don’t understand why you need to put a password in there.

The ability to toggle ssh on/off from the /dev UI is a good one.

Only if access to the /dev UI is authenticated.

There’s no point in toggling SSH off, if a non-authenticated user can toggle it back on using the web interface.

You’re right, but remember we need to find a reasonable compromise between security and user experience

The “non-authenticated user” still won’t have the password, if it is not “volumio.”

IMHO the weakest point of SSH is the password you use. I for my part use pre-shared keys for pretty much every SSH access I configure and disable password authentification. If SSH is properly configured on volumio like prohibiting root access for example there is nothing wrong with it. You could let the user enable ssh via the web gui and let them configure their public key. Also greet the user at their login via SSH with a message to change the default password and only turn off SSH it it hasn’t been changed.

root access is prohibited by default and we regenerate SSH keys on first boot

Which is great. What I wanted to say is, if the user has changed the password and maybe even uses pre-shared keys to authenticate it is fine to have SSH activated and no security threat at all.

That’s true.

But the issue is: how to get the user who never uses SSH (maybe doesn’t even know what SSH is) to change the password from the default “volumio”?

Merely toggling SSH off is useless if it can be trivially toggled back on; you really do need to make setting a password to be part of the initial setup process in the UI.

Here are my thoughts about volumio Security:

First I think it would be nice if the kernel and packages are up to date. If they get updated regular basis then there should not be a problem to update them „quickly“ if there is a serious security flaw in one of them. Of cause this could brick the system, so maybe there could be an experimental, normal user switch. This could be also some kind of public beta testing.

I think Volumio should run with low privileges. If I am not wrong Volumio is running as the user Volumio which is also a sudoer, so if there is any flaw in the web interface it could take full control over the OS.

So it would be nice if „every“ deamon gets a user which only had granted the rights it needs.

SSH and samba should be disabled by default.

My idea for setup. On first start the web UI should ask for a user name and then suggest a random password (which can be edited). This password should be protect the configurations.
Then in the configurations there can be a switch to turn on SSH a random password could be generated and then displayed. This makes it harder to set an bruteforceable password. For connivence there could be the option to upload a public RSA(or EC) key for SSH authentication.

Some scripts for plugins and upgrade need root privileges. Those files could be saved as root user and the process who needs to call them could be granted the permission in the sudoer file.
Like here:
askubuntu.com/questions/159007/ … a-password

I think this could also address this problem github.com/volumio/Volumio2/issues/1192

As already mentioned, Samba is a problem with the current (2.175) Volumio. I would suggest

sudo systemctl disable smbd.service

(Note: doing that requires having SSH turned-on. And note further that, if you do turn off Samba, then the only way to get files on or off a hard drive attached to your Volumio device is using ‘scp’ or ‘rsync -e ssh’, both of which require SSH turned on.)

SSH: Please be aware, that the boot partition currently is vfat in most cases but ext4 is likely to be the standard for many non-PI implementations. So, putting a file on the boot partition via a windows pc is not going to work as a general solution long-term.

Gé, let’s try to stick with vfat for as much as possible for first part…

First step has been done:

  • Disabled SSH by default
  • SSH can be enabled by DEV page or putting a file called ssh on boot

more info here:
volumio.github.io/docs/User_Manual/SSH.html

This will be available from next version

Next steps, change default password

Thanks!
BTW on overall security, one might want to check several files chmod in volumio app in particular: for instance, it seems several .conf files have 777 whereas not needed/desirable: such things could potentially allow some unwanted code injection/execution.