On Mon, Jan 31, 2022 at 8:19 PM Steve Grubb <sgrubb(a)redhat.com>
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