checkbox-dev team mailing list archive

[Zygmunt Krynicki <zygmunt.krynicki@xxxxxxxxxxxxx>]

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