[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZCSQiSn/4nRls/e+@tautology.pseudorandom.co.uk>
Date: Wed, 29 Mar 2023 20:24:57 +0100
From: Simon McVittie <smcv@...ian.org>
To: oss-security@...ts.openwall.com
Subject: Re: polkitd service user privilege separation
On Wed, 29 Mar 2023 at 15:34:50 +0200, Johannes Segitz wrote:
> Since the user owns the directory it's easy to escalate from user polkitd
> to root.
On one hand, yes. This makes the privilege separation not actually very
practically useful.
On the other hand, the entire point of polkit is to answer requests from
privileged system services, of the form:
[smcv] wants to [turn off wifi], should I allow this?
(where the parts inside square brackets are examples/placeholders), and
many of the things you can do with those requests are effectively already
root-equivalent. In particular, if you have the pkexec tool installed, the
whole point of that tool is that it's setuid root and makes requests like:
[smcv] wants to [run as root: mkdir /pwned], should I allow this?
and it is already trusting the polkitd process, running as the polkitd
user, to return "yes" or "no" according to the system's security policy.
> This demonstration caused some confusion in the original report to
> upstream. The POC is here to demonstrate the issue, not how real world
> exploitation would work. A real world exploit would rely on another
> vulnerability to be able to act as polkitd and then use the issue outlined
> here to escalate privileges.
Let's suppose you're able to act as the polkitd user as a result of a
vulnerability. Wouldn't it be easier to get root (or more generally,
permission to do a privileged thing) by tracing, replacing or otherwise
subverting the polkitd process?
In particular, if the vulnerability you're exploiting is arbitrary code
execution in the polkitd process (which is normally the only thing
running as uid polkitd), then you already have the ability to choose
how polkitd answers those requests; and if you have that, then as an
attacker, you've already won, because you can send a request that will
make you root-equivalent (for example from pkexec) and then coerce the
polkitd process into answering "yes, that's fine".
polkitd can only be either trusted or untrusted, we can't have it both
ways. I think the main thing that's wrong here is the documentation that
claims that the privilege separation is meaningful.
smcv
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
