Re: CVE-2021-4034: why is pkexec still a thing?
Lennart Poettering writes: On Di, 01.02.22 09:01, Sam Varshavchik (mr...@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. pgpsrbL1UNcIV.pgp Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-
Re: CVE-2021-4034: why is pkexec still a thing?
On Di, 01.02.22 09:01, Sam Varshavchik (mr...@courier-mta.com) wrote: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/B2ZCFBIM3AWBUFJKNHGZWPLZZDZPH43Y/ > > > > 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 ___ 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: CVE-2021-4034: why is pkexec still a thing?
Lennart Poettering writes: On Di, 01.02.22 07:14, Sam Varshavchik (mr...@courier-mta.com) wrote: > Lennart Poettering writes: > > > On Mo, 31.01.22 18:32, Sam Varshavchik (mr...@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/devel@lists.fedoraproject.org/message/B2ZCFBIM3AWBUFJKNHGZWPLZZDZPH43Y/ 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?
Re: CVE-2021-4034: why is pkexec still a thing?
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 ___ 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: CVE-2021-4034: why is pkexec still a thing?
On Di, 01.02.22 07:14, Sam Varshavchik (mr...@courier-mta.com) wrote: > Lennart Poettering writes: > > > On Mo, 31.01.22 18:32, Sam Varshavchik (mr...@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/devel@lists.fedoraproject.org/message/B2ZCFBIM3AWBUFJKNHGZWPLZZDZPH43Y/ 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 ___ 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: CVE-2021-4034: why is pkexec still a thing?
Lennart Poettering writes: On Mo, 31.01.22 18:32, Sam Varshavchik (mr...@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. pgpZwrbUzSEPJ.pgp Description: PGP signature ___ 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: CVE-2021-4034: why is pkexec still a thing?
On Mo, 31.01.22 18:32, Sam Varshavchik (mr...@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 ___ 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: CVE-2021-4034: why is pkexec still a thing?
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-python-to-run-systemd-d-bus-commands-from-non-root-user * what is the best way to mimic KEEP_ENV_VARS from `userhelper(8)`? Miroslav ___ 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: CVE-2021-4034: why is pkexec still a thing?
On 1/31/22 21:15, Neal Gompa wrote: > On Mon, Jan 31, 2022 at 8:19 PM Steve Grubb 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 OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ 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: CVE-2021-4034: why is pkexec still a thing?
On Mon, Jan 31, 2022 at 8:19 PM Steve Grubb 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! ___ 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: CVE-2021-4034: why is pkexec still a thing?
On Mon, Jan 31, 2022 at 5:24 PM Steve Grubb 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@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 ___ 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 Lis
Re: CVE-2021-4034: why is pkexec still a thing?
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 ___ 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: CVE-2021-4034: why is pkexec still a thing?
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. pgp55rJYDskLq.pgp Description: PGP signature ___ 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: CVE-2021-4034: why is pkexec still a thing?
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. pgp4xGszFYaqp.pgp Description: PGP signature ___ 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: CVE-2021-4034: why is pkexec still a thing?
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 ___ 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: CVE-2021-4034: why is pkexec still a thing?
On Mon, 2022-01-31 at 10:19 +, 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 ___ 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: CVE-2021-4034: why is pkexec still a thing?
Hello, po 31. 1. 2022 v 18:13 odesílatel Steve Grubb napsal: > On Monday, January 31, 2022 5:36:24 AM EST Lennart Poettering wrote: > > On Fr, 28.01.22 18:16, Sam Varshavchik (mr...@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 ___ 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: CVE-2021-4034: why is pkexec still a thing?
po 31. 1. 2022 v 13:49 odesílatel Sam Varshavchik 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 ___ 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: CVE-2021-4034: why is pkexec still a thing?
On Monday, January 31, 2022 5:36:24 AM EST Lennart Poettering wrote: > On Fr, 28.01.22 18:16, Sam Varshavchik (mr...@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 ___ 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: CVE-2021-4034: why is pkexec still a thing?
On 1/31/22 05:36, Lennart Poettering wrote: > On Fr, 28.01.22 18:16, Sam Varshavchik (mr...@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) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ 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: CVE-2021-4034: why is pkexec still a thing?
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 ___ 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: CVE-2021-4034: why is pkexec still a thing?
On Mo, 31.01.22 07:46, Sam Varshavchik (mr...@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 ___ 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: CVE-2021-4034: why is pkexec still a thing?
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 ___ 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: CVE-2021-4034: why is pkexec still a thing?
Lennart Poettering writes: On Mo, 31.01.22 06:28, Sam Varshavchik (mr...@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. pgpV1sx3dVyIw.pgp Description: PGP signature ___ 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: CVE-2021-4034: why is pkexec still a thing?
On Mo, 31.01.22 06:28, Sam Varshavchik (mr...@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 ___ 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: CVE-2021-4034: why is pkexec still a thing?
Lennart Poettering writes:
On Fr, 28.01.22 18:16, Sam Varshavchik (mr...@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.
pgpum4oRyqCIY.pgp
Description: PGP signature
___
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: CVE-2021-4034: why is pkexec still a thing?
On Fr, 28.01.22 11:26, Adam Williamson (adamw...@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 ___ 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: CVE-2021-4034: why is pkexec still a thing?
On Fr, 28.01.22 18:16, Sam Varshavchik (mr...@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 ___ 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: CVE-2021-4034: why is pkexec still a thing?
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! ___ 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: CVE-2021-4034: why is pkexec still a thing?
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_cc-remote-login-helper ___ 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: CVE-2021-4034: why is pkexec still a thing?
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 Fedora Project Leader ___ 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: CVE-2021-4034: why is pkexec still a thing?
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 ___ 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: CVE-2021-4034: why is pkexec still a thing?
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. pgpORP9dsoEYP.pgp Description: PGP signature ___ 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: CVE-2021-4034: why is pkexec still a thing?
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-aria...@dereferenced.org/T/#u And it's already in the mmotm tree so just a matter of time until it reaches linux master -- Dominique ___ 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: CVE-2021-4034: why is pkexec still a thing?
On Fri, Jan 28, 2022 at 3:04 PM Robbie Harwood wrote: > > Adam Williamson 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! ___ 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: CVE-2021-4034: why is pkexec still a thing?
Adam Williamson 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 signature.asc Description: PGP signature ___ 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: CVE-2021-4034: why is pkexec still a thing?
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 ___ 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: CVE-2021-4034: why is pkexec still a thing?
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 ___ 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: CVE-2021-4034: why is pkexec still a thing?
On Fr, 28.01.22 10:55, Demi Marie Obenour (demioben...@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
___
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: CVE-2021-4034: why is pkexec still a thing?
On 1/28/22 11:38, Michael Catanzaro wrote: > On Fri, Jan 28 2022 at 10:55:43 AM -0500, Demi Marie Obenour > 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) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ 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: CVE-2021-4034: why is pkexec still a thing?
On Fri, Jan 28 2022 at 10:55:43 AM -0500, Demi Marie Obenour 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. ___ 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: CVE-2021-4034: why is pkexec still a thing?
On 1/28/22 05:41, Lennart Poettering wrote: > On Mi, 26.01.22 14:21, Adam Williamson (adamw...@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) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ 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: CVE-2021-4034: why is pkexec still a thing?
On Fr, 28.01.22 12:25, Florian Weimer (fwei...@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 ___ 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: CVE-2021-4034: why is pkexec still a thing?
* Lennart Poettering: > On Fr, 28.01.22 12:12, Florian Weimer (fwei...@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 ___ 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: CVE-2021-4034: why is pkexec still a thing?
On Fr, 28.01.22 12:12, Florian Weimer (fwei...@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 ___ 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: CVE-2021-4034: why is pkexec still a thing?
* 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 ___ 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: CVE-2021-4034: why is pkexec still a thing?
Hi Christian, I suppose that was not intentional, thanks for the PR. O. pá 28. 1. 2022 v 10:15 odesílatel Christian Stadelmann 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@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 ___ 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: CVE-2021-4034: why is pkexec still a thing?
On Mi, 26.01.22 14:21, Adam Williamson (adamw...@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 ___ 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: CVE-2021-4034: why is pkexec still a thing?
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@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: CVE-2021-4034: why is pkexec still a thing?
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 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-12-years-gives-attackers-root-on-every-major-linux-distro/ > > 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 -- desk...@lists.fedoraproject.org > To unsubscribe send an email to desktop-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/desk...@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ 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: CVE-2021-4034: why is pkexec still a thing?
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-initial-setup/gis-pkexec.c [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 ___ 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: CVE-2021-4034: why is pkexec still a thing?
On Thu, Jan 27, 2022 at 1:05 PM Matthew Miller 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! ___ 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: CVE-2021-4034: why is pkexec still a thing?
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 Fedora Project Leader ___ 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: CVE-2021-4034: why is pkexec still a thing?
> 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. ___ 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: CVE-2021-4034: why is pkexec still a thing?
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 ___ 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: CVE-2021-4034: why is pkexec still a thing?
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 ___ 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: CVE-2021-4034: why is pkexec still a thing?
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 ___ 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
CVE-2021-4034: why is pkexec still a thing?
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-12-years-gives-attackers-root-on-every-major-linux-distro/ 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 ___ 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
