Message-ID: <CA+5PVA5maoh-T3HDJQ-BzX69wnWPwyxsnvYLZv7dremSQro9sA@mail.gmail.com>
Date:	Tue, 1 Sep 2015 15:04:19 -0400
From:	Josh Boyer <jwboyer@...oraproject.org>
To:	Andy Lutomirski <luto@...capital.net>
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 2:31 PM, Andy Lutomirski <luto@...capital.net> wrote:
> 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.

You seem to have interpreted my email as argumentation.  I don't want
to argue.  I simply want to point out that Fedora 23 will not ship
with kdbus in the kernel.  Therefore the Fedora 23 release, for its
entire supported timeframe, will not utilize kdbus.

So if someone wants to rebuild a kernel that contains the kdbus driver
and jump through the hoops you describe, then yes they might very well
run into problems you suggest might be present.  However, they will
also not be running Fedora 23 at that point.  I wish such users well
and thank them for their upstream testing efforts.

To be honest, I'm not sure what "process" you're talking about.
Kernel development is kind of rife with examples of new features
having security issues and it taking time to sort them out.  I don't
mean to cast aspersions, but user namespaces has had numerous CVEs
since it's inclusion.  I don't think anyone here has ever accused its
development of not following some kind of process.  And distros took
some time before enabling that feature, which is what I expect to
happen with kdbus should it ever be merged.  That certainly isn't an
argument for allowing _known_ security issues into the kernel, but as
you said, you haven't found a security hole as of yet.

josh
--
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