Re: F37 Change: Make pkexec and pkla-compat optional (Self-Contained Change proposal)
On Fri, 2022-02-18 at 13:54 +0100, Lennart Poettering wrote: > > sudo is what users/admins use. pkexec is what (desktop) programs often use. In which case we can have the programs that use it depend on it, so at least we have those requirements mapped distinctly. To me it makes more sense to say "let's install pkexec when we are also installing something that uses it" than "let's install pkexec any time we install polkit". > Then don't. But whether you use it or whether it's "legacy"/should go > away are two distinct questions. I agree, but your argument read to me like "we must keep it installed even when no program that uses it is installed, for interactive use", which I disagree with. I think focusing on the word "legacy" misses the point. The real meat of the idea for me is "let's only install it when it's needed", which I think would be good. Still, if it's as tied in to Workstation as it seems to be, the effort may not be worthwhile. We'd only ultimately be able to drop it, maybe, from minimal and Server installs. If it still has to be in KDE and Workstation installs, the value of doing all the work to separate it and find all the packages that use it may not be worthwhile. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Make pkexec and pkla-compat optional (Self-Contained Change proposal)
On Mi, 16.02.22 15:01, Adam Williamson (adamw...@fedoraproject.org) wrote: > > > hence I am not against the feature but please tone down the wording > > > regarding pkexec, it's misleading. Say you want to split it out to > > > reduce the attack surface, but don't use the word "legacy" in its > > > context. > > > > > > (dropping "pkla-compat" given its unmaintained state is Ok to be > > > called "legacy" i guess) > > > > I think I'd go stronger and say I don't really see the value in > > splitting out pkexec at all. I'd rather people have a default path to > > do safer privilege escalation, and pkexec is way better than > > sudo/doas/etc in that regard. > > This feels a bit unrealistic to me. In the real world, I can recall off > the top of my head exactly zero docs, guides, articles, howtos etc. > that use pkexec. They all use sudo. Like it or not, sudo is what people > use. The sensible thing to do there is devote attention to making sure > sudo is as secure as possible, or actually make some kind of big effort > to convince people to use pkexec instead. sudo is what users/admins use. pkexec is what (desktop) programs often use. docs/guides/articles/howtos are focussed on users/admins. hence of course, you won't find it mentioned there. > I just tried this, actually, for giggles. Two reasons it's a non- > starter: it prompts for the root password, not for my user password (my > user is an 'admin' so far as sudo etc. are concerned, but apparently > not an 'admin' so far as interactive pkexec is concerned). I do not > know the root password, it is intentionally a 24-character random > string I would have to look up. When I hit "pkexec" a nice GNOME shell prompt pops up asking me for *my* password, not root's. > And it prompts with one of those > goddamn 'secure' GNOME popovers which prevents you accessing your > password manager, so every time you hit one, you have to cancel it, go > to your password manager, copy the password it wants, then trigger it > again. > > No way on earth I'm using that. Then don't. But whether you use it or whether it's "legacy"/should go away are two distinct questions. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Make pkexec and pkla-compat optional (Self-Contained Change proposal)
On Thu, 2022-02-17 at 15:29 -0500, Owen Taylor wrote: > > I just tried this, actually, for giggles. Two reasons it's a non- > > starter: it prompts for the root password, not for my user password (my > > user is an 'admin' so far as sudo etc. are concerned, but apparently > > not an 'admin' so far as interactive pkexec is concerned). I do not > > know the root password, it is intentionally a 24-character random > > string I would have to look up. And it prompts with one of those > > goddamn 'secure' GNOME popovers which prevents you accessing your > > password manager, so every time you hit one, you have to cancel it, go > > to your password manager, copy the password it wants, then trigger it > > again. > > > > I think you misinterpreted the prompt. Assuming your user is in the wheel > group: > > "Authentication is needed to run '' as the superuser' > > Isn't asking for the root password, but rather your password to do > something as root. Nope. The name shown was "Administrator" (which means it wants the root password), and entering my user password does not work. Entering the root password does. This may not be the case for everyone, but hey, I just did a quick test on my desktop, and that's what I found. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Make pkexec and pkla-compat optional (Self-Contained Change proposal)
On Wed, 16 Feb 2022 09:17:41 -0800 Adam Williamson wrote: > On Wed, 2022-02-16 at 12:12 -0500, Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/polkit_recommends_pkla_pkexec > > > > == Summary == > > Split `pkexec` from the polkit package and make it a recommended > > only sub-package. Similarly, make the polkit-pkla-compat package a > > recommended package too. This will enable users and desktop no > > longer relying on those features to avoid installing them. > > Splitting them off but making them Recommended seems odd to me. At > that point we've got all the work of splitting them but little of the > benefit, because soft dependencies are included when building images, > so our default installs are still going to include pkexec. > > Why not just not have them recommended at all, and instead try to find > all packages that use them and add dependencies, so that they will be > included when an image or whatever really does need them? Is that > considered too difficult? I woould prefer having hard dependencies on the necessary packages instead of a recommends. Some of us run with weak dependencies turned off and the missing requires will break things for us. Having the recommends in place will mask the breakage instead of letting it be caught in testing. Jim ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Make pkexec and pkla-compat optional (Self-Contained Change proposal)
On Wed, Feb 16, 2022 at 12:14 PM Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/polkit_recommends_pkla_pkexec > [..] > `pkexec` and `pkla-compat` > ([https://src.fedoraproject.org/rpms/polkit-pkla-compat package]) are > legacy tools that are no longer needed on a desktop and increase the > attack surface as they are SetUID binaries (`pkexec`) or not > maintained anymore (`pkla-compat`). For pkexec, "no longer needed on a desktop" definitely does not reflect the situation for Fedora Workstation and GNOME. If you run: grep org.freedesktop.policykit.exec.path /usr/share/polkit-1/actions/* there is considerable usage - there are config files using pkexec provided by, among others: gamemode, fedora-third-party, systemd, gnome-control-center, gnome-system-monitor, gnome-settings-daemon, gvfs, Would it be possible to rewrite all of the usage as D-Bus services? Yes - but it would be considerable work and risk of new bugs and regressions. (fedora-third-party is a recent addition by me - I considered not using pkexec and writing a service instead, but it seemed like extra work and complexity for little gain.) If KDE or another desktop doesn't use pkexec, and there's a desire to split pkexec out in packaging and add explicit dependencies on it, I'm not opposed to that, but I don't think we should be calling pkexec legacy, and it would require considerable (upstream, not just Fedora) changes to remove the usage in Workstation. - Owen ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Make pkexec and pkla-compat optional (Self-Contained Change proposal)
On Wednesday, February 16, 2022 6:01:48 PM EST Adam Williamson wrote: > I just tried this, actually, for giggles. Two reasons it's a non- > starter: it prompts for the root password, not for my user password > (my user is an 'admin' so far as sudo etc. are concerned, but > apparently not an 'admin' so far as interactive pkexec is > concerned). That is odd. I am never prompted for the root password for anything. Maybe this is a policy difference between GNOME and KDE. My supplemental groups: wheel mock systemd-journal wireshark > I do not know the root password, it is intentionally a > 24-character random string I would have to look up. And it prompts > with one of those goddamn 'secure' GNOME popovers which prevents you > accessing your password manager, so every time you hit one, you have > to cancel it, go to your password manager, copy the password it > wants, then trigger it again. > > No way on earth I'm using that. Again, in KDE, there is a prompt for MY password and it is only modal as far as the pkexec command is concerned. I can open my password manager before responding to the prompt (not that I need to, since it wants my password -- not root's). Anyway, until this discussion, I never knew there was a pkexec. I note that pkexec will not operate correctly outside of my KDE session. It prompts for my password from a terminal session and then fails with $ pkexec ls AUTHENTICATING FOR org.freedesktop.policykit.exec Authentication is needed to run `/usr/bin/ls' as the super user Authenticating as: Garry T. Williams (garry) Password: polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie AUTHENTICATION FAILED Error executing command as another user: Not authorized This incident has been reported. $ Of course, sudo will operate correctly without a desktop session. I don't think I will be eager to use pkexec instead of sudo. -- Garry T. Williams ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Make pkexec and pkla-compat optional (Self-Contained Change proposal)
On Thu, Feb 17, 2022 at 2:28 PM Adam Williamson wrote: > On Wed, 2022-02-16 at 13:55 -0500, Neal Gompa wrote: > > On Wed, Feb 16, 2022 at 12:38 PM Lennart Poettering > > wrote: > > > > > > On Mi, 16.02.22 12:12, Ben Cotton (bcot...@redhat.com) wrote: > > > > > > > `pkexec` and `pkla-compat` > > > > ([https://src.fedoraproject.org/rpms/polkit-pkla-compat package]) > are > > > > legacy tools that are no longer needed on a desktop and increase the > > > > attack surface as they are SetUID binaries (`pkexec`) or not > > > > maintained anymore (`pkla-compat`). > > > > > > I find this wording weird... I seriously doubt we should consider > > > "pkexec" legacy. It's the much nicer approach to the "sudo" problem, > > > as mentioned in earlier discussions... > > > > > > Splitting it off into a separate package might be OK, but claiming > > > that the fact that it is a suid binary makes it "legacy" sounds really > > > strange to me, by that means we should also mark "sudo", "su", "ping", > > > "mount", "umount", "write", "passwd", … and so on "legacy", but I > > > doubt we are at that point, are we? > > > > > > hence I am not against the feature but please tone down the wording > > > regarding pkexec, it's misleading. Say you want to split it out to > > > reduce the attack surface, but don't use the word "legacy" in its > > > context. > > > > > > (dropping "pkla-compat" given its unmaintained state is Ok to be > > > called "legacy" i guess) > > > > > > > I think I'd go stronger and say I don't really see the value in > > splitting out pkexec at all. I'd rather people have a default path to > > do safer privilege escalation, and pkexec is way better than > > sudo/doas/etc in that regard. > > This feels a bit unrealistic to me. In the real world, I can recall off > the top of my head exactly zero docs, guides, articles, howtos etc. > that use pkexec. They all use sudo. Like it or not, sudo is what people > use. The sensible thing to do there is devote attention to making sure > sudo is as secure as possible, or actually make some kind of big effort > to convince people to use pkexec instead. > > But just shipping pkexec as well as sudo by default is IMHO not helping > anything, all it does is add unnecessary attack surface. I bet you > could shoulder-surf for an entire weekend at Flock and not see a single > person type 'pkexec'. > Perhaps it actually works well that pkexec is used for "behind-the-scenes" privilege escalation, and sudo is what people are familiar with for interactive and sysadmin-configured use. PolKit and hence pkexec can make decisions on things that sudo doesn't have an idea about like the idea of "logged in at a graphical console", but they aren't really useful if you just want to quickly run a command as root with authentication. I just tried this, actually, for giggles. Two reasons it's a non- > starter: it prompts for the root password, not for my user password (my > user is an 'admin' so far as sudo etc. are concerned, but apparently > not an 'admin' so far as interactive pkexec is concerned). I do not > know the root password, it is intentionally a 24-character random > string I would have to look up. And it prompts with one of those > goddamn 'secure' GNOME popovers which prevents you accessing your > password manager, so every time you hit one, you have to cancel it, go > to your password manager, copy the password it wants, then trigger it > again. > I think you misinterpreted the prompt. Assuming your user is in the wheel group: "Authentication is needed to run '' as the superuser' Isn't asking for the root password, but rather your password to do something as root. - Owen ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Make pkexec and pkla-compat optional (Self-Contained Change proposal)
On Wed, 2022-02-16 at 13:55 -0500, Neal Gompa wrote: > On Wed, Feb 16, 2022 at 12:38 PM Lennart Poettering > wrote: > > > > On Mi, 16.02.22 12:12, Ben Cotton (bcot...@redhat.com) wrote: > > > > > `pkexec` and `pkla-compat` > > > ([https://src.fedoraproject.org/rpms/polkit-pkla-compat package]) are > > > legacy tools that are no longer needed on a desktop and increase the > > > attack surface as they are SetUID binaries (`pkexec`) or not > > > maintained anymore (`pkla-compat`). > > > > I find this wording weird... I seriously doubt we should consider > > "pkexec" legacy. It's the much nicer approach to the "sudo" problem, > > as mentioned in earlier discussions... > > > > Splitting it off into a separate package might be OK, but claiming > > that the fact that it is a suid binary makes it "legacy" sounds really > > strange to me, by that means we should also mark "sudo", "su", "ping", > > "mount", "umount", "write", "passwd", … and so on "legacy", but I > > doubt we are at that point, are we? > > > > hence I am not against the feature but please tone down the wording > > regarding pkexec, it's misleading. Say you want to split it out to > > reduce the attack surface, but don't use the word "legacy" in its > > context. > > > > (dropping "pkla-compat" given its unmaintained state is Ok to be > > called "legacy" i guess) > > > > I think I'd go stronger and say I don't really see the value in > splitting out pkexec at all. I'd rather people have a default path to > do safer privilege escalation, and pkexec is way better than > sudo/doas/etc in that regard. This feels a bit unrealistic to me. In the real world, I can recall off the top of my head exactly zero docs, guides, articles, howtos etc. that use pkexec. They all use sudo. Like it or not, sudo is what people use. The sensible thing to do there is devote attention to making sure sudo is as secure as possible, or actually make some kind of big effort to convince people to use pkexec instead. But just shipping pkexec as well as sudo by default is IMHO not helping anything, all it does is add unnecessary attack surface. I bet you could shoulder-surf for an entire weekend at Flock and not see a single person type 'pkexec'. I just tried this, actually, for giggles. Two reasons it's a non- starter: it prompts for the root password, not for my user password (my user is an 'admin' so far as sudo etc. are concerned, but apparently not an 'admin' so far as interactive pkexec is concerned). I do not know the root password, it is intentionally a 24-character random string I would have to look up. And it prompts with one of those goddamn 'secure' GNOME popovers which prevents you accessing your password manager, so every time you hit one, you have to cancel it, go to your password manager, copy the password it wants, then trigger it again. No way on earth I'm using that. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Make pkexec and pkla-compat optional (Self-Contained Change proposal)
> https://fedoraproject.org/wiki/Changes/polkit_recommends_pkla_pkexec > See in progress PR: https://src.fedoraproject.org/rpms/polkit/pull-request/2 From a comment in the PR: > IMHO making polkit-pkla-compat optional is seriously risky. The > configuration can contain “if user=foo deny” entries, and silently > ignoring those configuration files can break the security of the > system. If polkit indeed treats rules it doesn't have currently support for as always satisfied, I would treat this is a blocker for splitting out polkit-pkla-compat. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Make pkexec and pkla-compat optional (Self-Contained Change proposal)
On Wed, Feb 16, 2022 at 12:38 PM Lennart Poettering wrote: > > On Mi, 16.02.22 12:12, Ben Cotton (bcot...@redhat.com) wrote: > > > `pkexec` and `pkla-compat` > > ([https://src.fedoraproject.org/rpms/polkit-pkla-compat package]) are > > legacy tools that are no longer needed on a desktop and increase the > > attack surface as they are SetUID binaries (`pkexec`) or not > > maintained anymore (`pkla-compat`). > > I find this wording weird... I seriously doubt we should consider > "pkexec" legacy. It's the much nicer approach to the "sudo" problem, > as mentioned in earlier discussions... > > Splitting it off into a separate package might be OK, but claiming > that the fact that it is a suid binary makes it "legacy" sounds really > strange to me, by that means we should also mark "sudo", "su", "ping", > "mount", "umount", "write", "passwd", … and so on "legacy", but I > doubt we are at that point, are we? > > hence I am not against the feature but please tone down the wording > regarding pkexec, it's misleading. Say you want to split it out to > reduce the attack surface, but don't use the word "legacy" in its > context. > > (dropping "pkla-compat" given its unmaintained state is Ok to be > called "legacy" i guess) > I think I'd go stronger and say I don't really see the value in splitting out pkexec at all. I'd rather people have a default path to do safer privilege escalation, and pkexec is way better than sudo/doas/etc in that regard. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Make pkexec and pkla-compat optional (Self-Contained Change proposal)
> I find this wording weird... I seriously doubt we should consider > "pkexec" legacy. It's the much nicer approach to the "sudo" > problem, > as mentioned in earlier discussions... > > Splitting it off into a separate package might be OK, but claiming > that the fact that it is a suid binary makes it "legacy" sounds really > strange to me, by that means we should also mark "sudo", "su", > "ping", > "mount", "umount", "write", "passwd", … and so on > "legacy", but I > doubt we are at that point, are we? > > hence I am not against the feature but please tone down the wording > regarding pkexec, it's misleading. Say you want to split it out to > reduce the attack surface, but don't use the word "legacy" in its > context. > > (dropping "pkla-compat" given its unmaintained state is Ok to be > called "legacy" i guess) I agree that the wording is stronger than it should be. I'll update that. -- Timothée Ravier CoreOS engineer & Fedora Kinoite maintainer ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Make pkexec and pkla-compat optional (Self-Contained Change proposal)
> Splitting them off but making them Recommended seems odd to me. At that > point we've got all the work of splitting them but little of the > benefit, because soft dependencies are included when building images, > so our default installs are still going to include pkexec. > > Why not just not have them recommended at all, and instead try to find > all packages that use them and add dependencies, so that they will be > included when an image or whatever really does need them? Is that > considered too difficult? I went with Recommends to be conservative. We could indeed make them fully optional if we end up being confident we will not break the default user experience. -- Timothée Ravier CoreOS engineer & Fedora Kinoite maintainer ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Make pkexec and pkla-compat optional (Self-Contained Change proposal)
On Mi, 16.02.22 12:12, Ben Cotton (bcot...@redhat.com) wrote: > `pkexec` and `pkla-compat` > ([https://src.fedoraproject.org/rpms/polkit-pkla-compat package]) are > legacy tools that are no longer needed on a desktop and increase the > attack surface as they are SetUID binaries (`pkexec`) or not > maintained anymore (`pkla-compat`). I find this wording weird... I seriously doubt we should consider "pkexec" legacy. It's the much nicer approach to the "sudo" problem, as mentioned in earlier discussions... Splitting it off into a separate package might be OK, but claiming that the fact that it is a suid binary makes it "legacy" sounds really strange to me, by that means we should also mark "sudo", "su", "ping", "mount", "umount", "write", "passwd", … and so on "legacy", but I doubt we are at that point, are we? hence I am not against the feature but please tone down the wording regarding pkexec, it's misleading. Say you want to split it out to reduce the attack surface, but don't use the word "legacy" in its context. (dropping "pkla-compat" given its unmaintained state is Ok to be called "legacy" i guess) Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Make pkexec and pkla-compat optional (Self-Contained Change proposal)
On Wed, 2022-02-16 at 12:12 -0500, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/polkit_recommends_pkla_pkexec > > > == Summary == > Split `pkexec` from the polkit package and make it a recommended only > sub-package. Similarly, make the polkit-pkla-compat package a > recommended package too. This will enable users and desktop no longer > relying on those features to avoid installing them. Splitting them off but making them Recommended seems odd to me. At that point we've got all the work of splitting them but little of the benefit, because soft dependencies are included when building images, so our default installs are still going to include pkexec. Why not just not have them recommended at all, and instead try to find all packages that use them and add dependencies, so that they will be included when an image or whatever really does need them? Is that considered too difficult? Thanks! -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
F37 Change: Make pkexec and pkla-compat optional (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/polkit_recommends_pkla_pkexec == Summary == Split `pkexec` from the polkit package and make it a recommended only sub-package. Similarly, make the polkit-pkla-compat package a recommended package too. This will enable users and desktop no longer relying on those features to avoid installing them. == Owner == * Name: [[User:Siosm| Timothée Ravier]], Jan Rybar * Email: si...@fedoraproject.org, jry...@redhat.com == Detailed Description == `pkexec` and `pkla-compat` ([https://src.fedoraproject.org/rpms/polkit-pkla-compat package]) are legacy tools that are no longer needed on a desktop and increase the attack surface as they are SetUID binaries (`pkexec`) or not maintained anymore (`pkla-compat`). This change will thus split `pkexec` from the polkit package and make it a recommended only sub-package. Similarly, it will make the polkit-pkla-compat package a recommended package too. This will enable users and desktop no longer relying on those features to avoid installing them. Users that still need those features will easily be able to install them. See in progress PR: https://src.fedoraproject.org/rpms/polkit/pull-request/2 == Feedback == Related discussion in https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/ZDZACAMG2E3P4K4P2CVBQ3XBBZ7CYSXA/#Q6EK5NXFV5GEMW3RFTXIWT4NVNDKYKLG See in progress PR: https://src.fedoraproject.org/rpms/polkit/pull-request/2 == Benefit to Fedora == Increased security, less legacy software installed by default, moving to a more secure desktop by default. == Scope == * Proposal owners: ** Test as many desktop environments as possible and add the new dependencies for the packages requiring either polkit-pkla-compat rules support or pkexec. * Other developers: ** Test as many desktop environments as possible and add the new dependencies for the packages requiring either polkit-pkla-compat rules support or pkexec. * Release engineering: * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A * Alignment with Objectives: == Upgrade/compatibility impact == Nothing should happen during upgrades for existing systems as the packages are still available and will be kept as is and the new polkit-pkexec package will be installed for users not deselecting recommends. Only new installations that will not have those packages will be impacted and the risk of security issues with the pkla rules removal is low. == How To Test == 1. Install the polkit package from https://copr.fedorainfracloud.org/coprs/siosm/polkit/ 2. Remove the polkit-pkexec sub-package and polkit-pkla-compat package 3. Ensure that your applications and desktop environment are still working as intended. Focus on applications that require privileges. == User Experience == N/A == Dependencies == N/A == Contingency Plan == Revert the change. == Documentation == N/A (not a System Wide Change) == Release Notes == TODO -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@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/devel-announce@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
F37 Change: Make pkexec and pkla-compat optional (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/polkit_recommends_pkla_pkexec == Summary == Split `pkexec` from the polkit package and make it a recommended only sub-package. Similarly, make the polkit-pkla-compat package a recommended package too. This will enable users and desktop no longer relying on those features to avoid installing them. == Owner == * Name: [[User:Siosm| Timothée Ravier]], Jan Rybar * Email: si...@fedoraproject.org, jry...@redhat.com == Detailed Description == `pkexec` and `pkla-compat` ([https://src.fedoraproject.org/rpms/polkit-pkla-compat package]) are legacy tools that are no longer needed on a desktop and increase the attack surface as they are SetUID binaries (`pkexec`) or not maintained anymore (`pkla-compat`). This change will thus split `pkexec` from the polkit package and make it a recommended only sub-package. Similarly, it will make the polkit-pkla-compat package a recommended package too. This will enable users and desktop no longer relying on those features to avoid installing them. Users that still need those features will easily be able to install them. See in progress PR: https://src.fedoraproject.org/rpms/polkit/pull-request/2 == Feedback == Related discussion in https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/ZDZACAMG2E3P4K4P2CVBQ3XBBZ7CYSXA/#Q6EK5NXFV5GEMW3RFTXIWT4NVNDKYKLG See in progress PR: https://src.fedoraproject.org/rpms/polkit/pull-request/2 == Benefit to Fedora == Increased security, less legacy software installed by default, moving to a more secure desktop by default. == Scope == * Proposal owners: ** Test as many desktop environments as possible and add the new dependencies for the packages requiring either polkit-pkla-compat rules support or pkexec. * Other developers: ** Test as many desktop environments as possible and add the new dependencies for the packages requiring either polkit-pkla-compat rules support or pkexec. * Release engineering: * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A * Alignment with Objectives: == Upgrade/compatibility impact == Nothing should happen during upgrades for existing systems as the packages are still available and will be kept as is and the new polkit-pkexec package will be installed for users not deselecting recommends. Only new installations that will not have those packages will be impacted and the risk of security issues with the pkla rules removal is low. == How To Test == 1. Install the polkit package from https://copr.fedorainfracloud.org/coprs/siosm/polkit/ 2. Remove the polkit-pkexec sub-package and polkit-pkla-compat package 3. Ensure that your applications and desktop environment are still working as intended. Focus on applications that require privileges. == User Experience == N/A == Dependencies == N/A == Contingency Plan == Revert the change. == Documentation == N/A (not a System Wide Change) == Release Notes == TODO -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
