[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrV=1upVBxQHybFZ7BYmQmS5nSbeeCoX+_x_5Kf9SSjxMA@mail.gmail.com>
Date: Tue, 1 Sep 2015 11:31:19 -0700
From: Andy Lutomirski <luto@...capital.net>
To: Josh Boyer <jwboyer@...oraproject.org>
Cc: David Herrmann <dh.herrmann@...il.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Greg KH <gregkh@...uxfoundation.org>
Subject: Re: kdbus_proc_permission (Re: [GIT PULL] kdbus updates for Greg)
On Tue, Sep 1, 2015 at 10:13 AM, Josh Boyer <jwboyer@...oraproject.org> wrote:
> On Mon, Aug 31, 2015 at 3:09 PM, Andy Lutomirski <luto@...capital.net> wrote:
>> On Mon, Aug 31, 2015 at 9:22 AM, David Herrmann <dh.herrmann@...il.com> wrote:
>>> Hi
>>>
>>> On Mon, Aug 31, 2015 at 5:37 PM, Andy Lutomirski <luto@...capital.net> wrote:
>>>> On Mon, Aug 24, 2015 at 2:52 AM, David Herrmann <dh.herrmann@...il.com> wrote:
>>>>> On Mon, Aug 10, 2015 at 4:42 AM, Andy Lutomirski <luto@...capital.net> wrote:
>>>>>> I haven't checked the context in which it's used, but in order for
>>>>>> kdbus_proc_permission to do what it claims to do, it appears to be
>>>>>> missing calls to security_inode_permission and
>>>>>> security_file_permission.
>>>>>
>>>>> Both are expected to be added by lsm patches (both hooks you mentioned
>>>>> are empty if no lsm is selected).
>>>>
>>>> Will that mean that existing MAC policies stop being fully enforced
>>>> (in effect) if kdbus is installed?
>>>
>>> It means kdbus messages carry information about the sender, which LSMs
>>> might prevent you to read via /proc. Just like you can send dbus
>>> messages to a peer, which LSM-enhanced dbus-daemon might not allow.
>>
>> It's a security-sensitive function that doesn't do what the name and
>> description suggest. Whether that's an active problem or not is
>> unknown, but it's certainly a maintainability problem.
>>
>>> If
>>> you use LSMs, we clearly advise you to wait for kdbus to gain LSM
>>> support. We explicitly support legacy dbus1-compat for exactly such
>>> reasons.
>>
>> This is not an acceptable attitude for security.
>>
>> There are so many things wrong with your statement that I'll limit
>> myself to one of them: Fedora 23/Rawhide, which is the *reference*
>> platform, uses SELinux.
>
> Clarification: Fedora Rawhide only. The kdbus code is not included in
> the F23 kernel.
>
> Your point otherwise stands. I just don't want Phoronix or someone
> else getting confused and thinking Fedora 23 will ship with kdbus. It
> will not.
But a bunch of kdbus code does appear in Fedora 23 userspace, I think.
Granted, systemd is build with --disable-kdbus, but if it's a new
enough version, then I think that means that the code is still there.
To be clear, I don't claim to have found a specific security hole, but
in the event that running Fedora 23 with a kdbus-supporting kernel and
booting with kdbus=1 [1] introduces security problems, then we have a
problem. (This isn't nearly as bad as it would be if we had problems
just by upgrading the kernel.) And there is certainly something wrong
with the process if the kdbus team thinks it's okay that enabling
kdbus can break existing security policy.
--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists