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

[Josh Boyer]

On Tue, Sep 1, 2015 at 4:11 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote:
> On Tue, Sep 1, 2015 at 12:54 PM, Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> wrote:
>> On Tue, Sep 1, 2015 at 3:35 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> 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

FWIW, that's how I interpreted it.  Mostly because I haven't seen a
pull for 4.3 yet.

> 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

Isn't that a bit chicken and egg though?  I mean, we can coordinate
between the SELinux policy people to get it lined up as best as
possible.  Though when it comes to SELinux policy, the kernel rolls
out new features and userspace typically lags behind a bit.

I have no experience with other LSMs.

> metadata protected kdbus_proc_permission if the loaded policy doesn't
> explicitly support the new hooks.  I really don't know.

That's a possibility.  I also don't know.  I'd have to go look at the
proposed LSM patches again and I haven't see a revision of those in a
while.

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

Confining things through xattr labels on inodes.  ;)  FWIW, despite
warnings to the contrary, the test system I have does boot just fine
with SELinux in Enforcing mode.  It is likely the least scientific and
useful scenario though, as it is just a dumb headless NUC box that all
I do is test kernels on.  I won't even pretend that my mention here is
anything more than an anecdote along the lines of "cool story, bro."

josh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/