linux-kernel - Re: kdbus_proc_permission (Re: [GIT PULL] kdbus updates for Greg)

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 13:11: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 12:54 PM, Josh Boyer <jwboyer@...oraproject.org> wrote:
> On Tue, Sep 1, 2015 at 3:35 PM, Andy Lutomirski <luto@...capital.net> wrote:
>> No one in user namespace land has considered it acceptable for an old
>> userspace that's running a new kernel with user namespaces turned on
>> to have security problems as a result of user namespaces.  It's
>> happened, but it's considered a problem to be fixed with high
>> priority.  I'd be reassured if kdbus took a similar stance.
>
> And again, I'm not sure why you think the kdbus developers aren't?
> You haven't found any security holes.  They haven't submitted a pull
> request for 4.3.  As far as I can tell, things are still being worked
> on and developed as expected.  I personally really appreciate your
> diligence on the security aspects of kdbus.  Frankly, I hope you _do_
> find security holes so that they can be fixed before it is merged.
> But I've not seen anything that would indicate to me the kdbus
> developers would ignore such an issue if you found one.
>

David said:

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.

If he means that I should wait for kdbus to gain LSM support and that
kdbus won't go upstream until that happens, then that's a little bit
better.  But there's still an issue that probably can't be addressed
purely in the kernel: unless some more magic that I'm not aware of in
the existing userspace SELinux tooling (and all the other LSMs), then
existing LSM policies will be insecure even on new kernels.  Maybe the
LSM people consider this to be okay, but that would surprise me a
little bit.  Or maybe kdbus with LSM hooks defaults to rejecting all
metadata protected kdbus_proc_permission if the loaded policy doesn't
explicitly support the new hooks.  I really don't know.

For all I know, this is a security hole as is -- it depends rather
strongly on what people are doing with SELinux.

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