Messages in this thread | | | From | Andy Lutomirski <> | Date | Tue, 1 Sep 2015 12:35:52 -0700 | Subject | Re: kdbus_proc_permission (Re: [GIT PULL] kdbus updates for Greg) |
| |
On Tue, Sep 1, 2015 at 12:04 PM, Josh Boyer <jwboyer@fedoraproject.org> wrote: > On Tue, Sep 1, 2015 at 2:31 PM, Andy Lutomirski <luto@amacapital.net> wrote: >> On Tue, Sep 1, 2015 at 10:13 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote: >>> On Mon, Aug 31, 2015 at 3:09 PM, Andy Lutomirski <luto@amacapital.net> wrote: >>>> On Mon, Aug 31, 2015 at 9:22 AM, David Herrmann <dh.herrmann@gmail.com> wrote: >>>>> Hi >>>>> >>>>> On Mon, Aug 31, 2015 at 5:37 PM, Andy Lutomirski <luto@amacapital.net> wrote: >>>>>> On Mon, Aug 24, 2015 at 2:52 AM, David Herrmann <dh.herrmann@gmail.com> wrote: >>>>>>> On Mon, Aug 10, 2015 at 4:42 AM, Andy Lutomirski <luto@amacapital.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. > > 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
| |