On 1/31/22 21:15, Neal Gompa wrote: > On Mon, Jan 31, 2022 at 8:19 PM Steve Grubb <sgrubb@xxxxxxxxxx> 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
Attachment:
OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
