Hey TL;DR; This is a summary of why and how we currently do security elevation in PlainBox
We currently have two mechanisms for running commands as another user: 1) We can use sudo, the user is prompted for each shell command that we want to use. This is super annoying unless the user pre-configures sudo to work without a password 2) We can use pkexec to start plainbox-trusted-launcher-1 (once for each job). This can be white-listed by our insecure and secure policy files for PolicyKit It has a number of limitations and inefficiencies (it runs local jobs each time and caches nothing between each run). It is also unavailable for remote sessions (ssh into anything and run PlainBox) unless we enable broad access which makes it somewhat insecure. Why do we do it? Well, because some commands need to run as root. The real question is why do we do it in such a convoluted manner? A) We need to prevent anyone using a machine with python3-plainbox installed to run arbitrary commands as root. PlainBox is pre-installed on every desktop Ubuntu system and that would be a big security hole. The only way to do that is to ensure that every single command that we run as root came from a trusted component. This implies any system-wide installed package (since packages require root to install) is a potential source of trusted tests but al the files writable by normal users are not B) We need to support generated jobs, which in turn mean generated commands. We cannot compromise security requirements listed in A) in order to gain B) What doesn't work today (Roman numerals): I) We have big limits in what the trusted launcher understands. This is currently only one-level of local jobs. We'd like to support all the things that normal jobs support (templates). This is complex as it pulls in a lot of the code from PlainBox into the trusted launcher program. All such code needs to be written with security in mind. To put this into perspective security issues related to setuid programs were tied to issues as simple as printing user supplied string to stdout. Security is *HARD* to get right. II) We cannot reliably kill jobs started as another user (this is the long-lived backstabber story that I've started researching a while ago). This also includes runaway processes that may have been forked from the initial process we've started. III) The way we are using policykit is really not the intended way. Typically trusted helpers that *always* run as root (started via DBus or on boot, for example) are available and PolicyKit is used to mediate access from untrusted user processes to services exposed by the trusted helpers. Trusted helpers can then ask PolicyKit if access should be granted or not. We on the other hand use pkexec which allows us to run a shell command as root. This has insufficient granularity (we don't want to compromise A) so we have resorted to implementing our own launchers that only use pkexec to gain root initially, but then do additional checks to disallow arbitrary commands from being started. In effect we have numerous issues with things like passwords prompts being asked over and over. IV: Support of phablet environment with additional sandboxing and no clear way to use PolicyKit is unclear. In general we can assume it doesn't work. In the next message I'll summarize what we need and how we can work on plainbox-trusted-launcher-2 to address the shortcomings listed here. Thanks ZK -- Mailing list: https://launchpad.net/~checkbox-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~checkbox-dev More help : https://help.launchpad.net/ListHelp
