volumio
[RPi] Plugin Installation Breaks when the OS Password is Changed
Version: 2.175 Platform: Raspberry Pi
I installed the Raspberry Pi image and changed the user password for the OS via SSH. Now the installation of the Youtube Plugin fails.
The "details" section in the UI did not help:
Downloading plugin at http://volumio.github.io/volumio-plugins/plugins/volumio/armhf/music_service/youtube/youtube.zip
END DOWNLOAD: http://volumio.github.io/volumio-plugins/plugins/volumio/armhf/music_service/youtube/youtube.zip
Creating folder on disk
Unpacking plugin
Checking for duplicate plugin
Copying Plugin into location
Installing dependencies
The following error occurred when installing the plugin: Error
The log says:
volumio@volumio:~$ tail -f /var/log/volumio.log
2017-05-28T08:41:00.371Z - info: Downloading plugin at http://volumio.github.io/volumio-plugins/plugins/volumio/armhf/music_service/youtube/youtube.zip
2017-05-28T08:41:01.793Z - info: END DOWNLOAD: http://volumio.github.io/volumio-plugins/plugins/volumio/armhf/music_service/youtube/youtube.zip
2017-05-28T08:41:14.350Z - info: Checking if plugin already exists
2017-05-28T08:41:14.355Z - info: Rename folder
2017-05-28T08:41:17.669Z - info: Move to category
2017-05-28T08:41:46.801Z - info: Checking if install.sh is present
2017-05-28T08:41:46.806Z - info: Executing install.sh
2017-05-28T08:41:48.692Z - info: Install script return the error Error: Command failed: echo volumio | sudo -S sh /data/plugins//music_service/youtube/install.sh > /tmp/installog
[sudo] password for volumio: Sorry, try again.
[sudo] password for volumio:
sudo: 1 incorrect password attempt
2017-05-28T08:41:48.696Z - info: An error occurred installing the plugin. Rolling back config
2017-05-28T08:41:48.696Z - info: Plugin folders cleanup
2017-05-28T08:41:48.697Z - info: Scanning into folder /volumio/app/plugins/
2017-05-28T08:41:48.697Z - info: Scanning category audio_interface
2017-05-28T08:41:48.698Z - info: Scanning category miscellanea
2017-05-28T08:41:48.699Z - info: Scanning category music_service
2017-05-28T08:41:48.700Z - info: Scanning category plugins.json
2017-05-28T08:41:48.701Z - info: Scanning category system_controller
2017-05-28T08:41:48.702Z - info: Scanning category user_interface
2017-05-28T08:41:48.703Z - info: Scanning into folder /data/plugins/
2017-05-28T08:41:48.703Z - info: Scanning category music_service
2017-05-28T08:41:48.704Z - info: Plugin youtube found in folder but missing in configuration. Removing folder.
2017-05-28T08:41:52.421Z - info: Plugin folders cleanup completed
2017-05-28T08:41:52.423Z - info: Error: Error
2017-05-28T08:41:52.426Z - info: Folder /tmp/downloaded_plugin removed
2017-05-28T08:41:52.427Z - info: Folder /tmp/downloaded_plugin.zip removed
I thought about resetting the password to the default, but the OS won't allow me:
volumio@volumio:~$ passwd
Changing password for volumio.
(current) UNIX password:
Enter new UNIX password:
Retype new UNIX password:
Bad: new password is too simple
I propose an information. Try a simple command first (sudo echo 1). If it fails, show a message The password for the system user 'volumio' has been changed. Please use the install script ... via SSH. (Those wo know how to change the system password might also know how to start a script via SSH).
However, the install script is not available, because it has been deleted so fast.
Alternatively you could prompt for the password, but this has security implications, because the UI transmission is not encrypted #1166 and this would expose the sudoable user password to the network.
This is an issue: since now we would like to change default pw for user volumio, we need a way to execute the install script as volumio but with sudo. Ideas?
I created a pull request #1193, which simply removes the sudo call. I was able to install all current plugins with that version.
This obviously contradicts with your statement:
we need a way to execute the install script as volumio but with sudo
Why do you need root for plugin installation? For future plugins?
There are lots of echo "volumio" | sudo calls. Maybe it's worth changing the sudo rules to "nopasswd" and specify them more clearly
IMO you should do the following things
- disallow the user volumio to login via ssh (sshd_config or pam) at all (no need for). Then you can keep your default password or remove the password completly
- create a normal user (like the pi user) that can login and which password can be changed. for normal administrative tasks
Alternative: fix the sudoers rules so everything can be executed using nopasswd. Then the scripts don't need to pass a hardcoded password in the control and pluginmanager scripts
Disabling SSH Login is completly useless as long as you can reenable it via WebUI without any form of authentication. This does not really prevent the abuse of the volumio player as an attackable IOT Device.
Access to the system without authentication (as with the web-gui) is obviously bad. Did you think about creating two users? One for system management and the core infrastructure and one for the user. The ssh login for the former can be denied via /etc/ssh/sshd_config but ssh logins in general be kept up.
To preserve safety of my local network, I have generated a pair of ssh-keys and added it into volumio user.
Then, I enabled PasswordAuthentication only for localhost. That way, Volumio processes continue to work as expected, and then I am still able to connect to the volumio server with my ssh key.
What if, by accident, I loose my private key ? Well, I am able to plug a monitor and keyboard to revert the changes.
Steps:
- Enable SSH in http://volumio/dev (have a look at https://volumio.github.io/docs/User_Manual/SSH.html)
- Generate a pair of ssh key, if needed
ssh-keygen - Add it to volumio
ssh-copy-id volumio@volumio - Log into volumio and change ssh settings:
$ ssh volumio@volumio
$ sudo su
# cat <<EOF >> /etc/ssh/sshd_config
PasswordAuthentication no
Match Address 127.0.0.1
PasswordAuthentication yes
EOF
- Restart sshd
# service sshd restart
Here you are workaround I'm using quite a long time which can improve the security allowing to use non-default password for ssh access.
- log-in as volumio user and change the default root password
volumio@volumio:~$ sudo -i
root@volumio:~# passwd root
Enter new UNIX password:
- enable root and restrict volumio ssh login
root@Volumio:~# nano /etc/ssh/sshd_config
...
PermitRootLogin yes
...
Match User volumio
PasswordAuthentication no
- apply changes via sshd restart
root@volumio:/home/volumio# /etc/init.d/ssh restart
[ ok ] Restarting ssh (via systemctl): ssh.service.
Using this setup, I have never had any trouble with the system upgrade or plugin installation. If you need to work under volumio account (e.g. for devel. plugin installation), just log in as the old school root user and switch to volumio user:
root@volumio:~# su - volumio
volumio@volumio:~$
Sorry but this seems to be a worst solution than what it cures: you enable directly root login
disagree ;-) I don't see anything wrong with using root login protected by strong password in private home network. It is the same like other well known user name with sudo privileges and much better than volumio account protected by default password.
This triggered a couple of thoughts. I'll throw them out there in hopes of stimulating more thoughts.
- system comes preconfigured so user volumio may not log in, as you show above
- at first boot, generate a volumio password, store it in plaintext /data with mode 0400 and permissions volumio:nogroup
- this could be avoided if we get rid of the need for 'echo $pass | sudo' entirely
- in the wizard allow option of setting up a new user and password that is allowed to log in over ssh.
- This would be the only time this is allowed; give the user a fixed uid and if that already exists, do not allow it to be overwritten
- this user goes in the sudoers group, which has
%sudo ALL=(ALL:ALL) ALL - attacker has to guess user and password
- fail2ban is a nice simple way to stall guessing attacks, but it requires python3. Might not be that much extra disk space.
Why does plugin installation need sudo / root access? Everything else in the web GUI does not require anything like that. Awkward. (Yes, one could argue that manipulating the system in the web GUI should require a password.)
On another note, what about running the plugin installer on a terminal (not via the web GUI)? Is is possible to run the installer with sudo / root permissions? This would at least allow plugin installation on the terminal (via ssh access).
I agree with @mbrennwa, a root acces shouldn't be needed here. As (almost) all files in /volumio belong to, well, volumio, no sudoing should be required.
This is even dangerous, as plugins could execute some weird code.... 🤔
I see from some plugins that they are installing (and removing!) other OS packages, which would need some form of privilege - but (IMHO) that's not a "plugin" - that's another "application" (which happens to be closely coupled with volumio) Having sudo without a password is not a solution (again, IMHO) So, how about the plugin "Install" button asking for the password? This would ensure that the plugin can only be installed by the user AND it would mean that the password can be changed.
+1. That means you have to have a keyboard of some kind available when installing plugins, but OTOH it is an action that is probably best done sitting in front of a computer, paying full attention.
There are some mods to system files that volumio needs to do, which requires root permissions. However having an explicit list of commands that can be sudoed with no password should be ok for most of that. The sticking point for this issue has been arbitrary commands that plugins want to run, so requiring a password for that case only may be reasonable. Not quite sure how difficult feeding the input password to sudo will be.
(edit)
Then we circle back around to changing the password, over an unencrypted web link, from the factory default. I keep thinking that offering to change it in the startup wizard might be enough, and once that has been done then ssh for the volumio user could be enabled again. Of course the plugin dialog won't be encrypted either, so any later use also exposes the password...
We could always send the password from the webUI to the backend, sure it is not over https, but it would be better than the current situation?
I agree, better than where we are now, particularly if it is a one-time change at installation, or a once-in-a-while change, at most.
That means you have to have a keyboard of some kind available when installing plugins
Not necessarily... on my Android device, the pop-up keyboard appears when needed, so I don't see that as an issue.
We could always send the password from the webUI to the backend, sure it is not over https, but it would be better than the current situation? Yeah, this is what I had in mind with the Install button, (but hadn't put into words)
However having an explicit list of commands that can be
sudoed with no password should be ok for most of that. I'd be cautious of this approach (but I don't have a better suggestion). It will start with "just" a few commands, and then more & more will be added (and none removed). There should really be a single approach for both the volumio core AND for plugins.
Further thought has brought me to a series of steps like this:
- add fail2ban to the system to drastically limit random probing (ssh only). Installed size is 512k so it may need a little pruning, possibly a rebuilt package in the volumio repo. Most of the dependencies seem to be installed already.
- add /data/password, containing the current password. The image gets built with this file. After the first image with that file is released, start work on the backend
- convert all hardcoded usage in the backend to 'cat /data/password', one module at a time.
- plugin authors will have to go through the same transformation.
At this point a savvy user could login over ssh and change it if they want.
- add a 'device password' step to the first run wizard, which updates the file.
After that has run, the only way to change the password is to ssh in and run 'passwd' (unless of course there's a way to make it run again, then you might have to put in a check that the current password is the expected image default and skip that step if not).
I think this gradually improves the current situation without requiring a lot of change at one time. It also avoids the network eavesdropping issue except for one occasion. After that perhaps we can start getting rid of the 'cat /data/password' calls.
Disabling ssh access by default is still a good idea and I think we can leave it that way.
@xipmix I really like your approach, seems this offers the best balance between security and flexibility. Would you be willing to work on it and submit PRs? If yes, that woud be awesome and I'll actively cooperate
Sure. Actually there seems to be only one place where the 'echo volumio' idiom is still in use, pluginmanager.js. A lot of good work has being going on while we've been dithering here. Maybe this is less work than we feared.
Just re-read an earlier post:
* add /data/password, containing the current password. The image gets built with this file. After the first image with that file is released, start work on the backend * convert all hardcoded usage in the backend to 'cat /data/password', one module at a time.
This is just moving the problem around.
Password security is not done by checking whether the password matches - instead - a hash of it is checked. So, the workflow should be (similar to):
- User enters a password
- Password is hashed (let's just say SHA256 - I must admit that I don't know what hash is best here)
- The HASH is stored
- Any time a password is required to add / update something, then the user is prompted for the password and it's compared to that hash.
The point is here, the user is totally aware of when Volumio is trying to do something AND we have improved security :)
The logical place to store that hash would be the /etc/shadow file, so what you are proposing here boils down to "prompt the user for every sudo invocation that requires a password", which is a significant change of user experience. It also exposes the password on the network since the connection is over http, not https (see comments above). On the other hand, AFAIK at present the only sudo calls that need a password that are left is plugin installation and removal. So maybe this is something that could be done in a further iteration.
Imho the best step forward is:
- Prevent all ssh password logins by adding
PasswordAuthentication noto file/etc/ssh/sshd_config - On help pages and/or volumio.local/dev page, add instructions
- If you want to login via ssh, mount your SD card to your computer, and with root permissions, put your SSH key in /home/volumio/.ssh/authorized_keys
- Please never change the password of the volumio user, as the plugin system currently needs this. If you accidentally changed the password, mount your SD card to your computer, and with root permissions, in /etc/shadow replace the line starting with "volumio" with this line: ...
Of course we can do a lot more, but this may be a start.
Working with the SD card would require physical access, which is not always possible.Am 31.01.2020 01:13 schrieb geek-merlin [email protected]:Imho the best step forward is: Prevent all ssh password logins by adding PasswordAuthentication no to file /etc/ssh/sshd_configOn help pages and/or volumio.local/dev page, add instructions If you want to login via ssh, mount your SD card to your computer, and with root permissions, put your SSH key in /home/volumio/.ssh/authorized_keysPlease never change the password of the volumio user, as the plugin system currently needs this. If you accidentally changed the password, mount your SD card to your computer, and with root permissions, replace the line starting with "volumio" with this line: ...
Of course we can do a lot more, but this may be a start.
—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or unsubscribe.
This idea of manually installing an authorized_keys file has merit, it saves having to modify the wizard and installing fail2ban. But it seems rather easy for it to go wrong and frustrate the user. For example making sure 'volumio' and not 'root' owns said file... Perhaps an automated chown && chmod at boot time can ensure this isn't a problem. Another option would be to do the ssh key upload as part of the firstrun wizard, if that doesn't complicate that process too much. The manual approach should be added to the 'good to know' section of the docs, in any case.
The question of physical access doesn't seem a big problem to me, you have to burn an image to the card at some point and shortly after that, run that firstrun wizard.
I do think it is useful to be able to change the volumio user password if the user desires this, but that could be implemented in a later iteration.
On Fr, 31 Jan, 2020 at 05:31, xipmix [email protected] wrote:
The question of physical access doesn't seem a big problem to me, you have to burn an image to the card at some point and shortly after that, run that firstrun wizard.
This assumes that the SSH keys will never change after the first set up. This may (will!) not be the case in many situations. For instance, in my environment the computers and user accounts that need to access the volumio boxes change quite often. Turning all volumio boxes off, accessing the SD cards, fiddle with the SSH keys, copy them to the SD cards, and reboot all volumio boxes every time is simply not possible.
Disabling password access is not a "fix" for the root problem that the password is hardcoded in some spots. I don't understand why Volumio can't just ask the user for a password whenever it's needed (be it SSH or the web UI).
Is it true in your environment that once you have one ssh key set up, you could do all later changes over the network? That's what I was envisaging, that the physical access upload would only need to be a one-time thing. (You may also be interested in this talk from LCA, by the way - https://linux.conf.au/schedule/presentation/54/)
I agree disabling password access doesn't address the root problem. It would be interesting to hear what @volumio thinks about the UX impact of being prompted for passwords at regular intervals.
There's another issue though - the generation and use of ssh keys. My guess is the number of volumio users who have the faintest idea how to work with SSH keys is rather small. That's not to say it shouldn't be supported, but there may still be a significant need for password-based access.
Thanks guys for this interesting conversation. IMHO the best sum of all proposals is:
- The etc/shadow file will not contain the volumio line, which will be added in a separate file via an include.
- We can request ssh pw change at first ssh connection. And store such password in the included ssh line (this way it will survive updates, while avoiding to impact global shadow file
- We also store the pw under /data/userpw . This variable will be read by the plugin installer when it needs to install a plugin
- SSH keys is too much of a nieche request to be taken into consideration
What do you guys think?