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

[Andy Lutomirski]

On Tue, Sep 1, 2015 at 12:04 PM, Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> wrote:
> On Tue, Sep 1, 2015 at 2:31 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote:
>> On Tue, Sep 1, 2015 at 10:13 AM, Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> wrote:
>>> On Mon, Aug 31, 2015 at 3:09 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote:
>>>> On Mon, Aug 31, 2015 at 9:22 AM, David Herrmann <dh.herrmann@xxxxxxxxx> wrote:
>>>>> Hi
>>>>>
>>>>> On Mon, Aug 31, 2015 at 5:37 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote:
>>>>>> On Mon, Aug 24, 2015 at 2:52 AM, David Herrmann <dh.herrmann@xxxxxxxxx> wrote:
>>>>>>> On Mon, Aug 10, 2015 at 4:42 AM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> 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.

I don't want to argue either :)

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

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

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