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. 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@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
