Volumio security Hardening

Volumio Development Development talks
21

(I just registered to post this)
For me it looks a good a idea to hide some volumio settings too. I have a volumio running where multiple people have access to. I want them to be able to play music, but they can also:

  • Meshup the wifi.
  • Meshup my music collection settings
  • Preform a factory reset.
  • Install a random plugin.
  • Reboot the system
    To call some :stuck_out_tongue:

First login: Change admin password
adminpassword -> volumio user password.

22

I am baffled by the current solution. let me explain my experience:

Using volumio mostly out of the box (using etch to burn the system and then go), I rarely use ssh. But when I did want to use ssh, I found that my volumio devices were wide open for anyone access to the /dev url for almost a year.

Nowhere during installation there was a clue that I had to change my ssh password. It was simple to turn ssh to turn on with /dev and the standard password.

Imo, ppl who use ssh ARE ‘more advanced’ and should write the empty ssh file in boot if they want ssh access. That procedure is implemented by raspberrypi.org and that is what the – more advanced – user expects. And also the less advanced user (like me)

So the current implementation is not idiot proof (if I may call myself that way), and it should be. Especially with the changing IT landscape with a growing number of security breaches and hacks.

best regards

Rieas

23

I agree with VolumioIsGreat:

  1. The kernel and packages should be kept up to date
  2. The web interface should run with low privileges
  3. SSH and Samba should be disabled by default
  4. Daemons should have no more rights than they need to perform their tasks

Regarding generating a random password, I would caution that ‘random’ is far easier to say than to do. Alan Turing said it best, something like this: “Anyone attempting to generate random numbers algorithmicaly is, of course, in a state of sin”.

Macmpi pointed out that configuration files should not be world-writeable; that is also a good practice.

24

+1 on the 2 previous posts.

I had the same frightening experience to find that /dev was unprotected and let anyone turn ssh on with a default password.

I was expecting the “sshenable” file technique. If you want to go the “write a cleartext password” way, it’s fine as long as the file is destroyed as soon as the ssh is enabled and the password set.