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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 1 Sep 2015 15:54:05 -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 3:35 PM, Andy Lutomirski <luto@...capital.net> wrote:
> On Tue, Sep 1, 2015 at 12:04 PM, Josh Boyer <jwboyer@...oraproject.org> wrote:
>> 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.
>>
>
> This does highlight a difference in configurations that the upstream
> kernel configures supported versus what Fedora considers supported.
> From Fedora's POV (correct me if I'm wrong), if you boot with a kernel
> with an unsupported configuration, it's unsupported.  From the
> upstream kernel's POV, if you flip on new features and boot an old
> distro, it's supposed to work with *very* few exceptions.

Well, mostly.  We've certainly turned on configuration options in the
Fedora kernel, reported problems with them, and been told by upstream
"why would you enable that?  It's not ready/relevant for distro use."
So in theory I agree with you, but not everyone follows those rules it
seems.

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

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/