Security Concerns

[ReK42]

There are several significant security concerns with the way this distribution has been implemented:

• Web UI clients connect directly to a nodejs process via an iptables port redirect.
  • Best practice is to serve web apps via a reverse proxy.
  • Using a well-known web server such as nginx to front-end client traffic offloads many security concerns to a well-maintained package with more resources for handling those kinds of issues.
  • I assume the iptables redirect was done because only root can listen on ports <1024. Implementing a reverse proxy removes the need for this as software like nginx includes secure ways to listen on ports 80 and 443 without maintaining root access.
  • See this article for how to implement.
• Web UI is HTTP by default and does not support configuring HTTPS.
  • Best practice is to serve web apps via HTTPS only, with HTTP redirecting to HTTPS.
  • Auto-generating a self-signed certificate is a widely accepted practice for deployments such as this, the idea being an encrypted connection is always better than an unencrypted connection even if the certificate is not fully trusted.
  • This can be easily implemented alongside the above reverse proxy recommendation, as only the client traffic to the reverse proxy needs to be encrypted since the traffic from the reverse proxy to the nodejs process is loopback only.
  • See this utility for a best-practices config generator for nginx to implement this.
• No local firewall is implemented, nor is configuring one supported.
  • Best pactice is to run a local firewall to control what traffic is allowed to reach processes running on the device.
  • Installing and configuring ufw is as simple as:

    apt install ufw
    ufw allow ssh
    ufw allow http
    ufw allow https
    ufw allow mdns
    [...]
    ufw enable

  • This results in a config file /etc/ufw/user.rules which can be included in the image.
  • To see which service names are supported cat /etc/services. Custom ports can be added with ufw allow 1234/udp.
• Changing the default SSH password is not supported.
  • While using a default username and password for SSH access is common practice, best practice is to implement the ability to change it for those who wish to.
  • I have seen replies to forum threads on this to the effect of "this is OK because SSH is disabled by default," however SSH can be enabled via the web UI with no authentication required to do so, easily circumventing this.
• Web UI does not support authentication and authorization.
  • There are areas of the web UI which should really be locked behind an authentication system.
    • The /dev interface allows access to sensitive information and functions, such as enabling SSH.
    • The settings area of the web UI allows reconfiguration of the device, service accounts (e.g. Volumio, Spotify) and other sensitive configuration/information.
  • Best practice is to implement role-based access control rather than a simple all-or-nothing authentication model.
  • Potential roles could be:
    • Admin: Full access (current behaviour)
    • User: Ability to use play controls, queue media, etc. but no access to settings or /dev
    • Read-Only: Ability to view Now Playing and the queue
  • More granular access control could also be a useful feature, e.g. the ability to allow users to change/queue tracks but not change the volume could be useful in a common-area jukebox device.
• Ownership and permissions of system directories is modified.
  • The changes to ownership and permissions of the following directories is concerning and contrary to posix best practices.

    -bash-5.0# ls -ld / /etc /lib
    drwxrwxrwx 1 root    root    1024 Jan  1  1970 /
    drwxr-xr-x 1 volumio volumio 1024 Jul 27 22:02 /etc
    drwxr-xr-x 1 volumio volumio 1024 Jul 27 21:10 /lib

[volumio]

@ReK42 Thanks so much for the compelling overview and proposed solutions. Those are the kind of messages mantainers love to see.

Most of the issues and suggestions you gave were already debated internally, and we always try to balance usability with security (that's the main reason some were not implemented).

I however agree there are some low-hanging fruits that we would love to start working on. If you would like to help us, I would suggest starting with point 1 and 2 (2 needs some further investigation if the client side accepts redirection to https). And later going to subsequent points.

My go to solution for point 1 and ideally 2 would be using caddy, as it has an out of the box auto-ssl feature which will greatly simplify the implementation. What is your take on this choice? Would you like to help us?

[ashthespy]

My go to solution for point 1 and ideally 2 would be using caddy, as it has an out of the box auto-ssl feature which will greatly simplify the implementation.

Caddy (v2) supports web sockets out of the box, so its reverse_proxy setup makes it trivial to access your Volumio device across WAN as well :-)

[volumio]

If someone is happy to help with a POC, we'll be happy to work on it