CVE-2021-4034: why is pkexec still a thing?

[Adam Williamson]

Hi folks!

For anyone who hasn't seen it yet - there's quite a kerfuffle today
about a major security issue in polkit:

https://arstechnica.com/information-technology/2022/01/a-bug-lurking-for-...

turns out that ever since it was invented, `pkexec` has had a bug
allowing for local root privilege escalation. Which is...bad.

The issue and some of the comments around it prompted me to wonder -
why is `pkexec` still a thing? Particularly, why is it still a thing we
are shipping by default in just about every Fedora install?

My best recollection is that pkexec was kinda a kludge to allow us to
get rid of consolehelper: some apps weren't getting rewritten to the
Right Way of doing things under policykit, they still just wanted to
have the entire app run as root, and pkexec was a way to make that
happen.

But that was then, and this is now. Does anything in Workstation use
pkexec? Does anything in KDE use it? I'm pretty sure (at least I really
hope!) nothing in Server uses it. I don't think any of our
documentation recommends its use for interactive execution of things as
root (these days we tend to just specify `sudo` for that and assume the
install has an admin user).

Should we just split it out of the polkit package into a subpackage and
stop shipping the subpackage on those editions/spins at least? If
there's anything in other desktops still using it, it can grow a
dependency on the subpackage...

Am I forgetting some other reason we still need it?
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

[Adam Williamson]

On Wed, 2022-01-26 at 14:21 -0800, Adam Williamson wrote:
>  
>  Am I forgetting some other reason we still need it? 
BTW, bonus follow-up to this: as part of researching the background of
polkit, I noticed that we never actually entirely got done moving off
usermode :( There are still over a dozen packages in the distro that
require it:

anaconda-live-0:36.15-1.fc36.x86_64
beesu-0:2.7-40.fc35.x86_64
chkrootkit-0:0.55-3.fc35.x86_64
hddtemp-0:0.3-0.49.beta15.fc35.x86_64
mate-system-log-0:1.26.0-1.fc35.x86_64
mock-0:2.16-1.fc36.noarch
pure-ftpd-0:1.0.49-11.fc36.x86_64
setuptool-0:1.19.11-23.fc35.x86_64
subscription-manager-0:1.29.21-1.fc36.x86_64
system-config-rootpassword-0:1.99.6-25.fc35.noarch
system-switch-java-0:1.1.8-6.fc35.noarch
system-switch-mail-0:2.0.1-14.fc35.noarch
usermode-gtk-0:1.114-3.fc35.x86_64
vpnc-consoleuser-0:0.5.3-42.svn550.fc35.x86_64
xawtv-0:3.107-5.fc35.x86_64

the tracker bug for the conversion is still hanging out at
https://bugzilla.redhat.com/show_bug.cgi?id=502765 , never quite got
closed. Don't suppose anyone wants to see whether this could be pushed
over the line...?
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

[Kevin Kofler]

Adam Williamson wrote:
>  But that was then, and this is now. Does anything in Workstation use
>  pkexec? Does anything in KDE use it? 
Not sure. KDE stuff SHOULD use kdesu for this purpose, if it needs to run as 
root at all to begin with. But some application developer might have 
preferred pkexec in the name of portability to other desktops. Of course, 
the proper thing to do would be to use KAuth, or PolicyKit directly.

        Kevin Kofler

[Milan Crha]

On Wed, 2022-01-26 at 15:18 -0800, Adam Williamson wrote:
>  There are still over a dozen packages in the distro that
>  require it: 
	Hi,
the gnome-software also calls pkexec is some occasions, once when
external appstream data is used (not a thing in Fedora, as far as I
know) and when invoking fedora-third-party in some cases. There's no
hard require for it in the .spec file.
	Bye,
	Milan

[Peter Robinson]

>  BTW, bonus follow-up to this: as part of researching the background
> of
>  polkit, I noticed that we never actually entirely got done moving off
>  usermode :( There are still over a dozen packages in the distro that
>  require it:
>
>  anaconda-live-0:36.15-1.fc36.x86_64
>  beesu-0:2.7-40.fc35.x86_64
>  chkrootkit-0:0.55-3.fc35.x86_64
>  hddtemp-0:0.3-0.49.beta15.fc35.x86_64
>  mate-system-log-0:1.26.0-1.fc35.x86_64
>  mock-0:2.16-1.fc36.noarch
>  pure-ftpd-0:1.0.49-11.fc36.x86_64
>  setuptool-0:1.19.11-23.fc35.x86_64
>  subscription-manager-0:1.29.21-1.fc36.x86_64
>  system-config-rootpassword-0:1.99.6-25.fc35.noarch
>  system-switch-java-0:1.1.8-6.fc35.noarch
>  system-switch-mail-0:2.0.1-14.fc35.noarch
>  usermode-gtk-0:1.114-3.fc35.x86_64
>  vpnc-consoleuser-0:0.5.3-42.svn550.fc35.x86_64
>  xawtv-0:3.107-5.fc35.x86_64
>
>  the tracker bug for the conversion is still hanging out at
>  https://bugzilla.redhat.com/show_bug.cgi?id=502765 , never quite got
>  closed. Don't suppose anyone wants to see whether this could be pushed
>  over the line...? 
Most of those appear to be legacy and shouldn't be parts of key
blocker artifacts. I'm surprised that things like subscription-manager
hasn't been moved but in the Fedora context it's basically irrelevant.
Interestingly I fixed/cleaned up usbview recently which also used it.

[Matthew Miller]

On Wed, Jan 26, 2022 at 02:21:19PM -0800, Adam Williamson wrote:
>  My best recollection is that pkexec was kinda a kludge to allow us
> to
>  get rid of consolehelper: some apps weren't getting rewritten to the
>  Right Way of doing things under policykit, they still just wanted to
>  have the entire app run as root, and pkexec was a way to make that
>  happen. 
That sounds right to me too. I mean not "right", but what happened.

I'd also love to get rid of the entire javascript configuration system.
That's... more CVEs waiting to happen.


-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Neal Gompa]

On Thu, Jan 27, 2022 at 1:05 PM Matthew Miller <mattdm(a)fedoraproject.org&gt; wrote:
>  On Wed, Jan 26, 2022 at 02:21:19PM -0800, Adam Williamson wrote:
>  > My best recollection is that pkexec was kinda a kludge to allow us to
>  > get rid of consolehelper: some apps weren't getting rewritten to the
>  > Right Way of doing things under policykit, they still just wanted to
>  > have the entire app run as root, and pkexec was a way to make that
>  > happen.
>
>  That sounds right to me too. I mean not "right", but what happened.
>
>  I'd also love to get rid of the entire javascript configuration system.
>  That's... more CVEs waiting to happen.
>  
Some years ago, Ikey Doherty made a patchset to allow polkit to use
regular config files instead of JavaScript[1]. He did it in Solus[2],
but the discussion upstream petered out and nothing happened. Maybe we
could talk to Ikey about reviving it and integrating it upstream
finally?

[1]: https://lists.freedesktop.org/archives/polkit-devel/2017-October/000547.html
[2]: https://dev.getsol.us/T4824



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Christian Stadelmann]

Hi Adam,

thanks for asking this question!

Due to similar horrible bugs before, I have uninstalled sudo and friends, but I never
managed to uninstall pkexec due to those dependencies.

>  The issue and some of the comments around it prompted me to wonder -
>  why is `pkexec` still a thing? Particularly, why is it still a thing we
>  are shipping by default in just about every Fedora install? 
Probably because gnome-initial-setup requires it [1]?

>  Does anything in Workstation use
>  pkexec? 
On my system [2], apart from gnome-initial-setup, only Grsync references pkexec in its
source code [3].

>  Should we just split it out of the polkit package into a subpackage
> and
>  stop shipping the subpackage on those editions/spins at least?  
+1 on that pragmatic solution!

[1]
https://gitlab.gnome.org/GNOME/gnome-initial-setup/-/blob/master/gnome-in...

[2] I used `rpmreaper polkit` and walked through the source code of all the 14 direct
dependencies of polkit and searched them for `pkexec`. GNOME shell mentions it a lot in
source code but I cannot find it being called.
[3] https://sourceforge.net/p/grsync/code/HEAD/tree/trunk/grsync/src/callbacks.c

[Ondřej Holý]

Hi Adam,

also gvfs uses pkexec currently to start gvfsd-admin backend...

Regards

O.

st 26. 1. 2022 v 23:39 odesílatel Adam Williamson
<adamwill(a)fedoraproject.org&gt; napsal:
>  Hi folks!
>
>  For anyone who hasn't seen it yet - there's quite a kerfuffle today
>  about a major security issue in polkit:
>
>
> https://arstechnica.com/information-technology/2022/01/a-bug-lurking-for-...
>
>  turns out that ever since it was invented, `pkexec` has had a bug
>  allowing for local root privilege escalation. Which is...bad.
>
>  The issue and some of the comments around it prompted me to wonder -
>  why is `pkexec` still a thing? Particularly, why is it still a thing we
>  are shipping by default in just about every Fedora install?
>
>  My best recollection is that pkexec was kinda a kludge to allow us to
>  get rid of consolehelper: some apps weren't getting rewritten to the
>  Right Way of doing things under policykit, they still just wanted to
>  have the entire app run as root, and pkexec was a way to make that
>  happen.
>
>  But that was then, and this is now. Does anything in Workstation use
>  pkexec? Does anything in KDE use it? I'm pretty sure (at least I really
>  hope!) nothing in Server uses it. I don't think any of our
>  documentation recommends its use for interactive execution of things as
>  root (these days we tend to just specify `sudo` for that and assume the
>  install has an admin user).
>
>  Should we just split it out of the polkit package into a subpackage and
>  stop shipping the subpackage on those editions/spins at least? If
>  there's anything in other desktops still using it, it can grow a
>  dependency on the subpackage...
>
>  Am I forgetting some other reason we still need it?
>  --
>  Adam Williamson
>  Fedora QA
>  IRC: adamw | Twitter: adamw_ha
>  https://www.happyassassin.net
>
>  _______________________________________________
>  desktop mailing list -- desktop(a)lists.fedoraproject.org
>  To unsubscribe send an email to desktop-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]...
>  Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

[Christian Stadelmann]

Hi Ondřej,

you wrote:
>  also gvfs uses pkexec currently to start gvfsd-admin backend...
The gvfs .spec file does not reflect that so it may fail on a system without polkit
installed. Is this by intention? If no, I've created a PR: 
https://src.fedoraproject.org/rpms/gvfs/pull-request/2

Feel free to merge or close it whatever is suitable.

Kind regards,
Christian

[Lennart Poettering]

On Mi, 26.01.22 14:21, Adam Williamson (adamwill(a)fedoraproject.org) wrote:

>  The issue and some of the comments around it prompted me to wonder -
>  why is `pkexec` still a thing? Particularly, why is it still a thing we
>  are shipping by default in just about every Fedora install? 
I don't think there's too much wrong with pkexec. It's like sudo but
with a much smaller, tighter footprint, with a hookup to intractive UI
stuff. I am pretty sure many cases where sudo is used right now would
actually benefit from using pkexec instead.

I mean, polkit has some issues, but I am pretty sure that "pkexec" is
not what I'd consider the big problem with it. Or to say this
differently: the whole concept of tools like
su/sudo/setpriv/runuser/suid binaries is questionnable: i.e. I am
pretty sure we'd be better off if we would systematically prohibit
acquiring privs through execve(), and instead focus on delegating
privileged operations to IPC services — but of course that would be
quite a departure from traditional UNIX.

I mean, if you buy into the conceptual idea that sudo/su/… are a good
thing, and are fine with polkit, too, then I am pretty sure pkexec is
actually the best option you have, and you should rather dump sudo.

"pkexec" is a *short* program, it runs very little code with
privileges actually. That makes it a *ton* better than the humungous
code monster that "sudo" is. It has a smaller security footprint, and
is easier to review than "sudo". That's worth a lot actually.

Lennart

--
Lennart Poettering, Berlin

[Ondřej Holý]

Hi Christian,

I suppose that was not intentional, thanks for the PR.

O.

pá 28. 1. 2022 v 10:15 odesílatel Christian Stadelmann
<genodeftest(a)fedoraproject.org&gt; napsal:
>  Hi Ondřej,
>
>  you wrote:
>  > also gvfs uses pkexec currently to start gvfsd-admin backend...
>
>  The gvfs .spec file does not reflect that so it may fail on a system without polkit
> installed. Is this by intention? If no, I've created a PR:
>  https://src.fedoraproject.org/rpms/gvfs/pull-request/2
>
>  Feel free to merge or close it whatever is suitable.
>
>  Kind regards,
>  Christian
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
>  Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

[Florian Weimer]

* Lennart Poettering:

>  I mean, polkit has some issues, but I am pretty sure that
> "pkexec" is
>  not what I'd consider the big problem with it. Or to say this
>  differently: the whole concept of tools like
>  su/sudo/setpriv/runuser/suid binaries is questionnable: i.e. I am
>  pretty sure we'd be better off if we would systematically prohibit
>  acquiring privs through execve(), and instead focus on delegating
>  privileged operations to IPC services — but of course that would be
>  quite a departure from traditional UNIX. 
One issue is that it's harder to prevent other users from doing execve
than it's denying them access to some IPC service.  In this sense, SUID
programs are more robust.

Thanks,
Florian

[Lennart Poettering]

On Fr, 28.01.22 12:12, Florian Weimer (fweimer(a)redhat.com) wrote:

>  * Lennart Poettering:
>
>  > I mean, polkit has some issues, but I am pretty sure that "pkexec" is
>  > not what I'd consider the big problem with it. Or to say this
>  > differently: the whole concept of tools like
>  > su/sudo/setpriv/runuser/suid binaries is questionnable: i.e. I am
>  > pretty sure we'd be better off if we would systematically prohibit
>  > acquiring privs through execve(), and instead focus on delegating
>  > privileged operations to IPC services — but of course that would be
>  > quite a departure from traditional UNIX.
>
>  One issue is that it's harder to prevent other users from doing execve
>  than it's denying them access to some IPC service.  In this sense, SUID
>  programs are more robust. 
Well, that's precisely the problem that PK was supposed to address,
but then it descended down the JS rabbit hole...

Lennart

--
Lennart Poettering, Berlin

[Florian Weimer]

* Lennart Poettering:

>  On Fr, 28.01.22 12:12, Florian Weimer (fweimer(a)redhat.com) wrote:
>
> > * Lennart Poettering:
> >
> > > I mean, polkit has some issues, but I am pretty sure that "pkexec" is
> > > not what I'd consider the big problem with it. Or to say this
> > > differently: the whole concept of tools like
> > > su/sudo/setpriv/runuser/suid binaries is questionnable: i.e. I am
> > > pretty sure we'd be better off if we would systematically prohibit
> > > acquiring privs through execve(), and instead focus on delegating
> > > privileged operations to IPC services — but of course that would be
> > > quite a departure from traditional UNIX.
> >
> > One issue is that it's harder to prevent other users from doing execve
> > than it's denying them access to some IPC service.  In this sense, SUID
> > programs are more robust.
>
>  Well, that's precisely the problem that PK was supposed to address,
>  but then it descended down the JS rabbit hole... 
Not sure if we are talking about the same thing.  I meant flooding the
local socket (or similar) with requests, not access control.

Thanks,
Florian

[Lennart Poettering]

On Fr, 28.01.22 12:25, Florian Weimer (fweimer(a)redhat.com) wrote:

>  >> One issue is that it's harder to prevent other users
> from doing execve
>  >> than it's denying them access to some IPC service.  In this sense, SUID
>  >> programs are more robust.
>  >
>  > Well, that's precisely the problem that PK was supposed to address,
>  > but then it descended down the JS rabbit hole...
>
>  Not sure if we are talking about the same thing.  I meant flooding the
>  local socket (or similar) with requests, not access control. 
Well, making socket services scalable is not entirely trivial, but i
figure the number of parallel connections a Linux system should be
able to handle is still higher than the number of processes it allows
to run in parallel...

Lennart

--
Lennart Poettering, Berlin

[Demi Marie Obenour]

On 1/28/22 05:41, Lennart Poettering wrote:
>  On Mi, 26.01.22 14:21, Adam Williamson (adamwill(a)fedoraproject.org)
> wrote:
>  
> > The issue and some of the comments around it prompted me to wonder -
> > why is `pkexec` still a thing? Particularly, why is it still a thing we
> > are shipping by default in just about every Fedora install?
>  
>  I don't think there's too much wrong with pkexec. It's like sudo but
>  with a much smaller, tighter footprint, with a hookup to intractive UI
>  stuff. I am pretty sure many cases where sudo is used right now would
>  actually benefit from using pkexec instead.
>  
>  I mean, polkit has some issues, but I am pretty sure that "pkexec" is
>  not what I'd consider the big problem with it. Or to say this
>  differently: the whole concept of tools like
>  su/sudo/setpriv/runuser/suid binaries is questionnable: i.e. I am
>  pretty sure we'd be better off if we would systematically prohibit
>  acquiring privs through execve(), and instead focus on delegating
>  privileged operations to IPC services — but of course that would be
>  quite a departure from traditional UNIX. 
Agreed.  With S_ISUID and S_ISGID, the default is to inherit the entire
(untrusted!) caller environment, and the privileged process must sanitize
it.  With an IPC service, the default is to not inherit any of the
environment, and only parts of the environment that are specifically
set are passed on.

As an aside, can Linux and/or glibc please disallow passing a NULL
argv[0]?  I would honestly be okay with glibc just crashing the process
during startup if argv[0] is NULL or empty.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[Michael Catanzaro]

On Fri, Jan 28 2022 at 10:55:43 AM -0500, Demi Marie Obenour 
<demiobenour(a)gmail.com&gt; wrote:
>  As an aside, can Linux and/or glibc please disallow passing a NULL
>  argv[0]?  I would honestly be okay with glibc just crashing the 
>  process
>  during startup if argv[0] is NULL or empty. 
A glibc restriction wouldn't be enough, since you don't have to use 
glibc to make a syscall.

[Demi Marie Obenour]

On 1/28/22 11:38, Michael Catanzaro wrote:
>  On Fri, Jan 28 2022 at 10:55:43 AM -0500, Demi Marie Obenour 
>  <demiobenour(a)gmail.com&gt; wrote:
> > As an aside, can Linux and/or glibc please disallow passing a NULL
> > argv[0]?  I would honestly be okay with glibc just crashing the 
> > process
> > during startup if argv[0] is NULL or empty.
>  
>  A glibc restriction wouldn't be enough, since you don't have to use 
>  glibc to make a syscall. 
I meant glibc in the *child* process, at least if AT_SECURE is set.

-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[Lennart Poettering]

On Fr, 28.01.22 10:55, Demi Marie Obenour (demiobenour(a)gmail.com) wrote:

>  As an aside, can Linux and/or glibc please disallow passing a NULL
>  argv[0]?  I would honestly be okay with glibc just crashing the process
>  during startup if argv[0] is NULL or empty. 
Yeah, it would be good if glibc start-up code would automatically
synthesize argv[0] in some way (maybe set it to the name PR_GET_NAME
returns or so) if argc == 0. And that this would then propagate into
program_invocation_name[] and program_invocation_short_name[] so that
all code can safely rely that once main() is invoked argc > 0, argv[0]
is non-NULL (and ideally even a non-empty string), and both
program_invocation{_short,}_name are set. There's just too much code
out there that relies on this, and I think it would be best if glibc
would just make it so that what people assume is guaranteed actually
becomes guaranteed.

Lennart

--
Lennart Poettering, Berlin

[Adam Williamson]

On Fri, 2022-01-28 at 11:41 +0100, Lennart Poettering wrote:
>  
>  "pkexec" is a *short* program, it runs very little code with
>  privileges actually. That makes it a *ton* better than the humungous
>  code monster that "sudo" is. It has a smaller security footprint, and
>  is easier to review than "sudo". That's worth a lot actually. 
...and yet despite being so easy to review it somehow had a major
security vulnerability ever since it was written.

Anyway, my point is not really pkexec vs. sudo for interactive use, but
whether pkexec is actually needed by default on all of our editions for
non-interactive use. It's not an easy question to answer since our
packaging doesn't distinguish between something needing *polkit* and
something needing *pkexec*. Though from what we've found in this
thread, it seems like at least GNOME and KDE definitely do still need
it. I'm not enough of a domain expert to know if it's realistic to
rewrite everything in GNOME and KDE that relies on pkexec to use a
different mechanism.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

[Adam Williamson]

On Thu, 2022-01-27 at 08:30 +0100, Milan Crha wrote:
>  On Wed, 2022-01-26 at 15:18 -0800, Adam Williamson wrote:
>  > There are still over a dozen packages in the distro that
>  > require it:
>  
>  	Hi,
>  the gnome-software also calls pkexec is some occasions, once when
>  external appstream data is used (not a thing in Fedora, as far as I
>  know) and when invoking fedora-third-party in some cases. There's no
>  hard require for it in the .spec file. 
Yeah, I actually started looking last night and found a few other
places too :/ gnome-control-center installs a `/usr/libexec/cc-remote-
login-helper` which is run by pkexec, for instance. So I guess we're
stuck with it :(
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

[Robbie Harwood]

Adam Williamson <adamwill(a)fedoraproject.org&gt; writes:

>  ...and yet despite being so easy to review it somehow had a major
>  security vulnerability ever since it was written. 
This is not a good metric.  easy to review != was sufficiently reviewed,
and getting sufficient code review might be the hardest problem in
software engineering.

Additionally, if a project has never had an issue, it's just as likely
that no one has ever really looked at it than that it's "safer".

Be well,
--Robbie

[Neal Gompa]

On Fri, Jan 28, 2022 at 3:04 PM Robbie Harwood <rharwood(a)redhat.com&gt; wrote:
>  Adam Williamson <adamwill(a)fedoraproject.org&gt; writes:
>
>  > ...and yet despite being so easy to review it somehow had a major
>  > security vulnerability ever since it was written.
>
>  This is not a good metric.  easy to review != was sufficiently reviewed,
>  and getting sufficient code review might be the hardest problem in
>  software engineering.
>
>  Additionally, if a project has never had an issue, it's just as likely
>  that no one has ever really looked at it than that it's "safer".
>  
Actually, someone had conceived that it might be a problem in 2013:
https://ryiron.wordpress.com/2013/12/16/argv-silliness/



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Dominique Martinet]

Demi Marie Obenour wrote on Fri, Jan 28, 2022 at 10:55:43AM -0500:
>  As an aside, can Linux and/or glibc please disallow passing a NULL
>  argv[0]?  I would honestly be okay with glibc just crashing the process
>  during startup if argv[0] is NULL or empty. 
FWIW a patch has already been sent shortly after this all started:
https://lore.kernel.org/lkml/20220127000724.15106-1-ariadne@dereferenced....

And it's already in the mmotm tree so just a matter of time until it
reaches linux master

-- 
Dominique

[Sam Varshavchik]

Florian Weimer writes:

>  > Well, that's precisely the problem that PK was supposed to
> address,
>  > but then it descended down the JS rabbit hole...
>
>  Not sure if we are talking about the same thing.  I meant flooding the
>  local socket (or similar) with requests, not access control. 
Create a filesystem socket. Set the socket's UID, GID, and chmod.  
Abracadabra: same initial access control as execve. I don't recall off the  
top of my head whether you need r, w, x, or some combination of these to be  
able to connect() to it, but whatever they are: set it. I also don't recall  
whether ACLs would also work, but at least without ACLs you get the same  
level of control as an executable binary.

Then, demand an SO_PASSCRED as the first order of business, on every new  
connection: now you have exactly the same information to work with as a SUID  
executable.

I can't think of any reason why su/sudo cannot be implemented this way.

Having said all of that: the suid bit itself is irrelevant. It is nothing  
more than a convenient scapegoat to blame other bugs on. The same bug that's  
exploitable in a suid binary will also be exploitable, exactly the same way,  
in its suid-less equivalent. If you have a buffer overrun in a suid binary  
as a result of carefully-crafted command-line parameters or environment,  
then if you replace the suid binary with an identical bug-for-bug  
implementation that uses a socket to carefully pass along the same  
environment or parameters to a native root binary, and the buffer overrun is  
the same, guess what: you still have the same exploit.

suid is not the problem. An execved program will inherit the environment,  
some open file descriptors, and maybe a few other things that a standalone  
daemon that accepted a socket connection does not have. But that's what most  
exploits leverage, so cleaning up the environment and open file descriptors  
would remedy that. It will take some effort to exploit whatever remains.

If you wrote a suid program, and did not wipe out your char **environ, or  
went through and closed any lingering file descriptors, your problem was not  
your suid bit, but something else.

[Kevin Kofler]

Adam Williamson wrote:
>  Anyway, my point is not really pkexec vs. sudo for interactive use,
> but
>  whether pkexec is actually needed by default on all of our editions for
>  non-interactive use. It's not an easy question to answer since our
>  packaging doesn't distinguish between something needing *polkit* and
>  something needing *pkexec*. Though from what we've found in this
>  thread, it seems like at least GNOME and KDE definitely do still need
>  it. I'm not enough of a domain expert to know if it's realistic to
>  rewrite everything in GNOME and KDE that relies on pkexec to use a
>  different mechanism. 
Where have you seen KDE needing it? See my reply: KDE stuff should be using 
kdesu, not pkexec.

The journal scan posted to the kde list by Garry T. Williams actually does 
not contain a single invocation of pkexec. Those are all KAuth actions in 
the org.kde.kcontrol.kcmsddm.* namespace. pkexec uses the 
org.freedesktop.policykit.exec action. And none of the hits in Adrian 
Sevcenco's ag scan are KDE software. (I don't know if any of those are on 
the current KDE Spin, but they should not be.)

        Kevin Kofler

[Matthew Miller]

On Fri, Jan 28, 2022 at 11:26:58AM -0800, Adam Williamson wrote:
>  something needing *pkexec*. Though from what we've found in this
>  thread, it seems like at least GNOME and KDE definitely do still need
>  it. I'm not enough of a domain expert to know if it's realistic to
>  rewrite everything in GNOME and KDE that relies on pkexec to use a
>  different mechanism. 
I wouldn't call myself a domain expert on this, but ...
cc-remote-login-helper at least should be able to be updated. (It's making
dbus calls to systemd to enable sshd.)

Other stuff may be more like fundamentally replacing the whole app/tool.

I wonder if a first step might be to split out pkexec into a subpackage, and
then gradually remove requirements on it.


-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Brandon Nielsen]

On 1/27/22 10:50 AM, Adam Williamson wrote:
>  On Thu, 2022-01-27 at 08:30 +0100, Milan Crha wrote:
> > On Wed, 2022-01-26 at 15:18 -0800, Adam Williamson wrote:
> >> There are still over a dozen packages in the distro that
> >> require it:
> >
> > 	Hi,
> > the gnome-software also calls pkexec is some occasions, once when
> > external appstream data is used (not a thing in Fedora, as far as I
> > know) and when invoking fedora-third-party in some cases. There's no
> > hard require for it in the .spec file.
>  
>  Yeah, I actually started looking last night and found a few other
>  places too :/ gnome-control-center installs a `/usr/libexec/cc-remote-
>  login-helper` which is run by pkexec, for instance. So I guess we're
>  stuck with it :( 
I have opened an issue upstream[0], as well as prototyped a pkexec free 
approach[1]. If things go well I can look at gnome-software as well. I 
really do think splitting out and eventually dropping pkexec is a 
worthwhile goal.

Feedback welcome!

[0] - https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/1604
[1] - 
https://gitlab.gnome.org/nielsenb-jf/gnome-control-center/-/tree/41.2-no_...

[Michael J Gruber]

I vaguely remember we had a move off consolekit at some point: In 2016, I moved
"luckybackup" away from "beesu" (which uses consolekit) to
"pkexec" (from polkit).

We still have "beesu" in Fedora. Should I switch back? ;)

Seriously, while it's worthwhile to ponder which approach tu use or avoid in the
future, i.e. what is "The Right Way", the response time in terms of Fedora
patches showed that "Something Works Right" in Fedora land!

[Lennart Poettering]

On Fr, 28.01.22 18:16, Sam Varshavchik (mrsam(a)courier-mta.com) wrote:

>  Having said all of that: the suid bit itself is irrelevant. It is
> nothing
>  more than a convenient scapegoat to blame other bugs on. The same bug that's
>  exploitable in a suid binary will also be exploitable, exactly the same way,
>  in its suid-less equivalent. If you have a buffer overrun in a suid binary
>  as a result of carefully-crafted command-line parameters or environment,
>  then if you replace the suid binary with an identical bug-for-bug
>  implementation that uses a socket to carefully pass along the same
>  environment or parameters to a native root binary, and the buffer overrun is
>  the same, guess what: you still have the same exploit. 
I vehemently disagree. The thing with setuid/setgid is that the
invoked privileged process inherits a lot of implicit state and
context that people aren't really aware of or fully
understand. i.e. it's not just env vars and argv[], it's cgroup
memberships, audit fields, security contexts, open fds, child pids,
parent pids, cpu masks, IO/CPU scheduling priorities, various prctl()
settings, tty control, signal masks + handlers, … and so on. And it's
not even clear what gets inherited as many of these process properties
are added all the time.

If you do privileged execution of specific operations via IPC you get
the guarantee that whatever is done, is done from a well-defined,
pristine execution environment, without leaking context implicitly. The
IPC message is the *full* vulnerable surface, and that's as minimal as
it can get. And that's great.

So yes, setuid/setgid is a mess. Modern OS designs tend to follow the
rule that privs lost cannot be regained, and that's a much much better
design than what we do on Linux/UNIX.

(But I guess that ship has sailed, getting sudo out of the standard OS
is not going to work for a general purpose distro these days anymore —
but let's not pretend setuid/setgid was OK, because it's not.)

>  suid is not the problem. An execved program will inherit the
> environment,
>  some open file descriptors, and maybe a few other things that a standalone
>  daemon that accepted a socket connection does not have. But that's what most
>  exploits leverage, so cleaning up the environment and open file descriptors
>  would remedy that. It will take some effort to exploit whatever
>  remains. 
IRL you cannot clean up your execution context, because new stuff is
added all the time. And often enough it's not even clear whar reset it
to, e.g. cgroup stuff.

Lennart

--
Lennart Poettering, Berlin

[Lennart Poettering]

On Fr, 28.01.22 11:26, Adam Williamson (adamwill(a)fedoraproject.org) wrote:

>  On Fri, 2022-01-28 at 11:41 +0100, Lennart Poettering wrote:
>  >
>  > "pkexec" is a *short* program, it runs very little code with
>  > privileges actually. That makes it a *ton* better than the humungous
>  > code monster that "sudo" is. It has a smaller security footprint, and
>  > is easier to review than "sudo". That's worth a lot actually.
>
>  ...and yet despite being so easy to review it somehow had a major
>  security vulnerability ever since it was written. 
Yeah, but sudo is much worse, no? CVEs are a shitty metric, but afaik
the number of CVEs of sudo dwarves the CVEs of pkexec...

>  Anyway, my point is not really pkexec vs. sudo for interactive use,
> but
>  whether pkexec is actually needed by default on all of our editions for
>  non-interactive use. It's not an easy question to answer since our
>  packaging doesn't distinguish between something needing *polkit* and
>  something needing *pkexec*. Though from what we've found in this
>  thread, it seems like at least GNOME and KDE definitely do still need
>  it. I'm not enough of a domain expert to know if it's realistic to
>  rewrite everything in GNOME and KDE that relies on pkexec to use a
>  different mechanism. 
systemd's "ask-password" logic kinda pushes UI tools towards pkexec
too btw.

Lennart

--
Lennart Poettering, Berlin

[Sam Varshavchik]

Lennart Poettering writes:

>  On Fr, 28.01.22 18:16, Sam Varshavchik (mrsam(a)courier-mta.com)
> wrote:
>
>  > Having said all of that: the suid bit itself is irrelevant. It is nothing
>  > more than a convenient scapegoat to blame other bugs on. The same bug  
>  that's
>  > exploitable in a suid binary will also be exploitable, exactly the same  
>  way,
>  > in its suid-less equivalent. If you have a buffer overrun in a suid binary
>  > as a result of carefully-crafted command-line parameters or environment,
>  > then if you replace the suid binary with an identical bug-for-bug
>  > implementation that uses a socket to carefully pass along the same
>  > environment or parameters to a native root binary, and the buffer overrun  
>  is
>  > the same, guess what: you still have the same exploit.
>
>  I vehemently disagree. The thing with setuid/setgid is that the
>  invoked privileged process inherits a lot of implicit state and
>  context that people aren't really aware of or fully
>  understand. i.e. it's not just env vars and argv[], it's cgroup
>  memberships, audit fields, security contexts, open fds, child pids,
>  parent pids, cpu masks, IO/CPU scheduling priorities, various prctl()
>  settings, tty control, signal masks + handlers, … and so on. 
And none of that makes any difference, whatsoever, unless there's also an  
underlying logical bug in the code itself. And that's going to be the real  
problem. So then, question becomes, how many exploits leveraged any of these  
exotic resources, like cgroup members, tty control, and all of those other  
fringe attributes? I suppose there might've been a few, but I can't recall  
many. On the other hand, exploits that accomplish execve("/bin/bash") would  
work equally well, given the same underlying bug in the root daemon, that's  
triggerable via its front end, or in a suid program. A sanitized environment  
won't be much of a help.

Give me a suid program doing a fgets() with a wrong buffer size on a stack  
array. Then also give me a program that connects to a root daemon over a  
socket, then simply forwards all input to it, with the root daemon also  
doing the same exact buffer overrun. The exploit will be the same. The root  
daemon's pristine, pure as wind-driven snow, environment won't make any  
difference.

In fact, having extra moving pieces only breeds more opportunities for bugs.  
There are still too many simpletons who are going to conclude that the right  
way to go is by doing all edit checking in the wrapper, then passing  
validated data to the daemon who'll assume its validity.

"The more you overthink the plumbing, the easier it is to stop up the  
drain." – Scotty, Star Trek III.


>  > suid is not the problem. An execved program will inherit the
> environment,
>  > some open file descriptors, and maybe a few other things that a standalone
>  > daemon that accepted a socket connection does not have. But that's what  
>  most
>  > exploits leverage, so cleaning up the environment and open file descriptors
>  > would remedy that. It will take some effort to exploit whatever
>  > remains.
>
>  IRL you cannot clean up your execution context, because new stuff is
>  added all the time. And often enough it's not even clear whar reset it
>  to, e.g. cgroup stuff. 
Stuff that's "added all the time" won't be used in existing code base,
and  
will be immaterial. None of the stuff from semi-recent history (containers,  
CPU affinities, etc…) appears to have much effect on my existing setup.

[Lennart Poettering]

On Mo, 31.01.22 06:28, Sam Varshavchik (mrsam(a)courier-mta.com) wrote:

>  > I vehemently disagree. The thing with setuid/setgid is that the
>  > invoked privileged process inherits a lot of implicit state and
>  > context that people aren't really aware of or fully
>  > understand. i.e. it's not just env vars and argv[], it's cgroup
>  > memberships, audit fields, security contexts, open fds, child pids,
>  > parent pids, cpu masks, IO/CPU scheduling priorities, various prctl()
>  > settings, tty control, signal masks + handlers, … and so on.
>
>  And none of that makes any difference, whatsoever, unless there's also an
>  underlying logical bug in the code itself. 
That's what you hope. But because there are *so* many properties of a
process these days, and it's not entirely obvious what gets inherited
and what not and what the effect of it is, that it's very hard to
clean it up, and I'd even claim impossible.

>  > > suid is not the problem. An execved program will inherit
> the environment,
>  > > some open file descriptors, and maybe a few other things that a standalone
>  > > daemon that accepted a socket connection does not have. But that's
>  > what most
>  > > exploits leverage, so cleaning up the environment and open file descriptors
>  > > would remedy that. It will take some effort to exploit whatever
>  > > remains.
>  >
>  > IRL you cannot clean up your execution context, because new stuff is
>  > added all the time. And often enough it's not even clear whar reset it
>  > to, e.g. cgroup stuff.
>
>  Stuff that's "added all the time" won't be used in existing code base,
> and
>  will be immaterial. None of the stuff from semi-recent history (containers,
>  CPU affinities, etc…) appears to have much effect on my existing setup. 
suid processes didn't use to be a member of a cgroup. Now they
are. Security policy is tied to cgroups (i.e. see bpf cgroup stuff),
so suddenly bpf some stuff affects suid programs that they weren#t
affected by before.

You might *hope* that there was no bug introduced through the
interaction of all that code, but the point I am making is that
"struct task" and associated objects in kernel get extended all the
time, and suid programs that didn#t expect these additions will be
exposed to them, and cannot sanely reset them even if they wanted,
since typically developers cannot look into the future (and the
cgroup stuff cannot even be reset reasonably at all).

Lennart

--
Lennart Poettering, Berlin

[Sam Varshavchik]

Lennart Poettering writes:

>  On Mo, 31.01.22 06:28, Sam Varshavchik (mrsam(a)courier-mta.com)
> wrote:
>
>  > > I vehemently disagree. The thing with setuid/setgid is that the
>  > > invoked privileged process inherits a lot of implicit state and
>  > > context that people aren't really aware of or fully
>  > > understand. i.e. it's not just env vars and argv[], it's cgroup
>  > > memberships, audit fields, security contexts, open fds, child pids,
>  > > parent pids, cpu masks, IO/CPU scheduling priorities, various prctl()
>  > > settings, tty control, signal masks + handlers, … and so on.
>  >
>  > And none of that makes any difference, whatsoever, unless there's also an
>  > underlying logical bug in the code itself.
>
>  That's what you hope. But because there are *so* many properties of a
>  process these days, and it's not entirely obvious what gets inherited
>  and what not and what the effect of it is, that it's very hard to
>  clean it up, and I'd even claim impossible. 
I would like to see some hard data here: how many exploits, historically,  
leveraged all those ancillary, inherited process metadata that would not've  
worked if the targeted process had this ideal environment.

An argument is being advanced that having an isolated process, with a clean  
environment, would be an effective mitigation strategy that prevents  
exploitable vulnerabilities.

This should be demonstrable with prior art. Of course, it's fair to include  
the other side of the coin: documentation of incidents where there was no  
exploit clearly because of the isolated process's environment blocking any  
exploitation of a bug. Both, I think would be fair to cite as a  
authoritative data.

So, where's the prior art?

>  > Stuff that's "added all the time" won't be
> used in existing code base, and
>  > will be immaterial. None of the stuff from semi-recent history (containers,
>  > CPU affinities, etc…) appears to have much effect on my existing setup.
>
>  suid processes didn't use to be a member of a cgroup. Now they
>  are. Security policy is tied to cgroups (i.e. see bpf cgroup stuff),
>  so suddenly bpf some stuff affects suid programs that they weren#t
>  affected by before. 
And when the cgroups did not exist, when everyone lives in the same sandbox,  
something would stop the same, exact, exploitable program from exploiting  
whatever it coulf exploit as part of the cgroup, and with no other  
differences? Continuing with Star Trek quotes: as Mr. Spock would say "this  
is highly illogical".

It's difficult to talk in generalities but, presumably, prior to cgroups,  
the other actor that's involved in this theoretical exploit might've used  
some other access control mechanism, or authentication mechanism.

With the same exploitable program, it will either be able to leverage the  
other actor, before cgroups, with its alternative access control mechanism,  
or not. The prior security model was, presumably scrapped in favor of  
cgroups. That, as I understand, is the described scenario here.

So, the grand total that I see here: if the prior security model also didn't  
stop the same exploit being leveraged, then cgroups made no difference. If  
it did, switching to cgroups made it worse.

And in both cases, the issue is the nature of the actual bug in the  
exploitable program, and not anything else. Suid is just a scapegoat.

[Miroslav Suchý]

Dne 27. 01. 22 v 0:18 Adam Williamson napsal(a):
>  BTW, bonus follow-up to this: as part of researching the background
> of
>  polkit, I noticed that we never actually entirely got done moving off
>  usermode:(  There are still over a dozen packages in the distro that
>  require it: 
Moving off to where?

FYI there is tracking bug

[Tracker] Deprecate consolehelper and switch apps to use PolicyKit 1 for Fedora 12

https://bugzilla.redhat.com/show_bug.cgi?id=502765

but lots of the bugs are closed as DEFERED or WONTFIX.

I tried to migrate Mock out of consolehelper

https://bugzilla.redhat.com/show_bug.cgi?id=502749
https://github.com/rpm-software-management/mock/issues/684

but very soon I discovered that documentation of PolicyKit is nearly non-existent. At
least, it is not sufficient to do 
the migration. After reading the code I found that it is likely missing functionality of
consolehelper.

I had a discussion with maintainer of PolicyKit and we both come conclusion that PolicyKit
stopped in the middle of 
nowhere and for me and Mock is better to stay with consolehelper.

Does the situation have changed?

Miroslav

[Lennart Poettering]

On Mo, 31.01.22 07:46, Sam Varshavchik (mrsam(a)courier-mta.com) wrote:

>  > > Stuff that's "added all the time" won't
> be used in existing code base, and
>  > > will be immaterial. None of the stuff from semi-recent history (containers,
>  > > CPU affinities, etc…) appears to have much effect on my existing setup.
>  >
>  > suid processes didn't use to be a member of a cgroup. Now they
>  > are. Security policy is tied to cgroups (i.e. see bpf cgroup stuff),
>  > so suddenly bpf some stuff affects suid programs that they weren#t
>  > affected by before.
>
>  And when the cgroups did not exist, when everyone lives in the same sandbox,
>  something would stop the same, exact, exploitable program from exploiting
>  whatever it coulf exploit as part of the cgroup, and with no other
>  differences? Continuing with Star Trek quotes: as Mr. Spock would say "this
>  is highly illogical". 
See the discussion around seccomp and NNP. i.e. a new kernel facility
was added precisely to ensure that seccomp cannot be used to run code
that is intended to be run privileged – under security policies in
control by an unprivileged user. i.e. if you can take certain privs
away from code that expects to have them you might be able to trigger
vulnerable codepaths that the developer didn't expect you to be able
to trigger.

But anyway, don't focus so much in cgroups here. There are plenty
other props these days that sudo doesn#t clean up. consider this for
example: plenty of priv code takes file locks or similar, that unpriv
code is not supposed to be able to take. If it could, it could DoS
priv code and thta should not be possible. Given that sudo doesn't
clean up "nice" levels, I am pretty sure it's easy to construct an
exploit from that: i.e. issue "nice -n 19 sudo …" on some priv program
that takes a lock, and at the same time hammer the system with a bunch
of programs that want the CPU. Now, the priv program takes the lock,
but given the nice level of 19 will not be scheduled anymore for a
long long time, because your other programs monopolize the CPU an run
at nice level 0 like all other user code. So now the priv lock is
taken and remains so, and all other priv code that wants it will block
for basically forever and you trigger all that from your unpriv user
account.

You can make this even worse I guess if you throw IO and CPU scheduler
settings into the mix, and mask off all CPUs in the affinity
mask. Suddenly the priv code has no chance to ever get the lock again
because the resources it might theoretically get access too became soo
ridiculously artificially scarce that it never runs anymore...

This entire problem set doesn't exist if you run your services nicely
isolated, because if a client gets no chance to muck with priv code's
affinity mask, nice level, priorities, cgroup, … it cannot trigger
these vulnerabilities.

Lennart

--
Lennart Poettering, Berlin

[Kevin Kofler]

Lennart Poettering wrote:
>  The IPC message is the *full* vulnerable surface, and that's as
> minimal as
>  it can get. And that's great. 
But that message can actually open a whole new vulnerability, compared to a 
monolithic program running completely as root. E.g., I have seen several 
D-Bus-activated PolicyKit helpers that basically allow running an arbitrary 
command as root. Grant the PolicyKit permission for any of those to an 
unprivileged user and you have given them instant root. The monolithic 
version would make that a function, method, or class in a monolithic 
executable that is only ever called with some specific commands as an 
argument. The "more secure" PolicyKit-based design introduces the extra 
entry point that needs to be protected against unauthorized access.

        Kevin Kofler

[Demi Marie Obenour]

On 1/31/22 05:36, Lennart Poettering wrote:
>  On Fr, 28.01.22 18:16, Sam Varshavchik (mrsam(a)courier-mta.com)
> wrote:
>  
> > Having said all of that: the suid bit itself is irrelevant. It is nothing
> > more than a convenient scapegoat to blame other bugs on. The same bug that's
> > exploitable in a suid binary will also be exploitable, exactly the same way,
> > in its suid-less equivalent. If you have a buffer overrun in a suid binary
> > as a result of carefully-crafted command-line parameters or environment,
> > then if you replace the suid binary with an identical bug-for-bug
> > implementation that uses a socket to carefully pass along the same
> > environment or parameters to a native root binary, and the buffer overrun is
> > the same, guess what: you still have the same exploit.
>  
>  I vehemently disagree. The thing with setuid/setgid is that the
>  invoked privileged process inherits a lot of implicit state and
>  context that people aren't really aware of or fully
>  understand. i.e. it's not just env vars and argv[], it's cgroup
>  memberships, audit fields, security contexts, open fds, child pids,
>  parent pids, cpu masks, IO/CPU scheduling priorities, various prctl()
>  settings, tty control, signal masks + handlers, … and so on. And it's
>  not even clear what gets inherited as many of these process properties
>  are added all the time. 
State inheritance definitely should be opt-in, with the possible
exception of certain audit data such as the audit user ID.

>  If you do privileged execution of specific operations via IPC you
> get
>  the guarantee that whatever is done, is done from a well-defined,
>  pristine execution environment, without leaking context implicitly. The
>  IPC message is the *full* vulnerable surface, and that's as minimal as
>  it can get. And that's great.
>  
>  So yes, setuid/setgid is a mess. Modern OS designs tend to follow the
>  rule that privs lost cannot be regained, and that's a much much better
>  design than what we do on Linux/UNIX. 
Yes and no.  Systems with capability-based access control allow
one to gain additional privileges by means of receiving privileged
capabilities.  For instance, a login program could start with no
privileges at all other than the ability to connect to a service that
authenticates users.  Upon successful authentication, the login program
would be given a capability that allowed it to act as the authenticated
user.  For this to work, different instances of the login program would
need to be unable to compromise with each other, which is fairly easy
to enforce in a pure capability-based system.

>  (But I guess that ship has sailed, getting sudo out of the standard
> OS
>  is not going to work for a general purpose distro these days anymore —
>  but let's not pretend setuid/setgid was OK, because it's not.) 
What would break if sudo was replaced by an IPC service that ran
sudo as if it was setuid root, without it actually being setuid root?
I imagine the hardest part would be TTY handling, as not being able
to Ctrl-C a command launched by sudo is a rather poor user experience.
That might be solvable, though.

-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[Steve Grubb]

On Monday, January 31, 2022 5:36:24 AM EST Lennart Poettering wrote:
>  On Fr, 28.01.22 18:16, Sam Varshavchik (mrsam(a)courier-mta.com)
> wrote:
>  > Having said all of that: the suid bit itself is irrelevant. It is nothing
>  > more than a convenient scapegoat to blame other bugs on. The same bug
>  > that's exploitable in a suid binary will also be exploitable, exactly
>  > the same way, in its suid-less equivalent. If you have a buffer overrun
>  > in a suid binary as a result of carefully-crafted command-line
>  > parameters or environment, then if you replace the suid binary with an
>  > identical bug-for-bug implementation that uses a socket to carefully
>  > pass along the same environment or parameters to a native root binary,
>  > and the buffer overrun is the same, guess what: you still have the same
>  > exploit.
>  
>  I vehemently disagree. The thing with setuid/setgid is that the
>  invoked privileged process inherits a lot of implicit state and
>  context that people aren't really aware of or fully
>  understand. i.e. it's not just env vars and argv[], it's cgroup
>  memberships, audit fields, security contexts, 
For security reasons, we count on these last two. We count on a property 
called non-repudiation. We also count on a user with a specific selinux user 
cannot escape that assigment.

>  open fds, child pids, parent pids, cpu masks, IO/CPU scheduling
> priorities,
>  various prctl() settings, tty control, signal masks + handlers, … and so
>  on. And it's not even clear what gets inherited as many of these process
>  properties are added all the time.
>  
>  If you do privileged execution of specific operations via IPC you get
>  the guarantee that whatever is done, is done from a well-defined,
>  pristine execution environment, without leaking context implicitly. The
>  IPC message is the *full* vulnerable surface, and that's as minimal as
>  it can get. And that's great. 
But doesn't satisfy our security requirements. If the kernel dbus project had 
been successful, then Linux would have had a rock solid basis to allow 
impersonation which would satisfy the security requirements and allow the 
desktop actually go through a common criteria certification if any one ever 
wanted to do that. But as it stands, anything created by IPC is missing the 
necessary security context.

Also, it's impossible to reason about what's allowed and what's not because 
the policy is free-form javascript rather than assignments that can be 
checked by any configuration scanners. And access decisions do not go through 
the audit system. So, we really have little insight into access control and 
information flows from anything using IPC started applications.

Setuid may be distasteful to some people. But it's properties are well known 
and its fully plumbed to make some assurance arguments about the platform.

Cheers,
-Steve

[Miloslav Trmac]

po 31. 1. 2022 v 13:49 odesílatel Sam Varshavchik <mrsam(a)courier-mta.com&gt;
napsal:

>  And in both cases, the issue is the nature of the actual bug in the
>  exploitable program, and not anything else. Suid is just a scapegoat. 

I mean, this exact vulnerability is a counterexample. The input to pkexec
is approximately (invoking user identity, program to run, arguments to pass
to that program), and that’s all that would be provided over an IPC. The
vulnerability here is in the contents of argv[0], which is *not* the input
to the pkexec operation, just one of the values inherited through execve.

Now, I do acknowledge that the IPC server code could also be buggy, and
it’s been historically difficult enough to write a good D-Bus server (with
C, the old D-Bus libraries, possibly all that GObject boilerplate), that
just slapping userhelper / pkexec on top of a CLI backend (or worse, a full
GUI) was what ended up being implemented because it was so much easier and
“worked well enough”.

But that’s “just” a matter of lack of investment — we know for *decades* that
it’s possible to automate the IPC infrastructure (e.g. Java RMI, where one
defines a Java interface type, a Java implementation of that interface, and
just runs $tooling to run that interface implementation as an
out-of-process server, in, what, 1998?), and to use memory-safe languages,
to reduce human error and toil. After such an IPC infrastructure exists,
for easy integration into clients and servers, it’s at least as easy to
invoke an IPC, probably much easier, than encoding the IPC request as CLI
parameters, and parsing them in the executed binary — especially when error
handling needs to be taken into account.

Yeah, it would be a pretty big culture shift from the 1980s-UNIX
approaches, and Open Source communities tend to be defined by their shared
cultural values / design approaches.

So, just like moving from consolehelper to D-Bus APIs , in that linked bug
from 12 years ago, it just didn’t happen, because the existing community
was not inherently attracted to doing this kind of infrastructure work, and
moving to “non-UNIXy” approaches.
    Mirek

[Miloslav Trmac]

Hello,
po 31. 1. 2022 v 18:13 odesílatel Steve Grubb <sgrubb(a)redhat.com&gt; napsal:

>  On Monday, January 31, 2022 5:36:24 AM EST Lennart Poettering wrote:
>  > On Fr, 28.01.22 18:16, Sam Varshavchik (mrsam(a)courier-mta.com) wrote:
>  >
>  > I vehemently disagree. The thing with setuid/setgid is that the
>  > invoked privileged process inherits a lot of implicit state and
>  > context that people aren't really aware of or fully
>  > understand. i.e. it's not just env vars and argv[], it's cgroup
>  > memberships, audit fields, security contexts,
>
>  For security reasons, we count on these last two. We count on a property
>  called non-repudiation. 

I imagine an IPC with capability-like objects (in the microkernel sense,
not in the “POSIX capability” sense) could easily enough, on use, log both
who the capability was originally issued to, and who ultimately used it (or
even every single transition across an user account / login ID). In theory.


>  We also count on a user with a specific selinux user
>  cannot escape that assigment.
>  
OTOH the SELinux kernel-objects-only (basically files-only) confinement is
inherently limited to only the concepts the kernel understands. So there’s
a “write to /etc/passwd” capability but it isn’t possible to separately
give some users “add a user to /etc/passwd” and “change one’s own real name
in /etc/passwd” features, as far as the kernel is concerned. So the set-uid
executable that is used to write to /etc/passwd is still a part of the
trusted base, in the sense that it could be exploited not just to
immediately write unexpected data to /etc/passwd, but possibly because an
exploit payload written *elsewhere* (/etc/nsswitch.conf? /lib64/*?) could
be used to exploit the set-uid executable and cause it to misattribute a
kernel-visible /etc/passwd write to a “victim” user who just happened to be
exploited.

An IPC-based system could provide *much better* auditability and control,
because it could be granular at the level of individual operations — sure,
at a non-trivial cost; a lot of the IPC servers would end up a part of the
(semi-) trusted base, at least to the extent that they need to properly
audit use of the operations they provide. But, as described above, they are
already basically trusted to this extent today.


>  But doesn't satisfy our security requirements. If the kernel dbus
> project
>  had
>  been successful, then Linux would have had a rock solid basis to allow
>  impersonation which would satisfy the security requirements and allow the
>  desktop actually go through a common criteria certification if any one
>  ever
>  wanted to do that. But as it stands, anything created by IPC is missing
>  the
>  necessary security context.
>  
I mean, yes. I read that as not a reason to stick with set-uid, but as a
reason to make that a priority, and drive the investment and the cultural
change; otherwise Linux security is just going to keep falling behind. OTOH
with the consolehelper history and a lot of similar examples, I don’t know
how to do any of that (make it a priority, drive the investment, drive the
cultural change).

Also, it's impossible to reason about what's allowed and what's not because
>  the policy is free-form javascript rather than assignments that can
> be
>  checked by any configuration scanners. 

Polkit’s JavaScript is certainly a mistake, but 1) that’s unrelated to the
general use of IPC, 2) for Common Criteria it would be trivial enough to
say “the only Polkit Configuration is exactly this blob that invokes
polkit-pkla-compat”, and enforce it with OpenSCAP and kernel’s file system
audit rules.


>  And access decisions do not go through
>  the audit system. 

For polkit, that would be… a 20-line patch? Sure, the invoking user’s
configuration can be trusted only to the extent a D-Bus server provides it
correctly to Polkit, making the D-Bus servers a part of the trusted
codebase. Still, that would be pretty valuable at least until the first
successful exploit.
    Mirek

[Adam Williamson]

On Mon, 2022-01-31 at 10:19 +0000, Michael J Gruber wrote:
>  I vaguely remember we had a move off consolekit at some point: In
> 2016, I moved "luckybackup" away from "beesu" (which uses consolekit)
> to "pkexec" (from polkit).
>  
>  We still have "beesu" in Fedora. Should I switch back? ;) 
No. The issue is not that pkexec is inherently worse than any other
tool to do approximately the same thing (prompt for some kind of
password, then run the entire app as root) - it's unfortunate that
pkexec happened to have a giant security flaw, but it's not unlikely
that other tools to do the same thing will turn out to have security
flaws if someone decides to take a close look at them. The issue is
that *that whole design* is suboptimal.

What we really wanted to happen with the switch was for apps that need
higher privileges for some operation to be rewritten such that they
could use polkit to signal a more privileged executable (ideally one
that *already runs* privileged, so there's no greater attack surface
than before) to perform that operation, and otherwise run unprivileged.

pkexec was a less-good second choice option for apps where there didn't
seem to be much prospect of anyone doing the work to move to a better
design. It at least let us get rid of consolehelper from most
installations, so we had fewer 'run-this-thing-as-root' tools to worry
about. Switching from pkexec to any other 'run-this-thing-as-root' tool
would not be an improvement. Moving to a more sophisticated design
using polkit's other capabilities would be an improvement.

I wouldn't consider a non-default leaf package that's probably not very
widely installed to be much of a priority in any case. We still
actually have several things in the distro that never moved off
consolehelper! Things that are default parts of our key editions and
spins would be much higher priority for this.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

[Adam Williamson]

On Mon, 2022-01-31 at 16:00 +0100, Miroslav Suchý wrote:
>  Dne 27. 01. 22 v 0:18 Adam Williamson napsal(a):
>  > BTW, bonus follow-up to this: as part of researching the background of
>  > polkit, I noticed that we never actually entirely got done moving off
>  > usermode:(  There are still over a dozen packages in the distro that
>  > require it:
>  
>  Moving off to where? 
To polkit, was the original intention. That's what the Feature says:
https://fedoraproject.org/wiki/Features/UsermodeMigration

>  FYI there is tracking bug
>  
>  [Tracker] Deprecate consolehelper and switch apps to use PolicyKit 1 for Fedora 12
>  
>  https://bugzilla.redhat.com/show_bug.cgi?id=502765 
Yes, I know, it's the tracker bug for the above feature :)
>  
>  but lots of the bugs are closed as DEFERED or WONTFIX. 
Yes, I know, check who closed them and when ;) Several of them were
"me, last week". But there are several I had to leave open because I
verified the package was still in the distro and still using
consolehelper, and several tools for which either a bug was never
filed, or it was closed without the migration being done, or they
started using consolehelper later.
>  
>  I tried to migrate Mock out of consolehelper
>  
>  https://bugzilla.redhat.com/show_bug.cgi?id=502749
>  https://github.com/rpm-software-management/mock/issues/684 
Aha, mock was actually the big one on the list that I wondered about,
so thanks for filling that in.
>  
>  but very soon I discovered that documentation of PolicyKit is nearly non-existent. At
> least, it is not sufficient to do 
>  the migration. After reading the code I found that it is likely missing functionality of
> consolehelper.
>  
>  I had a discussion with maintainer of PolicyKit and we both come conclusion that
> PolicyKit stopped in the middle of 
>  nowhere and for me and Mock is better to stay with consolehelper.
>  
>  Does the situation have changed? 
I don't know. I can't tell from the above what documentation or
functionality you're missing, and that info doesn't seem to be in the
ticket or bug you linked either (except a very vague mention of needing
"to handle ENV".) I don't know when your conversations and research
took place, so it's hard to say what's changed since.

polkit's maintainer has changed twice (I think) since the time this
feature was introduced, it's currently Jan Rybar. The current polkit
documentation is at
https://www.freedesktop.org/software/polkit/docs/latest/ .
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

[Sam Varshavchik]

Demi Marie Obenour writes:

>  What would break if sudo was replaced by an IPC service that ran
>  sudo as if it was setuid root, without it actually being setuid root?
>  I imagine the hardest part would be TTY handling, as not being able
>  to Ctrl-C a command launched by sudo is a rather poor user experience. 
File descriptors can be sent across filesystem sockets, this can be done.  
Once that's over the fence, perusing the relevant man pages suggests a  
combination of setpgid and tcsetpgrp should get the job done.

But, still: every additional line of code written to implement something is  
an additional line with a potential bug. In a security-sensitive context, it  
won't surprise me if trying to chase the separated server process unicorn  
ends up creating more bugs than a simple suid program ever had in its  
decades' of existence.

[Sam Varshavchik]

Lennart Poettering writes:

>  See the discussion around seccomp and NNP. i.e. a new kernel
> facility
>  was added precisely to ensure that seccomp cannot be used to run code
>  that is intended to be run privileged – under security policies in
>  control by an unprivileged user. i.e. if you can take certain privs
>  away from code that expects to have them you might be able to trigger
>  vulnerable codepaths that the developer didn't expect you to be able
>  to trigger.
>
>  But anyway, don't focus so much in cgroups here. There are plenty
>  other props these days that sudo doesn#t clean up. consider this for 
Ok, so where's the track record of potential security exploits, in similar  
kinds of tools, that: 1) leverage any of the resources that you mentioned,  
and 2) but were mitigated, and became ordinary bugs, thanks to the  
vulnerable code being an isolated daemon process, with a clean environment.

In absence of an established track record that demonstrates this, in  
practice, this becomes just a theory. So, I'm not sure that it's clear to me  
-- is this getting argued based on an established track record, with some  
data to look at, the shows – based on some basic metrics – the benefits of  
rewriting suid programs in this manner; or is this just a theoretical  
argument.

Every additional line of code written to architect a privileged process, in  
this new manner, is a potential spot for a new bug to grow.

Rolling out a brand-spanking update, with a new architecture, new  
bootstrapping mechanism, and a new unprivileged process will become a  
Pyrrhic victory a year later, when it turns out that the privileged process  
trusted input from the unprivileged process, as an indirect result of new  
serialization/deserialization code that had to be written. That's where the  
bulk of the work was. And validating the deserialized data structure was  
accidentally overlooked.

Or the new serialization/deserialization code has its own buffer overflows.  
That would be code that didn't exist in the original, monolithic setuid  
executable.

[Steve Grubb]

Hello Mirek,

This is the most constructive reply I've seen in this thread.

On Monday, January 31, 2022 1:12:50 PM EST Miloslav Trmac wrote:
>  > But doesn't satisfy our security requirements. If the kernel
> dbus project
>  > had been successful, then Linux would have had a rock solid basis to
>  > allow impersonation which would satisfy the security requirements and
>  > allow the desktop actually go through a common criteria certification if
>  > any one ever  wanted to do that. But as it stands, anything created by
>  > IPC is missing the necessary security context.
>  
>  I mean, yes. I read that as not a reason to stick with set-uid, but as a
>  reason to make that a priority, and drive the investment and the cultural
>  change; otherwise Linux security is just going to keep falling behind. OTOH
>  with the consolehelper history and a lot of similar examples, I don’t know
>  how to do any of that (make it a priority, drive the investment, drive the
>  cultural change). 
Linux needs a first class impersonation mechanism. This would be where the 
kernel bestows upon a process, certain attributes from another process. Both 
sides should agree so that no toke kidnapping is possible or forcing 
credentials on an unsuspecting process. With something like this, we can 
start to solve the security problems caused by IPC instantiation. I was 
really hoping kernel dbus was successful way back when.


>  > And access decisions do not go through the audit system.
>  
>  For polkit, that would be… a 20-line patch?  
Probably a little more. The auditing would need to be selective and by admin 
control. Meaning, the admin may decide that they want auditing of one 
application's permission grants and not the other.

>  Sure, the invoking user’s configuration can be trusted only to the
> extent a
>  D-Bus server provides it correctly to Polkit, making the D-Bus servers a
>  part of the trusted codebase. Still, that would be pretty valuable at least
>  until the first successful exploit. 
I was hoping with kernel dbus, polkit would have examined the connections 
itself and asked the kernel for veracity of the request. I really wished that 
was given another try and everyone agreed on why it was necessary so that it 
could be articulated well to the people that have to say yes/no to the patch.

-Steve

[Andrew Lutomirski]

On Mon, Jan 31, 2022 at 5:24 PM Steve Grubb <sgrubb(a)redhat.com&gt; wrote:
>  Hello Mirek,
>
>  This is the most constructive reply I've seen in this thread.
>
>  On Monday, January 31, 2022 1:12:50 PM EST Miloslav Trmac wrote:
>  > > But doesn't satisfy our security requirements. If the kernel dbus project
>  > > had been successful, then Linux would have had a rock solid basis to
>  > > allow impersonation which would satisfy the security requirements and
>  > > allow the desktop actually go through a common criteria certification if
>  > > any one ever  wanted to do that. But as it stands, anything created by
>  > > IPC is missing the necessary security context.
>  >
>  > I mean, yes. I read that as not a reason to stick with set-uid, but as a
>  > reason to make that a priority, and drive the investment and the cultural
>  > change; otherwise Linux security is just going to keep falling behind. OTOH
>  > with the consolehelper history and a lot of similar examples, I don’t know
>  > how to do any of that (make it a priority, drive the investment, drive the
>  > cultural change).
>
>  Linux needs a first class impersonation mechanism. This would be where the
>  kernel bestows upon a process, certain attributes from another process. Both
>  sides should agree so that no toke kidnapping is possible or forcing
>  credentials on an unsuspecting process. With something like this, we can
>  start to solve the security problems caused by IPC instantiation. I was
>  really hoping kernel dbus was successful way back when.
>  
Windows has a first class impersonation mechanism, and it's really
quite complicated and far from rock solid.  I don't think Linux should
go that direction.

But I'm a bit baffled by the assertion that anything created by IPC is
missing the necessary security context.  The entire world of
distributed systems is missing this security context.  When I issue
REST request or a gRPC request or really any network request at all, I
have precisely whatever context I specifically authenticate with for
that call.  And, other than the fact that most systems use rather weak
authentication systems (mostly bearer tokens), this is *good* -- it
means that the credential being presented is, by construction,
intentional on the part of the presenter.  It also means that
incorrect inferences aren't drawn.  For example, in a world where an
entire security context comes along with a request, if process A asks
database server B to write a row *over a network*, and B asks the
filesystem (C) to do the write, we don't magically attribute more of
B's context than we should to the write.

I would love to see a nice security model for IPC in the Linux kernel,
but I haven't seen a credible proposal.  This problem is *hard*.

As for setuid, I'm strongly of the opinion that setuid was and remains
a mistake.  Executing a process should never add privileges.
Replacing sudo, etc well probably requires a mechanism by which a
process can allow a daemon to either create children of that process
or replace that process (in the exec sense).  The SELinux label to
apply to the newly created process should be the daemon's decision --
it's far from obvious that a sudo'd program should inherit sudo's
caller's label.

--Andy

>
> > > And access decisions do not go through the audit system.
> >
> > For polkit, that would be… a 20-line patch?
>
> Probably a little more. The auditing would need to be selective and by admin
> control. Meaning, the admin may decide that they want auditing of one
> application's permission grants and not the other.
>
> > Sure, the invoking user’s configuration can be trusted only to the extent a
> > D-Bus server provides it correctly to Polkit, making the D-Bus servers a
> > part of the trusted codebase. Still, that would be pretty valuable at least
> > until the first successful exploit.
>
> I was hoping with kernel dbus, polkit would have examined the connections
> itself and asked the kernel for veracity of the request. I really wished that
> was given another try and everyone agreed on why it was necessary so that it
> could be articulated well to the people that have to say yes/no to the patch.
>
> -Steve
>
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

[Neal Gompa]

On Mon, Jan 31, 2022 at 8:19 PM Steve Grubb <sgrubb(a)redhat.com&gt; wrote:
>  Hello Mirek,
>
>  This is the most constructive reply I've seen in this thread.
>
>  On Monday, January 31, 2022 1:12:50 PM EST Miloslav Trmac wrote:
>  > > But doesn't satisfy our security requirements. If the kernel dbus project
>  > > had been successful, then Linux would have had a rock solid basis to
>  > > allow impersonation which would satisfy the security requirements and
>  > > allow the desktop actually go through a common criteria certification if
>  > > any one ever  wanted to do that. But as it stands, anything created by
>  > > IPC is missing the necessary security context.
>  >
>  > I mean, yes. I read that as not a reason to stick with set-uid, but as a
>  > reason to make that a priority, and drive the investment and the cultural
>  > change; otherwise Linux security is just going to keep falling behind. OTOH
>  > with the consolehelper history and a lot of similar examples, I don’t know
>  > how to do any of that (make it a priority, drive the investment, drive the
>  > cultural change).
>
>  Linux needs a first class impersonation mechanism. This would be where the
>  kernel bestows upon a process, certain attributes from another process. Both
>  sides should agree so that no toke kidnapping is possible or forcing
>  credentials on an unsuspecting process. With something like this, we can
>  start to solve the security problems caused by IPC instantiation. I was
>  really hoping kernel dbus was successful way back when.
>
>
>  > > And access decisions do not go through the audit system.
>  >
>  > For polkit, that would be… a 20-line patch?
>
>  Probably a little more. The auditing would need to be selective and by admin
>  control. Meaning, the admin may decide that they want auditing of one
>  application's permission grants and not the other.
>
>  > Sure, the invoking user’s configuration can be trusted only to the extent a
>  > D-Bus server provides it correctly to Polkit, making the D-Bus servers a
>  > part of the trusted codebase. Still, that would be pretty valuable at least
>  > until the first successful exploit.
>
>  I was hoping with kernel dbus, polkit would have examined the connections
>  itself and asked the kernel for veracity of the request. I really wished that
>  was given another try and everyone agreed on why it was necessary so that it
>  could be articulated well to the people that have to say yes/no to the patch. 
An in-kernel first-class IPC would make tremendous inroads in Linux
security, but who is going to drive that anymore? Bus1
(https://bus1.org/) hasn't been touched since 2019. Bus1 had an RFC in
2016 on LKML[1] and that's it.

We *could* use Binder, but there's a general lethargy around trying to
leverage stuff from the Android/ChromeOS ecosystem to benefit regular
Linux systems. We *do* have it enabled in our kernel, but that's
mainly for the eventual support of Waydroid in Fedora Mobile.

So what should we do? I don't know. It seems the answer everyone else
offers is "give up". I don't like that answer, but what else can we
do?

[1]: https://lkml.org/lkml/2016/10/26/963



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Demi Marie Obenour]

On 1/31/22 21:15, Neal Gompa wrote:
>  On Mon, Jan 31, 2022 at 8:19 PM Steve Grubb <sgrubb(a)redhat.com&gt;
> wrote:
> >
> > Hello Mirek,
> >
> > This is the most constructive reply I've seen in this thread.
> >
> > On Monday, January 31, 2022 1:12:50 PM EST Miloslav Trmac wrote:
> >>> But doesn't satisfy our security requirements. If the kernel dbus
> project
> >>> had been successful, then Linux would have had a rock solid basis to
> >>> allow impersonation which would satisfy the security requirements and
> >>> allow the desktop actually go through a common criteria certification if
> >>> any one ever  wanted to do that. But as it stands, anything created by
> >>> IPC is missing the necessary security context.
> >>
> >> I mean, yes. I read that as not a reason to stick with set-uid, but as a
> >> reason to make that a priority, and drive the investment and the cultural
> >> change; otherwise Linux security is just going to keep falling behind. OTOH
> >> with the consolehelper history and a lot of similar examples, I don’t know
> >> how to do any of that (make it a priority, drive the investment, drive the
> >> cultural change).
> >
> > Linux needs a first class impersonation mechanism. This would be where the
> > kernel bestows upon a process, certain attributes from another process. Both
> > sides should agree so that no toke kidnapping is possible or forcing
> > credentials on an unsuspecting process. With something like this, we can
> > start to solve the security problems caused by IPC instantiation. I was
> > really hoping kernel dbus was successful way back when.
> >
> >
> >>> And access decisions do not go through the audit system.
> >>
> >> For polkit, that would be… a 20-line patch?
> >
> > Probably a little more. The auditing would need to be selective and by admin
> > control. Meaning, the admin may decide that they want auditing of one
> > application's permission grants and not the other.
> >
> >> Sure, the invoking user’s configuration can be trusted only to the extent a
> >> D-Bus server provides it correctly to Polkit, making the D-Bus servers a
> >> part of the trusted codebase. Still, that would be pretty valuable at least
> >> until the first successful exploit.
> >
> > I was hoping with kernel dbus, polkit would have examined the connections
> > itself and asked the kernel for veracity of the request. I really wished that
> > was given another try and everyone agreed on why it was necessary so that it
> > could be articulated well to the people that have to say yes/no to the patch.
>  
>  An in-kernel first-class IPC would make tremendous inroads in Linux
>  security, but who is going to drive that anymore? Bus1
>  (https://bus1.org/) hasn't been touched since 2019. Bus1 had an RFC in
>  2016 on LKML[1] and that's it.
>  
>  We *could* use Binder, but there's a general lethargy around trying to
>  leverage stuff from the Android/ChromeOS ecosystem to benefit regular
>  Linux systems. We *do* have it enabled in our kernel, but that's
>  mainly for the eventual support of Waydroid in Fedora Mobile. 
Why not use Binder?  It is *the* in-tree solution for fast IPC.

-- 
Sincerely,
Demi Marie Obenour
she/her/hers

[Miroslav Suchý]

Dne 31. 01. 22 v 20:39 Adam Williamson napsal(a):
> > but very soon I discovered that documentation of PolicyKit is
> nearly non-existent. At least, it is not sufficient to do
> > the migration. After reading the code I found that it is likely missing functionality
> of consolehelper.
> >
> > I had a discussion with maintainer of PolicyKit and we both come conclusion that
> PolicyKit stopped in the middle of
> > nowhere and for me and Mock is better to stay with consolehelper.
> >
> > Does the situation have changed?
>  I don't know. I can't tell from the above what documentation or
>  functionality you're missing, and that info doesn't seem to be in the
>  ticket or bug you linked either (except a very vague mention of needing
>  "to handle ENV".) I don't know when your conversations and research
>  took place, so it's hard to say what's changed since.
>
>  polkit's maintainer has changed twice (I think) since the time this
>  feature was introduced, it's currently Jan Rybar. The current polkit
>  documentation is at
>  https://www.freedesktop.org/software/polkit/docs/latest/  . 
The documentation seems to be slightly better, but after reading it I still have several
questions:

* what is the preferred way to run python scripts? Is it using pkexec in shebang (seems to
be discouraged in this 
thread) or using this technique?:

https://stackoverflow.com/questions/32332128/how-to-use-polkit-with-pytho...

* what is the best way to mimic KEEP_ENV_VARS from `userhelper(8)`?

Miroslav

[Lennart Poettering]

On Mo, 31.01.22 18:32, Sam Varshavchik (mrsam(a)courier-mta.com) wrote:

>  Lennart Poettering writes:
>
>  > See the discussion around seccomp and NNP. i.e. a new kernel facility
>  > was added precisely to ensure that seccomp cannot be used to run code
>  > that is intended to be run privileged – under security policies in
>  > control by an unprivileged user. i.e. if you can take certain privs
>  > away from code that expects to have them you might be able to trigger
>  > vulnerable codepaths that the developer didn't expect you to be able
>  > to trigger.
>  >
>  > But anyway, don't focus so much in cgroups here. There are plenty
>  > other props these days that sudo doesn#t clean up. consider this for
>
>  Ok, so where's the track record of potential security exploits, in similar
>  kinds of tools, that: 1) leverage any of the resources that you mentioned,
>  and 2) but were mitigated, and became ordinary bugs, thanks to the
>  vulnerable code being an isolated daemon process, with a clean
>  environment. 
I already described you a vulnerability. And the vulnerabilities in
sudo from not cleaning up env vars are pretty well documented, too no?
And they are the same kind: not cleaned up context.

The thing is that most security researches are probably more
interested in root escalation issues than in local DoS. That doesn't
mean local DoS was OK, it just means that people are out for other
trophies, and the vuln I explained is a DoS one. Hence it's not
surprising the vuln doesn#t have a fancy website or name or so, but
nevertheless it makes our platform weaker.

Lennart

--
Lennart Poettering, Berlin

[Sam Varshavchik]

Lennart Poettering writes:

>  On Mo, 31.01.22 18:32, Sam Varshavchik (mrsam(a)courier-mta.com)
> wrote:
>
>  > Lennart Poettering writes:
>  >
>  > > See the discussion around seccomp and NNP. i.e. a new kernel facility
>  > > was added precisely to ensure that seccomp cannot be used to run code
>  > > that is intended to be run privileged – under security policies in
>  > > control by an unprivileged user. i.e. if you can take certain privs
>  > > away from code that expects to have them you might be able to trigger
>  > > vulnerable codepaths that the developer didn't expect you to be able
>  > > to trigger.
>  > >
>  > > But anyway, don't focus so much in cgroups here. There are plenty
>  > > other props these days that sudo doesn#t clean up. consider this for
>  >
>  > Ok, so where's the track record of potential security exploits, in similar
>  > kinds of tools, that: 1) leverage any of the resources that you mentioned,
>  > and 2) but were mitigated, and became ordinary bugs, thanks to the
>  > vulnerable code being an isolated daemon process, with a clean
>  > environment.
>
>  I already described you a vulnerability. And the vulnerabilities in 
I must've missed those descriptions. Is there a reference somewhere that I  
can read, which describes them.

>  sudo from not cleaning up env vars are pretty well documented, too
> no?
>  And they are the same kind: not cleaned up context. 
A basic search finds the most recent sudo exploit was a heap based buffer  
overflow in sudo about a year ago. Something that can equally happen in an  
isolated process, too, if triggered the same way.

A more careful search located the sudo exploit you described, from 2014,  
CVE-2014-0106. I couldn't find anything similar in sudo's history, so this  
must be what you are referring to. Looks like it was in a non-default  
configuration, and after reading up the details of the exploit:

The only argument I see here, is that if the isolated process-based  
implementation of an sudo-alternative did not implement the non-env_reset  
option in the first place. If it did implement the non-env_reset related  
option, presumably there would've been some mechanism for the client to  
transmit its environment to the isolated process, for the benefit of the  
spawned subshell.

And it that turned out to be the case, the same exact bug would've happened.  
The process isolation would not've accomplished anything, here. The problem  
was not inherent with an suid-based approach. sudo had a broken  
implemenation of an optional configuration setting. If it was broken in the  
same way, in an isolated process, the lack of the setuid bit would not've  
made any material difference.

[Lennart Poettering]

On Di, 01.02.22 07:14, Sam Varshavchik (mrsam(a)courier-mta.com) wrote:

>  Lennart Poettering writes:
>
>  > On Mo, 31.01.22 18:32, Sam Varshavchik (mrsam(a)courier-mta.com) wrote:
>  >
>  > > Lennart Poettering writes:
>  > >
>  > > > See the discussion around seccomp and NNP. i.e. a new kernel facility
>  > > > was added precisely to ensure that seccomp cannot be used to run code
>  > > > that is intended to be run privileged – under security policies in
>  > > > control by an unprivileged user. i.e. if you can take certain privs
>  > > > away from code that expects to have them you might be able to trigger
>  > > > vulnerable codepaths that the developer didn't expect you to be able
>  > > > to trigger.
>  > > >
>  > > > But anyway, don't focus so much in cgroups here. There are plenty
>  > > > other props these days that sudo doesn#t clean up. consider this for
>  > >
>  > > Ok, so where's the track record of potential security exploits, in similar
>  > > kinds of tools, that: 1) leverage any of the resources that you mentioned,
>  > > and 2) but were mitigated, and became ordinary bugs, thanks to the
>  > > vulnerable code being an isolated daemon process, with a clean
>  > > environment.
>  >
>  > I already described you a vulnerability. And the vulnerabilities in
>
>  I must've missed those descriptions. Is there a reference somewhere that I
>  can read, which describes them. 
https://lists.fedoraproject.org/archives/list/[e-mail].o...

I explained a locking DoS there: run privileged code, but with
extremly restrictive resource scheduling settings, so that it will
acquire privileged resources such as locks (which it can, since it is
privileged) but is extremely slow to give up again since it runs
awfully slow, due to the extremely restrictive resource settings which
are under control of an unpriv caller.

>  > sudo from not cleaning up env vars are pretty well documented,
> too no?
>  > And they are the same kind: not cleaned up context.
>
>  A basic search finds the most recent sudo exploit was a heap based buffer
>  overflow in sudo about a year ago. Something that can equally happen in an
>  isolated process, too, if triggered the same way. 
CVE-2014-9680, CVE-2014-0106, CVE-2010-3853, CVE-2010-1646,
CVE-2008-3825, CVE-2006-0151, CVE-2005-4158, CVE-2005-3629,
CVE-2005-2959, CVE-2004-1051, CVE-2002-0043, …

These are all env var cleanup issues in su/sudo context.

Lennart

--
Lennart Poettering, Berlin

[Kevin Kofler]

Lennart Poettering wrote:
>  CVE-2014-9680, CVE-2014-0106, CVE-2010-3853, CVE-2010-1646,
>  CVE-2008-3825, CVE-2006-0151, CVE-2005-4158, CVE-2005-3629,
>  CVE-2005-2959, CVE-2004-1051, CVE-2002-0043, …
>  
>  These are all env var cleanup issues in su/sudo context. 
And the environment variable cleanup (which is uncontestably necessary for 
security (*)) also comes with collateral damage that makes it a bad idea to 
run monolithic GUI programs under such tools, see, e.g.:
https://bugzilla.redhat.com/show_bug.cgi?id=1171779

(*) Now, arguably, the default configuration of pkexec actually does *not*
    need the cleanup because it does not allow unprivileged users to run
    only selected commands, but both sudo and pkexec can be configured to
    allow that, and then you need to prevent the invoker from getting
    arbitrary code execution through environment variable hacks.

(Of course, D-Bus-activating those GUI programs will not work either. They 
need to be split into unprivileged GUI and privileged helper(s).)

        Kevin Kofler

[Sam Varshavchik]

Lennart Poettering writes:

>  On Di, 01.02.22 07:14, Sam Varshavchik (mrsam(a)courier-mta.com)
> wrote:
>
>  > Lennart Poettering writes:
>  >
>  > > On Mo, 31.01.22 18:32, Sam Varshavchik (mrsam(a)courier-mta.com) wrote:
>  > >
>  > > > Lennart Poettering writes:
>  > > >
>  > > > > See the discussion around seccomp and NNP. i.e. a new kernel
> facility
>  > > > > was added precisely to ensure that seccomp cannot be used to run
> code
>  > > > > that is intended to be run privileged – under security policies in
>  > > > > control by an unprivileged user. i.e. if you can take certain privs
>  > > > > away from code that expects to have them you might be able to
> trigger
>  > > > > vulnerable codepaths that the developer didn't expect you to be
> able
>  > > > > to trigger.
>  > > > >
>  > > > > But anyway, don't focus so much in cgroups here. There are
> plenty
>  > > > > other props these days that sudo doesn#t clean up. consider this for
>  > > >
>  > > > Ok, so where's the track record of potential security exploits, in  
>  similar
>  > > > kinds of tools, that: 1) leverage any of the resources that you  
>  mentioned,
>  > > > and 2) but were mitigated, and became ordinary bugs, thanks to the
>  > > > vulnerable code being an isolated daemon process, with a clean
>  > > > environment.
>  > >
>  > > I already described you a vulnerability. And the vulnerabilities in
>  >
>  > I must've missed those descriptions. Is there a reference somewhere that I
>  > can read, which describes them.
>
>
> https://lists.fedoraproject.org/archives/list/[e-mail].o...
>
>  I explained a locking DoS there: run privileged code, but with
>  extremly restrictive resource scheduling settings, so that it will
>  acquire privileged resources such as locks (which it can, since it is
>  privileged) but is extremely slow to give up again since it runs
>  awfully slow, due to the extremely restrictive resource settings which
>  are under control of an unpriv caller. 
And an isolated process will be capable of rate-limiting itself in this  
situation any better than a sudo process, which could do the same kind of  
rate-limiting itself, exactly how?

About the only thing that works to its advantage is that it'll be in a  
better position to employ rate limiting, by its virtue of being persistent.

But if this is a concern, there's a much better, hybrid approach. The user- 
initiated executable would be a setuid executable that connects to a  
filesystem socket, with the permissions adjusted so that only a privileged  
process can connect to it.

This mitigates resource attacks that establish connections to the persistent  
daemon, and just hold them open, without doing anything. Depending on the  
particulars the setuid executable could do its own sanity checks first,  
before establishing a connection to the persistent daemon, for the next step  
in the process.

The suid bit itself is not a problem. Much like everything else, it is a  
useful tool when used correctly. But just because it is used incorrectly,  
sometimes, doesn't make it bad. And I tend to avoid making an absolute one- 
size-fits-all, blanket assumption on the order of "X is bad". That's a bit 

simplistic, and too naive for my taste. I'd rather take a look at each  
individual situation, on its own merits, and figure out the best solution.

An excellent example would be what happened to OpenSSH. My understanding is  
that they shuffled off all authentication stuff into a separate daemon that  
runs with restricted privileges. This is not quite a good analogue for sudo,  
there is no setuid bit involved here. But this is the right approach:  
analyze the individual situation, and figure out the best solution. For  
OpenSSH it seems to be what they picked to do, which makes a lot of sense.

>  > > sudo from not cleaning up env vars are pretty well
> documented, too no?
>  > > And they are the same kind: not cleaned up context.
>  >
>  > A basic search finds the most recent sudo exploit was a heap based buffer
>  > overflow in sudo about a year ago. Something that can equally happen in an
>  > isolated process, too, if triggered the same way.
>
>  CVE-2014-9680, CVE-2014-0106, CVE-2010-3853, CVE-2010-1646,
>  CVE-2008-3825, CVE-2006-0151, CVE-2005-4158, CVE-2005-3629,
>  CVE-2005-2959, CVE-2004-1051, CVE-2002-0043, …
>
>  These are all env var cleanup issues in su/sudo context. 
Picking a few of them, at random:

CVE-2006-0151: https://bugzilla.redhat.com/show_bug.cgi?id=139478

# Statement for NVD:
#
# If an administrator is concerned that users who have been granted sudo  
# privileges can alter the environment, the existing "env_reset" option should 

# be used which cleans the whole environment.

Mic drop.

CVE-2005-3629: this is initscripts, not sudo, the topic here.

CVE-2008-3825: this is PAM, not sudo.

CVE-2014-9680: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1191144

Looks like env_reset does not reset the TZ variable – that's a bug in that  
option. Going back to the current thought experiment: what if sudo was a  
persistent daemon?

Well, this CVE actually proves my point: a persistent daemon would not've  
made any difference, whatsoever! If all the other sudo drivers were still in  
play, I'm fairly confident that the same exact bug would've happened, and  
having an isolated process would not've done anything.

TZ was intentionally excluded from sudo's clean environment. Why's that? 
Well, I can see sudo's original line of thinking, crystal clear: it would've  
been rather rude for the spawned subshell to pop up in a different timezone.  
So, sudo intentionally did not launder TZ for that exact reason.

Well, if the same drivers were in place on the alternate-Earth, where sudo  
used an isolated daemon, the same drivers would've been present, and the  
alternate-sudo would've made arrangements for the caller's TZ to be carried  
to the spawned subshell, overriding the isolated daemon's inherited TZ.

End result: same thing.

[Lennart Poettering]

On Di, 01.02.22 09:01, Sam Varshavchik (mrsam(a)courier-mta.com) wrote:

>  >
> https://lists.fedoraproject.org/archives/list/[e-mail].o...
>  >
>  > I explained a locking DoS there: run privileged code, but with
>  > extremly restrictive resource scheduling settings, so that it will
>  > acquire privileged resources such as locks (which it can, since it is
>  > privileged) but is extremely slow to give up again since it runs
>  > awfully slow, due to the extremely restrictive resource settings which
>  > are under control of an unpriv caller.
>
>  And an isolated process will be capable of rate-limiting itself in this
>  situation any better than a sudo process, which could do the same kind of
>  rate-limiting itself, exactly how? 
"Rate-limiting"? Not sure what "rate-limiting" has to do with any of
this.

If priv code runs with extremely low prio, and acquires a shared
resource, that other priv code might wait for that isn't low prio,
then you have a classic prio inversion issue. because the higher prio
code will be slowed down to the level of the low prio process, which
can be used to DoS things.

prio inversion issues are well known and more or less just bugs. But
they become a security issue once unpriv code has control of the prios
of priv code and can bring the system to a standstill hence. Which is
the case here with sudo.

(i.e. the fact that sudo dosn't at least do a simple
setpriority(PRIO_PROCESS, 0, 0); is beyond me...)

>  About the only thing that works to its advantage is that it'll be
> in a
>  better position to employ rate limiting, by its virtue of being
>  persistent. 
So, apparently I am beyond terrible in explaining the issue, given
your unrelated responses. But I don't think I am going to waste more
time on this. If my explanations weren't useful now I doubt I can
improve them, so let's end this specific branch of the thread
here.

>  An excellent example would be what happened to OpenSSH. My
> understanding is
>  that they shuffled off all authentication stuff into a separate daemon that
>  runs with restricted privileges. This is not quite a good analogue for sudo,
>  there is no setuid bit involved here. But this is the right approach:
>  analyze the individual situation, and figure out the best solution. For
>  OpenSSH it seems to be what they picked to do, which makes a lot of
>  sense. 
Yeah, OpenSSH split up its stuff into multiple processes that talk to
each other via IPC and where privs are never acquired, but only
lost. it's the perfect example of how to actually do things well, and
*not* using setuid because it's a broken design.

>  CVE-2006-0151: https://bugzilla.redhat.com/show_bug.cgi?id=139478
>
>  # Statement for NVD:
>  #
>  # If an administrator is concerned that users who have been granted sudo #
>  privileges can alter the environment, the existing "env_reset" option should
>  # be used which cleans the whole environment.
>
>  Mic drop.
>
>  CVE-2005-3629: this is initscripts, not sudo, the topic here.
>
>  CVE-2008-3825: this is PAM, not sudo.
>
>  CVE-2014-9680:
>  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1191144 
These are all issues where insufficent process context cleanup
(specifically env var cleanup) made setuid transitions
exploitable. It's always the same issue.

Anyway, I understand your love suid and sudo. But please accept that
some people, me being one of them, think the concept is a very bad
idea. Some others have voiced their takes already on this mailing
list. Let's end this branch of the thread here, it's really pointless
from my PoV I just keep repeating myself.

Lennart

--
Lennart Poettering, Berlin

[Sam Varshavchik]

Lennart Poettering writes:

>  On Di, 01.02.22 09:01, Sam Varshavchik (mrsam(a)courier-mta.com)
> wrote:
>
>  > And an isolated process will be capable of rate-limiting itself in this
>  > situation any better than a sudo process, which could do the same kind of
>  > rate-limiting itself, exactly how?
>
>  "Rate-limiting"? Not sure what "rate-limiting" has to do with any of
>  this. 
Rate limiting is a generic term. It doesn't only mean "how often  
something happens". Anyway:

>  If priv code runs with extremely low prio, and acquires a shared
>  resource, that other priv code might wait for that isn't low prio,
>  then you have a classic prio inversion issue. because the higher prio
>  code will be slowed down to the level of the low prio process, which
>  can be used to DoS things. 
The relevant part would be "limiting". Something that repeatedly does what's
 
described here could be described as a rate-limiting problem, but that's a  
minor issue. More importantly: it seems to me that an isolated daemon which  
acquires the same resource, on behalf of a low-priority, unprivileged  
process, will also end up block a higher-priority unprivileged process from  
getting that resource, in the same manner. Not sure how this would address  
priority inversion.

Perhaps one can say that an isolated process might factor this in, then  
juggle the competing resource requests based on the requesters' priorities.  
But that sounds like a lot of work for me, and more complicated work for a  
privileged process to do. More opportunities for bugs to happen. Bugs in  
privileged processes are bad.

But I want to closely focus on the exact "shared resource" part here, and  
examine the actual requirements. I really don't like discussing things in  
this kind of a general manner. Practical details matter to me. I would like  
to dig into the specific, actual instance here, on its own merits.

Is this shared resource really needed to be used in the manner that makes it  
possible for priority inversion to happen; or can it be used differently,  
somehow, in a way to avoids it. The questions to answer should be a little  
bit more sophisticated than "how to remove an setuid bit from a program,  
this'll fix all the problems".

>  prio inversion issues are well known and more or less just bugs. But
>  they become a security issue once unpriv code has control of the prios
>  of priv code and can bring the system to a standstill hence. Which is
>  the case here with sudo.
>
>  (i.e. the fact that sudo dosn't at least do a simple
>  setpriority(PRIO_PROCESS, 0, 0); is beyond me...) 
Maybe it should, maybe this is a good idea. Maybe it makes sense for a shell  
with elevated privileges to start with a lowered priority by default, and  
root would be able to elevate its privileges if needed. I don't play root  
very often, I have no opinion, but this is an unrelated topic.

But if I was convinced that it was a good idea then this is what I would do  
already: contacting the sudo-stewards and submitting a patch. It's worth a  
shot, and that's what I would do, if it bugged me. A few years ago, because  
of a crazy reason, I thought that adding a few bits to libxcb would be a  
useful thing to do, and I did exactly that. And they agreed!  So, rather  
than wondering, why doesn't X do Y, how about: take the bull by the horns  
and see what happens?

>  Yeah, OpenSSH split up its stuff into multiple processes that talk
> to
>  each other via IPC and where privs are never acquired, but only
>  lost. it's the perfect example of how to actually do things well, and
>  *not* using setuid because it's a broken design. 
I would agree: having openssh being a suid program is …not recommended.

>  Anyway, I understand your love suid and sudo. 
I love suid and sudo no more, no less, and exactly the same as I love my  
screwdriver. I'm married to neither. Both are just tools. Both can be used,  
by people, correctly. Both can be used also, by people, incorrectly. But it  
makes no sense to use that as a reason for replacing screwdrivers with  
wrenches.

>  But please accept that
>  some people, me being one of them, think the concept is a very bad
>  idea. Some others have voiced their takes already on this mailing
>  list. 
I never claimed that others are not allowed to have different opinions, or  
there's something wrong with them if they do. I have to admit that a long  
time ago I might've believed something like that. But I'm older now and I  
recognize that others will have different opinions. I'm not affiliated with  
sudo, in any way, and have no skin in the game. If they choose to update  
sudo to work in the described way, more power to them and we'll see how that  
works out. If Fedora decides to get sudo replaced by some alternative that  
works this way, we'll see how well that works out too, when it happens.