Fedora 37 Looks To Make pkexec Optional For Improved Security

[9Strike]

FYI, Debian already did that.

[RahulSundaram]

I think the point is that Linux counterparts exist, but they are terrible in comparison either because they are so convoluted that most developers don't bother using them (which from a security standpoint is failure) or the security is being applied by the wrong party.

Lately Linux seems to be just copying security mechanisms from BSD's basically because the implementation is both simple and also solves the problem.

In general, the issue isn't that Linux counterparts are terrible, the issue is that the Linux development model is much more distributed, it is not a single operating system managed by one entity, its a plethora of solutions that are managed by different possibly competing interests with different use cases that they want to manage. Distributed development models lead to less fundamental forks like in the BSD space but it can take a while to find a leading solution and in some cases, there isn't a strong leading contender and we live with multiple solutions. There are just different tradeoffs to different models of development. Copying viable solutions is a good thing and it happens across the board.

[kylew77]

Can you expand more on this topic? What is pledge/unveil?

Happy to! Pledge lets a program or process say I will only use these resources, for example stdio or the network or a few other options. pkg_add is the package management software for OpenBSD and it has a user named _pkg_fetch that pledges the network and its only job is to fetch content over the Internet for example. Programs can drop privileges when they don't need them but never gain them back with pledge so if a program say needs to read a file at the beginning of its run it can then call pledge and not be able to read files anymore. Unveil is really interesting in my opinion and an equivalent is available in Linux as part of SELlinux. For example, Chromium can only download and read files from /home/<username>/Downloads or /tmp and of course its executable file. This means even if a bug is found in Chromium that lets say a javascript website read files in your home directory like your .ssh directory it literally can't see that part of the directory structure! It is obscured from view. This guy Bob Beck wrote Unveil and here is a link to his presentation on it: https://www.openbsd.org/papers/bsdca...eil/index.html https://www.openbsd.org/papers/eurobsdcon2018-unveil/ Here is one about pledge https://www.openbsd.org/papers/BeckP...BSDCan2018.pdf

I used Bob Beck's work in my paper, which unfortunately was just for a class in my Masters in IT program and never got published. I had it hosted on my personal website but couldn't afford to pay for web hosting for a bit so the site is down for now. Hope to get it going again soon and it will host my paper.

If you have any more questions I will try to answer them. I know some C programing but am not an OS programer.

[cl333r]

I'm just a Linux user, why isn't pkexec fixed instead?

[RahulSundaram]

I'm just a Linux user, why isn't pkexec fixed instead?

You maybe missing the fact the vulnerability is already fixed but since pkexec is largely unused, splitting off the package makes it possible to not install the pkexec binary as part of polkit by default which reduces the default attack surface.

[cl333r]

You maybe missing the fact the vulnerability is already fixed but since pkexec is largely unused, splitting off the package makes it possible to not install the pkexec binary as part of polkit by default which reduces the default attack surface.

I'm using pkexec, to me it didn't seem like "largely unused". What should applications relying on the existence of pkexec use instead? Some other executable or some DBus interface?

[RahulSundaram]

I'm using pkexec, to me it didn't seem like "largely unused". What should applications relying on the existence of pkexec use instead? Some other executable or some DBus interface?

"Largely unused" refers to other default software components within the distribution which use the interface directly. They don't call out a binary.

[CommunityMember]

What should applications relying on the existence of pkexec use instead?

There is no single right answer, as it depends on the details. Sometimes the applications should be using targeted capabilities rather than running with full root privs in the first place, sometimes various IPC mechanisms, etc. Realistically all the changes to fully drop pkexec will take some time to happen (some parts of the discussion happened over a decade ago, but the (hard) work got deferred), but now that pkexec has resulted in a serious CVE people have been given some reason to go back and revisit how to reduce the need for pkexec (and some of its brethren).

[cl333r]

There is no single right answer, as it depends on the details. Sometimes the applications should be using targeted capabilities rather than running with full root privs in the first place, sometimes various IPC mechanisms, etc. Realistically all the changes to fully drop pkexec will take some time to happen (some parts of the discussion happened over a decade ago, but the (hard) work got deferred), but now that pkexec has resulted in a serious CVE people have been given some reason to go back and revisit how to reduce the need for pkexec (and some of its brethren).

Yeah, I get the overall picture, but it's strange to me that while all other software (including the Linux kernel and all browsers) regularly fix security holes yet nobody is trying to replace them, or drop them by default.

[mSparks]

I'm using pkexec, to me it didn't seem like "largely unused". What should applications relying on the existence of pkexec use instead? Some other executable or some DBus interface?

pkexec is probably a good option?