Hi
I noticed that the osmc user now default to having the sudo NOPASSWD permission (let’s say shortly, is root).
Isn’t that a huge security issue ?
Does it mean that all kodi plugins have access to root permission ?
Is it possible to limit the sudo to the used commands (I guess apt-get upgrade) ?
Thanks
This has not changed, OSMC has always had no password for sudo for the osmc user from day one.
Unfortunately this cannot be changed because there are numerous locations throughout the system where we rely on being able to escalate to root, and these situations cannot be scripted if there is a password.
Kodi itself must be able to run some commands as root (via Sudo) for a number of tasks including: setting system timezone, modifying files on /boot such as config.txt (Pi config and overclock modules in My OSMC) read the system journal (log uploader in My OSMC) etc.
There are many scripts and services that rely on the use of sudo as well. Those are just a few examples off the top of my head but there are many others.
We are not trying to make a super secure internet facing server here, this is a single purpose mediacenter designed to be used on a home network, behind a firewall. You can run additional services on it (since at it’s heart it is just Debian) but you shouldn’t assume that you have a high degree of security or isolation between the different services running on the system.
In theory a rouge addon written to use sudo could get root access, but other than mess up your system, what is it going to do with it ? Even without root it could still screw up your Kodi install totally. (Addon’s can write anywhere with the permission of the user Kodi runs as - Kodi does no file system sandboxing for addons)
BTW, if you think this is insecure you should try OpenElec - all processes on the system including Kodi run as root and you cannot even change the root password…
Hi
Just to clarify, this was really a question and not a critic. I wondered if it was a mistake or if there were strong reasons to do it.
I understand that OSMC is designed as mediacenter black box, and that in case of a security problem, it can be wiped out.
You can still do bad things by having root access to a linux box on a local network.
You could (as really far fetched example) install a DHCP server and name yourself gateway to man in the middle every internet connection.
So for me, it would be an improvement to whitelist the commands that can be run without password (I manually did that in my OSMC installation. I did not run in any problem yet, but I guess I will have to run manually some commands).
It will be especially true when Ocelot will be released.
Again, thank you for the work on OSMC. It is a great application.
Hi,
I appreciate you may have some concern about our use of NOPASSWD. It comes up from time to time, so I thought I’d address it properly.
Yes, one can escalate privileges – but the other alternative would be to run Kodi as root, which would achieve the same goals.
Ways of securing your system:
If Kodi was running as regular user and sudo required a password, and I, an addon developer, wanted to gain root privileges, without knowing the password, there’s a dozen ways I could think of doing it.
alias sudo=$(read password)Yes – have a search. This is done on most systems so normal users can reboot and shutdown without needing to sudo.
I can’t go in to detail about Ocelot at this time, but it leverages an isolation technology that is coming to OSMC soon. Kodi addons are also far more likely to change things they shouldn’t: ‘advancedsettings.xml’ for example is modified by some addons for the pursuit of performance. By the end of the year, we should have a way of preventing addons modifying outside of ~/.
Sam
Thanks for these elements.
I will config my sudo and wait for the long term solution later this year.
Thanks
Just to clarify, we are not removing the NOPASSWD later this year. We are securing components from abusing this privilege.
Sam
Hi! Thanks for a great mediacenter and an excellent way to put the Rpi2’s hardware to good use!
It might be something uncommon that I’m after, but I am using my Rpi2 as a regular Debian machine with X, vim, python, compilers and whatnot, as well as for entertainment. I’ve put the OSMC packages on my Jessie system and with a bit of gentle encouragement everything works fine. Great!
Except: I would like to start Kodi without it requesting my password for the purpose of gaining root privileges. I don’t want it to be capable of changing anything on the system at all, I can manage my debian perfectly fine outside OSMC. This includes packages, timezones, everything.
The account that I use to log in already is a member of ‘input’, ‘audio’ and ‘video’ and as such I can run all the HW accelerated demos in /opt/vc/bin as well as play audio and access the mouse. Simply said, as far as I know this account has all the privileges needed to run OSMC’s excellent build of KODI /for my use case/, which is playing media from youtube, free-to-air TV and already mounted filesystems.
This account also is in sudoers (by virtue of being a member of the ‘sudo’ group), but with a password: while I want to have the privileges, I want to know when something needs them.
And alas, when I run ‘kodi’ from a nice launcher icon, this fails, because it insists on running a command from a shell with sudo. I can only start kodi from a xterm and enter my password. After that everything works just absolutely perfectly.
Is there any way I can tell kodi not to bother even trying to get sudo, and have it just try to access the /dev/ nodes it needs anyway?
In short: I don’t need kodi to have root, I don’t want to use an extra account, I have all the permissions on the account that Kodi and I need, and I don want to enter a password in a shell to start watching TV.
Any tips?
Thanks!
Emile.
Not at this time. Unfortunately the only times we need to use ‘sudo’ is to move some files in to directories owned by root (timezone for example). I will consider moving to setuid approach in the future.
The temporary solution is to enable NOPASSWD only for /usr/lib/kodi/kodi.bin.
Sam
I really love OSMC. It turns my raspi 3 into a multifunctional multimedia station. BUT giving the osmc user the possibility to run any command as root just turns my OSMC into a trojan horse. Calling it just a ‘bad style’ is not enough. Its the worst you can do with a linux box. ANY kodi plugin could basically takeover the box without any notice. It renders ANY security concept of linux just useless. Any serious system copied the way linux does user isolation during the past years (android, windows, you name it).
If you really need root for some tasks then there is the SUID bit. With it you can give the OSMC user the permission to run certain things like ‘reboot’. Using it you can limit root access to certain very specific tasks. If you have more complex things then put it into a bash-script make it only root-writeable and add the sticky bit to it.
I will gladly assists to fix that absolute NO-GO in your ‘security’ concept, but this NEEDs to be fixed unless your intend is to build up a trojan horse or bot net …
PLEASE FIX THIS! This is not the idea of linux. This is a ‘security concept’ of the nineties and the same level as windows xp or worse. And finally: it is COMPLETLY unnecessary!!!
In doubt, bring up ANY problem or situation where you think you cannot omit having root permissions and we will find a way howto fix this in a non-dangerous way.
hang loose
m.
I will quickly point out what needs to be fixed:
This is where you did your HACK:
filesystem/common/funcs.sh: # Adds ‘osmc’ to sudoers with no password prompt
filesystem/common/funcs.sh: mkdir -p ${1}/etc/sudoers.d
filesystem/common/funcs.sh: echo “osmc ALL= NOPASSWD: ALL” >${1}/etc/sudoers.d/osmc-no-sudo-password
filesystem/common/funcs.sh: echo “Defaults !secure_path” >${1}/etc/sudoers.d/osmc-no-secure-path
filesystem/common/funcs.sh: chmod 0440 ${1}/etc/sudoers.d/osmc-no-sudo-password
filesystem/common/funcs.sh: chmod 0440 ${1}/etc/sudoers.d/osmc-no-secure-path
These are the root issues which need to be fixed:
package/mediacenter-osmc/patches/all-040-Ensure-that-Kodi-devicename-reflects-etc-hostname.patch:+ system("/usr/bin/sudo /bin/mv /tmp/hostname /etc/hostname");
package/mediacenter-osmc/patches/all-040-Ensure-that-Kodi-devicename-reflects-etc-hostname.patch:+ system("/usr/bin/sudo /bin/hostname -F /etc/hostname");
package/mediacenter-osmc/patches/rbp1-watchdog: sudo -u osmc $KODI --standalone -fs --lircdev /var/run/lirc/lircd; CODE="$?"
package/mediacenter-osmc/patches/vero2-watchdog: sudo -u osmc $KODI --standalone -fs --lircdev /var/run/lirc/lircd; CODE="$?"
package/mediacenter-osmc/patches/vero-watchdog: sudo -u osmc $KODI --standalone -fs --lircdev /var/run/lirc/lircd; CODE="$?"
package/mediacenter-osmc/patches/all-007-sync-timezone-from-mediacenter.patch:+ int res = system("/usr/bin/sudo /bin/mv /tmp/timezone /etc/timezone"); /* We need this to update a root owned file /
package/mediacenter-osmc/patches/all-007-sync-timezone-from-mediacenter.patch:+ asprintf(&command, “%s%s%s”, “/usr/bin/sudo /bin/cp /usr/share/zoneinfo/”, timezoneName.c_str(), " /etc/localtime.dpkg-new");
package/mediacenter-osmc/patches/all-007-sync-timezone-from-mediacenter.patch:+ system("/usr/bin/sudo /bin/mv /etc/localtime.dpkg-new /etc/localtime");
package/mediacenter-osmc/patches/vero2-057-add-reboot-to-android-option.patch:+ os.system("/usr/bin/sudo /sbin/reboot androidv2")
package/mediacenter-osmc/patches/rbp2-watchdog: sudo -u osmc $KODI --standalone -fs --lircdev /var/run/lirc/lircd; CODE="$?"
package/mediacenter-osmc/patches/atv-watchdog: sudo -u osmc xinit $KODI --standalone -fs --lircdev /var/run/lirc/lircd; CODE="$?"
package/mediacenter-addon-osmc/src/script.module.osmcsetting.remotes/resources/lib/remote_gui.py: subprocess.call([“sudo”, “mv”, ‘/var/tmp/blacklist-rc6.conf’, self.rc6_file_loc])
package/mediacenter-addon-osmc/src/script.module.osmcsetting.remotes/resources/lib/remote_gui.py: subprocess.call([“sudo”, “rm”, “-f”, self.rc6_file])
package/mediacenter-addon-osmc/src/script.module.osmcsetting.remotes/resources/lib/remote_gui.py: subprocess.call([‘sudo’, ‘ln’, ‘-sf’, self.remote_selection, LIRCD_PATH])
package/mediacenter-addon-osmc/src/script.module.osmcsetting.remotes/resources/lib/remote_gui.py: subprocess.call([‘sudo’, ‘ln’, ‘-sf’, original_target, LIRCD_PATH])
package/mediacenter-addon-osmc/src/script.module.osmcsetting.remotes/resources/lib/remote_gui.py: subprocess.call([‘sudo’, ‘systemctl’, ‘restart’, 'lircd_helper@’])
package/mediacenter-addon-osmc/src/script.module.osmcsetting.remotes/resources/lib/remote_gui.py: proc = subprocess.Popen([‘sudo’, ‘systemctl’, ‘restart’, 'lircd_helper@’])
package/mediacenter-addon-osmc/src/service.osmc.settings/resources/lib/osmc_walkthru.py: os.system("/bin/sudo /bin/systemctl disable ssh")
package/mediacenter-addon-osmc/src/service.osmc.settings/resources/lib/osmc_walkthru.py: os.system("/bin/sudo /bin/systemctl stop ssh")
package/mediacenter-addon-osmc/src/service.osmc.settings/resources/lib/osmc_walkthru.py: subprocess.call([‘sudo’, ‘rm’, ‘/tmp/NO_UPDATE’])
package/mediacenter-addon-osmc/src/service.osmc.settings/resources/lib/osmc_ubiquifonts.py: subprocess.call([“sudo”, “cp”, os.path.join(FONT_FOLDER, filename), alien_fonts_folder])
package/mediacenter-addon-osmc/src/service.osmc.settings/resources/lib/osmc_ubiquifonts.py: subprocess.call([“sudo”, “cp”, alien_font_xml, backup_file])
package/mediacenter-addon-osmc/src/service.osmc.settings/resources/lib/osmc_ubiquifonts.py: subprocess.call([“sudo”, “mv”, ‘/tmp/Font.xml’, alien_font_xml])
package/mediacenter-addon-osmc/src/service.osmc.settings/resources/lib/osmc_main.py: subprocess.call([‘sudo’, ‘mv’, ‘/tmp/walkthrough_completed’, ‘/walkthrough_completed’])
package/mediacenter-addon-osmc/src/service.osmc.settings/resources/lib/osmc_comms.py: subprocess.call([‘sudo’, ‘rm’, self.address])
package/mediacenter-addon-osmc/src/script.module.osmcsetting.networking/resources/lib/osmc_advset_editor.py: subprocess.call([‘sudo’, ‘cp’, loc, loc.replace(‘advancedsettings.xml’, ‘advancedsettings_backup.xml’)])
package/mediacenter-addon-osmc/src/script.module.osmcsetting.networking/resources/lib/osmc_advset_editor.py: subprocess.call([‘sudo’, ‘rm’, ‘-f’, loc])
package/mediacenter-addon-osmc/src/script.module.osmcsetting.networking/resources/lib/networking_gui.py: res = subprocess.check_call([‘sudo’, ‘chmod’, ‘777’, loc])
package/mediacenter-addon-osmc/src/script.module.osmcsetting.networking/resources/lib/osmc_systemd.py: subprocess.call([‘sudo’, ‘/bin/systemctl’, service_status, service_name])
package/mediacenter-addon-osmc/src/script.module.osmcsetting.networking/resources/lib/osmc_network.py: subprocess.call([‘sudo’, ‘mv’, ‘/tmp/cmdline.txt’, file_path])
package/mediacenter-addon-osmc/src/script.module.osmccommon/resources/lib/grablogs.py: ‘actn’: ‘sudo journalctl’,
package/mediacenter-addon-osmc/src/script.module.osmccommon/resources/lib/grablogs.py: os.popen(‘sudo cp -rf %s /boot/’ % TEMP_LOG_FILE)
package/mediacenter-addon-osmc/src/script.module.osmccommon/resources/lib/grablogs.py: os.popen(‘sudo cp -rf %s /boot/’ % TEMP_LOG_FILE)
package/mediacenter-addon-osmc/src/script.module.osmccommon/resources/lib/osmc_comms.py: subprocess.call([‘sudo’, ‘rm’, self.address])
package/mediacenter-addon-osmc/src/script.module.osmcsetting.logging/resources/lib/grablogs.py: ‘actn’: ‘sudo journalctl’,
package/mediacenter-addon-osmc/src/script.module.osmcsetting.logging/resources/lib/grablogs.py: os.popen(‘sudo cp -rf %s /boot/’ % TEMP_LOG_FILE)
package/mediacenter-addon-osmc/src/script.module.osmcsetting.logging/resources/lib/grablogs.py: os.popen(‘sudo cp -rf %s /boot/’ % TEMP_LOG_FILE)
package/mediacenter-addon-osmc/src/script.module.osmcsetting.updates/resources/lib/OSMC_Backups.py: subprocess.Popen([‘sudo’, ‘mv’, location, ‘/etc’])
package/mediacenter-addon-osmc/src/script.module.osmcsetting.updates/resources/lib/OSMC_Backups.py: res = subprocess.call([“sudo”, “mv”, ‘/tmp/fstab’, ‘/etc/fstab’ ])
package/mediacenter-addon-osmc/src/script.module.osmcsetting.updates/resources/lib/update_service.py: external scripts from the command line using sudo. The other script communicates with the update service using a socket file.
package/mediacenter-addon-osmc/src/script.module.osmcsetting.updates/resources/lib/update_service.py: subprocess.Popen([‘sudo’, ‘systemctl’, ‘start’, ‘manual-update’])
package/mediacenter-addon-osmc/src/script.module.osmcsetting.updates/resources/lib/update_service.py: subprocess.Popen([‘sudo’, ‘python’,’%s/apt_cache_action.py’ % libpath, action])
package/mediacenter-addon-osmc/src/script.module.osmcsetting.updates/resources/lib/update_service.py: subprocess.Popen([‘sudo’, ‘python’,’%s/apt_cache_action.py’ % libpath, ‘action_list’, action])
package/mediacenter-addon-osmc/src/script.module.osmcsetting.updates/resources/lib/update_service.py: subprocess.Popen([‘sudo’, ‘systemctl’, ‘restart’, ‘mediacenter’])
package/mediacenter-addon-osmc/src/script.module.osmcsetting.updates/resources/lib/update_service.py: subprocess.Popen([‘sudo’, ‘systemctl’, ‘start’, ‘manual-update’])
package/mediacenter-addon-osmc/src/script.module.osmcsetting.updates/resources/lib/update_service.py: os.system(‘sudo apt-cache clean’)
package/mediacenter-addon-osmc/src/script.module.osmcsetting.updates/resources/lib/update_service.py: subprocess.Popen([‘sudo’, ‘apt-get’, ‘autoremove’, ‘&&’, ‘apt-get’, ‘clean’])
package/mediacenter-addon-osmc/src/script.module.osmcsetting.updates/resources/lib/comms.py: subprocess.call([‘sudo’, ‘rm’, self.address])
package/mediacenter-addon-osmc/src/script.module.osmcsetting.updates/resources/lib/OSMC_HotFix.py: os.popen(‘sudo cp -rf %s /boot/’ % self.tmp_hfo_location)
package/mediacenter-addon-osmc/src/script.module.osmcsetting.services/resources/lib/service_selection_gui.py: os.system("sudo /bin/systemctl enable " + service)
package/mediacenter-addon-osmc/src/script.module.osmcsetting.services/resources/lib/service_selection_gui.py: os.system("sudo /bin/systemctl start " + service)
package/mediacenter-addon-osmc/src/script.module.osmcsetting.services/resources/lib/service_selection_gui.py: os.system("sudo /bin/systemctl disable " + service)
package/mediacenter-addon-osmc/src/script.module.osmcsetting.services/resources/lib/service_selection_gui.py: os.system("sudo /bin/systemctl stop " + service)
package/mediacenter-addon-osmc/src/script.module.osmcsetting.services/resources/lib/service_selection_gui.py: p = subprocess.call([“sudo”, “/bin/systemctl”, “is-active”, service])
package/mediacenter-addon-osmc/src/script.module.osmcsetting.services/resources/lib/service_selection_gui.py: p = subprocess.call([“sudo”, “/bin/systemctl”, “is-enabled”, service])
package/mediacenter-addon-osmc/src/script.module.osmcsetting.pioverclock/resources/osmc/OSMCSetting.py: subprocess.call([“sudo”, “mv”, ‘/var/tmp/config.txt’, config_location])
package/mediacenter-addon-osmc/src/script.module.osmcsetting.pi/resources/lib/config_editor.py: subprocess.call([“sudo”, “cp”, self.config, ‘/home/pi/’ ])
package/mediacenter-addon-osmc/src/script.module.osmcsetting.pi/resources/lib/config_editor.py: subprocess.call([“sudo”, “mv”, ‘/home/pi/config.txt’, ‘/home/pi/config’ + suffix + ‘.txt’ ])
package/mediacenter-addon-osmc/src/script.module.osmcsetting.pi/resources/lib/config_editor.py: subprocess.call([“sudo”, “mv”, tmp_loc, self.config ])
package/mediacenter-addon-osmc/src/script.module.osmcsetting.pi/resources/osmc/OSMCSetting.py: subprocess.call([“sudo”, “mv”, ‘/var/tmp/config.txt’, self.config_location])
package/mediacenter-addon-osmc/src/script.module.osmcsetting.pi/resources/osmc/OSMCSetting.py: subprocess.call([“sudo”, “mv”, ‘/var/tmp/config.txt’, self.config_location])
package/diskmount-osmc/files/lib/systemd/system/udisks-glue.service:ExecStartPre = /bin/bash -c "sudo rmdir /media// 2>/dev/null; time udevadm settle; exit 0"
package/diskmount-osmc/files/etc/udisks-glue.conf: if sudo /usr/bin/net usershare add “$(basename “%mount_point”)” “%mount_point” “Auto-mount Volume” “$(hostname)\osmc:f”
package/diskmount-osmc/files/etc/udisks-glue.conf: sudo /usr/bin/net usershare delete “$(basename “%mount_point”)”
package/diskmount-osmc/files/etc/udisks-glue.conf: if sudo /usr/bin/net usershare add “$(basename “%mount_point”)” “%mount_point” “Auto-mount Volume” “$(hostname)\osmc:f”
package/diskmount-osmc/files/etc/udisks-glue.conf: sudo /usr/bin/net usershare delete “$(basename “%mount_point”)”
package/diskmount-osmc/files/etc/udisks-glue.conf: sudo chmod a+rwx “%mount_point” 2>/dev/null
package/diskmount-osmc/files/etc/udisks-glue.conf: if sudo /usr/bin/net usershare add “$(basename “%mount_point”)” “%mount_point” “Auto-mount Volume” “$(hostname)\osmc:f”
package/diskmount-osmc/files/etc/udisks-glue.conf: sudo /usr/bin/net usershare delete “$(basename “%mount_point”)”
package/diskmount-osmc/files/etc/udisks-glue.conf: if sudo /usr/bin/net usershare add “$(basename “%mount_point”)” “%mount_point” “Auto-mount Volume” “$(hostname)\osmc:r”
package/diskmount-osmc/files/etc/udisks-glue.conf: sudo /usr/bin/net usershare delete “$(basename “%mount_point”)”
package/diskmount-osmc/files/etc/udisks-glue.conf: if sudo /usr/bin/net usershare add “$(basename “%mount_point”)” “%mount_point” “Auto-mount Volume” “$(hostname)\osmc:r”
package/diskmount-osmc/files/etc/udisks-glue.conf: sudo /usr/bin/net usershare delete “$(basename “%mount_point”)”
package/diskmount-osmc/files/etc/udisks-glue.conf: echo 1024 | sudo tee “/sys/dev/block/$device/queue/read_ahead_kb” > /dev/null
package/diskmount-osmc/files/etc/udisks-glue.conf: sudo /sbin/hdparm -S 240 %device_file
package/base-files-osmc/files/etc/profile.d/101-apt-update.sh: sudo apt-get update >/dev/null 2>&1
package/base-files-osmc/files/etc/profile.d/103-generate-locale.sh: sudo sed -e “s/# $LANG/$LANG/” -i /etc/locale.gen
package/base-files-osmc/files/etc/profile.d/103-generate-locale.sh: sudo /usr/sbin/locale-gen ${LANG}
package/base-files-osmc/files/usr/bin/apt-get:# even with our sudo preservation hack, we can’t set this up as a profile.d function and export it
results where found by running:
egrep -R sudo * 2>/dev/null | grep -v Pesudo | grep -v psudo | grep -v build.sh | grep -v Makefile | grep -v README | grep -v Depends | grep -vi Jenkins | grep -v prerm | grep -v toolchain | grep -v kernel | grep -v installer | grep -v backports
Hi @maze735,
I agree with some of what you have said. Having a user with sudo privileges and not requesting the password when they’re used is not particularly good practice.
However I don’t quite agree with your doomsday prophecy - if you set a strong password for the osmc user and limit inbouond connections from the internet then it is very unlikely that your OSMC device will be hacked in any way. Under normal operation there is no need for an OSMC device to accpet any incoming connections and a stateful firewall (contained in even the poorest domestic ADSL routers these days) will suffice to limit that threat.
On the other hand if you open ports and forward that traffic to an OSMC device then you need to secure it. Setting a strong password for the OSMC user should limit the chances of accessing that user and it’s elevated priveleges (just as you would set a strong password for the root user on a distribution that has root login enabled.
Six months or so ago I raised this issue myself with Sam (my background is IT Security) and spent a long time looking at the prospect of fixing it. I came to the conclusion that this was far from trivial whilst maintaining a sensible user experience. Yes you could limit sudo for each of the commands needed but that configuration would require ongoing maintenance and there would be a large number of such instances as this would have to cover every add-on which needed to make system changes and also any future development of add-ons. Alternatively it would be necessary to implement a sort of kodi version of gksudo and request a password every time system settings were changed or upgrades performed - this would be counter productive as it would encourage users to choose a simple password as most interact only with a simple remote control.
In all security decisions there has to be a trade off between risk, maintainability and usability. As the risk in normal operation with no incoming traffic is very low then there is little to be gained by reducing maintainability and usability. If the user decides to increase the risk (by hosting web facing services) then the user also needs to look at improving the security.
My lengthy research after raising this myself has led me to the conclusion that there is very little to be gained by fixing it that can’t simply be gained by setting a strong password and creating a second user for normal CLI access (which is the defacto way of treating an exposed root user in all Linux ditributions that expose a root enabled account.
thanks for your detailed answer! It’s not a doomsday prophecy, its about building a state of the art linux system.
Kodi definetely does not need root. I had it running on my unrooted(!) amazon fire TV stick without and drawbacks.
Building a trojan horse or botnet does not require any open port or anything like that. Simple internet access of the OSMC box is totally sufficient. I point it quickly out for you, how “Eve” would do it:
And we are not talking about developing a complicated virus using any complicated vulnerabilities. We are talking about a simple “script” or basic program which just uses the sudo-hole in the fashion any other program simply uses the system. Simply forwarding a shell to the command and controll server is written in a couple of hours and exposes the whole system and network.
And now for the implementation of the fix:
I DID NOT suggest not to run any system maintainance as root. Script or updates or whatever can be run as root or with SUID root scripts. Why not? As long as they are triggered from other basic system services, like a update deamon or cron job or whatever. So what.
BUT, it just cannot be that simple kodi plugin can issue a “system( sudo /home/osmc/.kodi/plugin/name/trojan.bin)” !!!
Unless you can check the integrity of all published kodi plugins…
m.
I’m sorry but
is purely a doomsday prophecy.
Your argument about random plugins makes no sense, the same could be true with or without sudo - you could create such a scenario directly in python with a plugin. There is no need for a plugin to isntall a daemon as kodi is running (and thus the plugin is running all the time).
Furthermore, the first rule of computer security is never install a program/plugin/app/software (call it what you will it’s all the same thing) that you don’t trust. No matter how much security you put in, if you can convince someone to install the software themselves then all hope is gone. If sudo wasn’t there and was needed by a corrupt plugin, then they could simply have users run an installation script which punches the necessary hole, most people aren’t linux savvy and will copy any command from a how-to without any knowledge of what it does.
Do you have any actual credible evidence of an army of OSMC powered bots?
SUID script ? You are aware that Linux ignores the SUID bit on interpreted executable, eg scripts ? And that the idea of SUID scripts is generally frowned on and considered insecure ?
I take it you have not tried OpenElec or LibreElec then ? Kodi runs as root and you cannot change the root password. 
In fact from memory everything on the system runs as root. (It’s been a while since I last ran it) Have you spoken to them about this ?
This is good advice if you want to run something besides Kodi and have some degree of isolation - the additional user account won’t have nopasswd SUID rights.
Your analysis of the complexity of achieving all current functionality without nopasswd SUID is spot on - it’s theoretically possible but a lot of work and difficulty as well as a maintenance headache.
While Kodi itself doesn’t need root permissions as such (although it does need capabilities enabled to allow the web server to run on the default port 80, and does require write permissions to various /sys paths to control and configure the video and audio hardware of the device) parts of the OSMC user interface like My OSMC (which is just a Kodi addon) do need to perform many root tasks, such as stopping and starting services to allow you to perform some “system administration” tasks via the Kodi GUI.
If the My OSMC addon has rights to stop and start services then by definition so does any other Kodi addon, if it knew to do so. Not an easy problem to solve while maintaining all existing functionality…
I would also add that OSMC is not designed to be a general purpose “multi-user” system in the traditional sense with multiple people logging into the device and each having their own space, or a server providing services to multiple customers such as a web host.
There is no other “user” of the box that you are trying to partition your data from. You, as the user of Kodi (and thus running as the OSMC user) are expected to be the owner of the box, and by definition you have complete control over the box, including being able to shut it down and edit cmdline.txt on the sd card to boot directly to a root shell if you really wanted to!
It is designed more as a single user appliance. Running Kodi and most other software as a non-root user in osmc does still afford protection against accidental exploitation of root permissions (since you must explicitly specify sudo in a command, so scripts that don’t normally need root access are protected against accidental screwups like rm -rf as one example) but does not of course protect against malicious use of sudo to gain root access.
However given the scope of the device, the data it contains and the single user nature of it, gaining root access doesn’t actually give you that much more power.
If you have an “untrusted” service that you would like to run in addition to Kodi and you want some degree of isolation, you can create another user account and run it under that account without nopasswd sudo rather than running it under osmc.
I think its easy to be critical of the security of something like OSMC because all the source code and scripting etc is out in the open - however there are loads of linux based devices with closed access such as IP cameras, routers and so on which do things such as blatantly run all processes as root, have deliberate back door passwords etc. In essence they are vastly more insecure and rely completely on security by obscurity - until someone finds a way in and discovers the horrors that lie within.
Call it what you want. Every linux guy who knows a little bit about security would consider the problem a major security hole, which is also very easy to avoid.
The example with random plugins makes perfect sense. Are you reading the python code of every plugin before you install it? I try to cope with as little plugins as possible, but I have some (like for subtitles) installed.
As you point out, it is even easier to exploit the hole by just having a python script as plugin running. And there is, of course a big difference if the plugin can access root rights or not. Usually the script will run in the same user context as its parent (osmc). That’s why any server on a linux system has a special user running the service (a httpd user for apache, a ftpd user wsftpd). Any exploit can then never gain more permissions than the users has which is running the service, in our case the kodi binary. But OSMC completely throws over that easy and save and common concept.
The security concepts we see today is also based on kind of ring of trust.
I see at least 3 rings in the case of OSMC:
Of course you trust the debian ring, everybody does. Then I can decide that I want to trust OSMC as these guys do a good job and the thing is still quite popular. But then there are third party plugins and other sources, whom intention I don’t know and which also have not necessarily a peer review of what they do. I definitely want to be careful with this ring! Having them run in only a normal user context is therefore a good compromise between security and kodi function.
And this is not my opinion this is just common sense with any linux system. Are you actually a developper for kodi?
Let me point out these solutions, as this is much more constructive than arguing about obvious things:
On easy solution would be to introduce another user like “kodi” which is not in the sudoers list. All stuff which needs to manipulate the system just stays in the “osmc” user context. Kodi itself will be run with limited rights and though be safe. This works very well for kodi on e.g. Amazon Fire TV.
Another easy solutions would be to give the “suid” bit to “/bin/systemclt” (for rebooting) and have some safe scripts for the tasks which I discover by a quick look, so far:
The scripts would have one or no argument. If it comes with arguments you would need to check that it e.g. consists of a sequence of [a-z][A-Z][0-9] to not introduce a backdoor into those scripts. This can most likely be done using bash and sed with a single line.
I could have almost implemented it in the time while writing these lines.
m.
and: I was not aware that scripts cant have suid, but that isnt really important because you can with the same effort build a 2 liner c-program which does the job. let me give you a proove of concept for this simple solutions.
Just name the the service you want to fix. Or lets just take the “updating the hostname” thing?
m
Have you looked at this list of things you can do with systemctl ? You might as well just give the user full root access than make systemctl suid. 
By the way, you don’t need root access to reboot or shutdown in osmc - it’s handled already via PolicyKit.
NOPASSWD is not a security feature. It never was and never will be. Even with this enabled, elevation to root is still possible on Linux.
Correct. Kodi has support for services. If a malicious adversary wanted to run a ‘trojan’, then a reverse netcat shell can be ran on any non-privileged port and does not require root access. From there, you could likely elevate privileges. Requiring a (commonly known) password for root access will not help this situation.
I very much doubt this. ‘Raspberry Pi kernels’ are not all the same. You’re not going to be able to inject a kernel module easily and have it run.
If you’re serious about removing the need for NOPASSWD, you can submit pull requests to GitHub. Here’s what needs to be done at a minimum to get the ball rolling:
We are already working on security improvements to OSMC. All help is appreciated.
This doesn’t make sense. Then you can just gain root with systemd units, and even create one to spawn a getty as root. Then you are just swapping out one security issue for another.
If you still want NET_CAP on Kodi.bin, you will also be able to bind a privileged network port anyway, regardless of whether you are root.
Thanks, finally we are taking about tec and not politics 
It looks like you are very aware of the backgrounds. Then why not fix it?
I think having a safe OSMC might even increase user acceptance.