lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ