Hardening LMS security

[Soundwave]

Hello, I am struggling a bit with properly securing LMS (on linux), and looking for some tips how to harden the server.

The main problem is I cannot seem to find a way to set up tiered access between simply accessing and listening to music, vs. accessing and controlling server settings. There is only one shared username/password for all types of access, including the ability to browse server folder names (the name of any folder accessible to the LMS user on the server) in the settings tab for entering music library path. I want to be able to give visitors the ability to use SqueezePlay to listen to music on my home network, but without also leaking information about the layout of folders all over the server.

I have tried some naive attempts at workarounds, using iptables to restrict access to port 9000 or ports 9000+9090 to localhost, so that accessing the web interface would require using an ssh tunnel to the server. However, when I do this (even for just port 9000) then SqueezePlay is no longer able to authenticate with and connect to LMS.

So does there have to be all-or-nothing permissions here, or is there something important I am missing? Alternatively, any decent workarounds you would recommend? E.g. set up a LMS server in a minimalist VM or chroot jail, and provide LMS with access to music libraries via samba? Or some other way of limiting what parts of the file system are visible to LMS?

And as I am sure this would otherwise be suggested - I do not see "just make sure the LMS user on the server does not have permissions to access private data" (by changing permissions all over the file system) as an acceptable workaround.

Cheers

[erland]

The two solutions I could think of is:

1. Run LMS in a virtual machine or chroot jail which doesn't contain anything important. Will still make it possible for users to change settings in LMS but they won't have access to everything else you have installed on the server. I personally run LMS in a VirtualBox machine which have the music folders residing on a NAS mounted as read-only, but I was mainly looking for a way where I could ensure that LMS couldn't do something that destroyed my music files.

or

2. Password protect the server and only allow users to play music using the iPeng Party iPhone/iPad app. I think you also need a device with the full iPeng app on the network. iPeng Party won't allow any settings to be changed but as I've understood it can work in a mode where it can access the music without having to give away the server password to your users. However, it have some limitations you might not like depending how the users are going to use the system, you will find more information about it here:
http://penguinlovesmusic.de/ipeng-party/

The general issue is that LMS isn't really designed to be used on a network which untrusted people have access to. This is especially the case if you start to install third party plugins on the server as some of these aren't designed with security in their mind, so password protecting the server without giving out the password to everyone is important in such scenario.

[Soundwave]

The two solutions I could think of is:

1. Run LMS in a virtual machine or chroot jail which doesn't contain anything important. Will still make it possible for users to change settings in LMS but they won't have access to everything else you have installed on the server. I personally run LMS in a VirtualBox machine which have the music folders residing on a NAS mounted as read-only, but I was mainly looking for a way where I could ensure that LMS couldn't do something that destroyed my music files.

Thank you for the reply erland. I will probably go with your #1 approach. I am setting up a small fanless server with very limited RAM, so I am thinking chroot jail is the way to go.

[Soundwave]

So I decided to set up a chroot jail, with good results. SqueezePlay has access to all the music, the web interface no longer leaks information about the (host) server file system, and all is well. Not a perfect solution, but an acceptable one.

For anyone who wants to do the same (on Debian), here is a brief high-level write-up. Used debootstrap to set up a chroot jail debian environment. Used schroot to open a shell inside the jail and install perl and lms (plus flac and faad just in case, don't know if they are needed). Used smbfs to mount a samba share read-only with all the music at a mount point inside the jail. Whenever LMS needs to be started, use schroot to do an /etc/init.d/logitechmediaserver start inside the jail.

So far I didn't bother to make start/stop scripts for the debian host, but that shouldn't be too much effort.

[banned for life]

On the other hand, you can use settings/advanced/security to allow/block ip addresses.

This is how I can open ports to the internet without worrying about a breach. If I'm at a remote location and want to listen, I configure the remote ip remotely.

Don't forget to allow your local ip's and 127.0.0.1 when you turn this on or you will have to manually edit server.conf.

bfl