Re: polkitd service user privilege separation

[Johannes Segitz <jsegitz () suse de>]

On Wed, Mar 29, 2023 at 08:24:57PM +0100, Simon McVittie wrote:
> On Wed, 29 Mar 2023 at 15:34:50 +0200, Johannes Segitz wrote:
> > 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?

yes, that's what I've mentioned in my report

.=====
| If you can act as the polkitd user you can also likely influence the polkit
| daemon and gain root this way, so this just makes it (a lot) easier to
| exploit.
`=====

For me it's easier to just write a file instead of subverting the process.

> 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.

I agree. That's was also my main concern why I wrote this. For any other
setup I would have requested a CVE for this, but here the permissions just
make it easier to get root, but aren't really a security boundary. But the
documentation makes it sound as if the polkitd user is a security boundary,
which it isn't.

Johannes
-- 
GPG Key                EE16 6BCE AD56 E034 BFB3  3ADD 7BF7 29D5 E7C8 1FA0
Subkey fingerprint:    250F 43F5 F7CE 6F1E 9C59  4F95 BC27 DD9D 2CC4 FD66
SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nürnberg, Germany
Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
(HRB 36809, AG Nürnberg)

Attachment: signature.asc
Description: Digital signature