Open mkonersmann opened 7 years ago
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?
see also #948
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
1) 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 2) 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:
ssh-keygen
ssh-copy-id volumio@volumio
$ ssh volumio@volumio
$ sudo su
# cat <<EOF >> /etc/ssh/sshd_config
PasswordAuthentication no
Match Address 127.0.0.1
PasswordAuthentication yes
EOF
# 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.
%sudo ALL=(ALL:ALL) ALL
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 sudo
ed 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
sudo
ed 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:
At this point a savvy user could login over ssh and change it if they want.
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.
Hope so ;) Thanks for helping out on this
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):
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:
PasswordAuthentication no
to file /etc/ssh/sshd_config
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 notifications@github.com: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 notifications@github.com 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:
What do you guys think?
I'm not following.
I'm not aware of an include mechanism for /etc/shadow. How are you thinking this would be implemented - with some boot-time rebuild of /etc/shadow from shadow.base and shadow.extra files?
Also unclear about how to implement the change-on-first-ssh; chage
is the normal mechanism but it will only update /etc/shadow
. Something else is needed to save the encrypted password to a separate file and the plaintext to /data/userpw. Or are you meaning this would be done in the wizard?
I agree ssh keys is somewhat niche.
OK nice to have a discussion about that. So let me elaborate more.
Unsecured IoT devices are quite common these days, but the more we get of them, and the safer the desktops get, the more interesting attack targets they are. Also as an attacker, you can hibernate your trojan in an IoT device, even if the victim scrubs their desktop computer. So it is foreseeable that we will have massive IoT attacks some day.
For any black hat, Volumio users will be attractive fraud targets ("If there are some users that pay for oxygen free cables more than my month's salary, i want their credit card data" (if this is true or not does not matter ;-)). I'll spare the details but from there it's script kiddies' work.
That said, we can have different estimate how difficult or likely attacks are, but one thing for sure: The main question is, what is between an attacker and Volumio root access. A user password is not the answer, as evidence shows too many user passwords are easy to dictionary-attack.
So let me strongly advise: If a user wants to SSH, teach them to ssh-keygen
. With great power comes great responsibility.
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?
Please, do NOT store the password - anywhere.
If you want to store something, compare it with a hash (which is the purpose of /etc/shadow), but never store the password.
@geek-merlin has some interesting points - for a physical device with a removable storage card, that process is possible, but if it's running on an embedded device (ie inside a box), or perhaps a VM, then that might not be the best approach for a generic IoT application like this one.
So, my opinion would be - for "normal" GUI operation:
I'm not sure how much administration via the "volumio" command line interface is done, but I presume that this needs to be done with the same elevated privileges, so it may be better to SSH into the device as a "normal" user (and obviosuly that can be via password or keys) and then use the sudo mechanism to elevate privileges.
Keeping it as standard as possible should be better for maintenance as well as end-user familiarity.
Thanks for the comment.
Ask the user for a password during installation (and there is NO default...)
That ignores the fact that user-provided passwords are not secure enough for root access.
but if it's running on an embedded device (ie inside a box), or perhaps a VM, then that might not be the best approach for a generic IoT application like this one.
Yes i get the point. I wonder if this is in prod anywhere, but let's assume it is. You can still get strongly secured root access if you want. Ask the user to upload an SSH key OR download a private key, done. Just one example.
Hi, I'm new to Volumio and whilst it's great piece of software this is a big issue. It's now 2021...is anything going to happen about this?
2022 and I just stumbled upon this when changing the volumio password. This actually makes me reconsider continuing using Volumio altogether feels like a very insecure architecture this way.
Disabled password login for now still a strange decision to do it this way.
The UK plan to make default passwords "illegal" (with fines...), so this issue will need to be addressed at some point: The Product Security and Telecommunications Infrastructure (PSTI) Bill
There's standard solutions for this problem, so I'm surprised by the conversations earlier in this thread asking about how to implement it...
I was waiting for v3 to stabilise (ie my hardware to be supported) before I had a look at this again... is it still the same on v3?!
I noticed that the plugins now needed a (free) volumio account before they could be installed, so I was hoping that the whole plug-in design had been revamped...
Come on, it's 2024 now... please don't tell me the Volumio products also have a default password? Such a great software otherwise, but completely unusable in a reasonably secure environment due to this issue... how disappointing.
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:
The log says:
I thought about resetting the password to the default, but the OS won't allow me:
I propose an information. Try a simple command first (
sudo echo 1
). If it fails, show a messageThe 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.