Removing need for passwordless sudo for OSMC user

yknivag · 22 August 2016 11:12

Anything which allows unlimited passwordless privilege escalation for a user with a valid shell is a major security hole.

It is for this very reason that software like Apache starts as root and then downgrades itself to a user with no shell defined.

Kodi really ought to work in the same way but that isn’t something OSMC can control, I know. But limiting passwordless privilege escalation to only the commands required would improve the situation in the interim.

I’m intrigued by your last line @sam_nazarko any more details? Or do we have to wait for the official announcement?

sam_nazarko · 22 August 2016 11:22

Not really.There are dozens of other ways to escalate to a privileged shell anyway. You should always be wary of what you install on your system.

Passworded sudo does not protect against this. At best it gives users a moment to think about what they’re doing and guards their system from brief moments of being unattended.

And passwordless sudo is only granted for the OSMC user, so for example, one cannot escalate this way.

Getting the balance right can be tricky but I think we have it right.

We could probably move back to a passworded sudo mechanism by changing the watchdog script for Kodi. We can set CAPS via systemd and rework the script, but this is low on the list. Kodi doesn’t really need sudo rights. This is where it’s used:

github.com

osmc/osmc/blob/master/package/mediacenter-osmc/patches/rbp2-watchdog#L87


      
                  dialog --backtitle "Package configuration" --title "OSMC Update" --infobox "\n         Updating the list of available OSMC packages..." 5 71 > /dev/tty1
                  err=$(apt-get -qq update); if [ -n "$err" ]
                  then
                          dialog --backtitle "Package configuration" --title "OSMC Update" --infobox "The following errors occured while searching for new packages:\n\n${err}\n\nContinuing in 20 seconds..." 0 0 > /dev/tty1
                          sleep 20
                  fi
                  systemctl start manual-update
                  exit 0
                  ;;
          esac
          
          if [ ! -e /var/run/fb_resolution ]; then
          	/bin/fbset | grep geometry | awk '{print "-xres "$2" -yres "$3" -vxres "$4" -vyres "$5}' > /var/run/fb_resolution
          fi
          
          if [ $root_space -lt 100 ]; then
          	set_font
          	dialog --infobox "\n            WARNING! Free disk space remaining is only ${root_space}MB.\n\nKodi will be unable to start if disk space is completely exhausted. Please free sufficient disk space as soon as possible. Continuing in 10 seconds..." 8 80 > /dev/tty1
          	sleep 10
          fi

But then you need to think about how we allow changes to hostname, changes to timezone and other system settings. This is added by OSMC, and it’s not easy to make these system changes without temporarily elevating permissions.

I’ll accept a PR to change the behaviour, if you’re willing to work on it.

It’s not as interesting as you think. Just a standard sandboxing mechanism. The attack surface is very low currently, after the changes it should be non-existent.

yknivag · 22 August 2016 11:35

L87 of this script doesn’t elevate to root. It is using sudo to switch from whichever user is running the script to the user osmc. What user does this script run as? root?

Appreciate it is more difficult for amending system settings but I’m sure it is possibe.

I’d be happy to try. Do you have details of where sudo is used for escalation purposes?

sam_nazarko · 22 August 2016 11:46

I’m showing you that the script starts as root in systemd, then we switch user. You can trivially change the user in the systemd unit, but then you’ll need to take care of some things. Most significantly.

Ensure that apt-pkg runs as a privileged context in the add-on [1]
Ensure hostname / timezone updates can be made as a regular user [2]
Ensure updater (manual-update) segment can run [3]

Not actually that bad. This won’t protect against the many other ways of escalating privileges though.

Allowing apt-pkg to run as OSMC user will allow access to the entire filesystem.
Allowing hostname / timezone / updates requires access to files in /etc
Ensuring manual update can run as OSMC has two potential issues:
- APT can access entire filesystem again, writing where and what it wants
- You would have to allow OSMC to have systemctl stop/start control which introduces problems of its own.

What this change does, is shift the OSMC user from requesting privileges to granting them unconditionally. This is inherently more dangerous in my eyes, as the former can be controlled more appropriately with policy.

[1] osmc/package/mediacenter-addon-osmc/src/script.module.osmcsetting.updates at master · osmc/osmc · GitHub
[2] osmc/package/mediacenter-osmc/patches at master · osmc/osmc · GitHub (see all series)
[3] See systemctl start manual-update in watchdog script.

Splitting this to a new topic.

yknivag · 22 August 2016 11:53

Thanks for the information. I’ll have a look and try and get my head around how to accomplish the updates and settings changes and will come back to this thread with the results in due course.

Thanks for splitting it off too and apologies for hijacking the other thread.