| |||||||||||||
Jaunty not even getting security updates.Jaunty not even getting security updates.Posted Nov 22, 2010 7:47 UTC (Mon) by error27 (subscriber, #8346)In reply to: Jaunty not even getting security updates. by gmatht Parent article: Kernel prepatch 2.6.37-rc3
The rule is that you don't break userspace. It's a very simple rule to understand.
Sometimes it's a painful rule, but in this case it's easy. The commit breaks booting which is an important feature and anyway it's easy to get the same effect by doing a "chmod -r /proc/kallsyms" in the bootup scripts.
http://git.kernel.org/linus/33e0d57f5d2f079104611be9f3fcc...
(Log in to post comments)
Jaunty not even getting security updates. Posted Nov 22, 2010 12:10 UTC (Mon) by Karellen (subscriber, #67644) [Link]
Yes, but it's not an absolute rule. For instance, it normally doesn't override security. If there's a (mis)feature which allows attackers to get root on you machine, and userspace relies on it, in that case it's normally tough luck to userspace.
Which means I'm not sure I would agree with this revert, as the opposite effect should also be achievable in userspace with a "chmod +r /proc/kallsyms" early in the bootup scripts. Those that want or need to enable the original behaviour can do so, while completely eliminating the (albeit brief) period of lesser security that the revert introduces for all users.
Surely the kernel should be as secure as possible by default, no?
Jaunty not even getting security updates. Posted Nov 22, 2010 12:40 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]
Yeah. I think distributions should revert this revert and get a more secure default till the Jaunty thing is not a concern anymore.
Jaunty not even getting security updates. Posted Nov 22, 2010 14:02 UTC (Mon) by tao (subscriber, #17563) [Link]
You're missing something here. If the attacker can access the file during boot, they already has root privileges on your machine, since they were able to install an initscript...
That said, I agree that taking broken userland behaviour in consideration in this case is stupid; Jaunty is unlikely to ship 2.6.37 anyway. Anyone installing a non-distro kernel should know what they're doing, and thus be able to also patch the relevant package that breaks because of this.
Jaunty not even getting security updates. Posted Nov 22, 2010 15:22 UTC (Mon) by Karellen (subscriber, #67644) [Link]
I am aware of that, and partly agree, but that response falls very close to the "it's only a theoretical problem; there's no way anyone will be able to actually exploit it" argument beloved of some proprietary software companies with terrible security track records.
Bolstered by the old cryptography saw that anyone can invent a cryptosystem which they themselves are not smart enough to crack, I'm not going to claim that just because I can't think of a way to exploit this problem, it cannot be exploited. Attackers can be fiendishly devious. I'd rather err on the side of caution.
Jaunty not even getting security updates. Posted Nov 23, 2010 5:58 UTC (Tue) by error27 (subscriber, #8346) [Link]
Kernel hackers upgrade their kernel a lot. You can't even imagine how enraged they would be if your idea was adopted. :P Also we want people to upgrade their kernels as easily as possible because we need testers.
If you're running a distro kernel then changing the permissions on kallsysms is pointless anyway.
Jaunty not even getting security updates. Posted Nov 22, 2010 13:55 UTC (Mon) by NAR (subscriber, #1313) [Link]
I thought that those who compile and run their own kernels (instead of the distribution-provided kernel) should be able to patch their kernel if it doesn't boot, otherwise they shouldn't run their own kernel...
Jaunty not even getting security updates. Posted Nov 22, 2010 14:07 UTC (Mon) by adobriyan (guest, #30858) [Link]
Compiling and running doesn't involve patching kernel and
certainly doesn't involve debugging kernel. Why A suddenly implies B?
I want just turn off IPv6 and CONFIG_COMPAT,
Jaunty not even getting security updates. Posted Nov 22, 2010 14:27 UTC (Mon) by NAR (subscriber, #1313) [Link]
I was under the impression that this is the philosophy of the 2.6.x kernel development cycle: keep the distribution kernels very close to the mainline, so users will use the kernel from the distribution and only those will compile and run their own kernel who know what they are doing.
P.s.: I'm pretty sure you don't need to recompile your kernel to turn off IPv6.
P.s.2: my point was running a kernel not included in the distribution (which implies a compilation), not the actual compilation step. You can recompile the kernel in Jaunty whatever way you like, it will boot (or at least it won't have problems reading that file).
Jaunty not even getting security updates. Posted Nov 22, 2010 18:55 UTC (Mon) by jrn (subscriber, #64214) [Link]
In general, it is very useful to be able to try a new kernel on old userspace when tracking down kernel bugs. See http://lwn.net/Articles/377953/ for an example (probably not the best one) of when this was broken.
Jaunty not even getting security updates. Posted Nov 22, 2010 21:44 UTC (Mon) by jrn (subscriber, #64214) [Link]
Jaunty not even getting security updates. Posted Nov 25, 2010 17:38 UTC (Thu) by dag- (subscriber, #30207) [Link]
> The rule is that you don't break userspace. It's a very simple rule to understand.
Well, I don't know how general that rule is, because kernel 2.6.36 ripped out an important set of /proc/acpi entries that are still used on older Gnome releases (eg. CentOS-5).
A separate project, named ELRepo, provides backported kernel modules, but also the current mainline kernel built specifically for CentOS-5. Which is great for testing/running the latest kernel with a stable and trusted distribution. Since 2.6.36, not anymore, as my laptop couldn't provide proper ACPI information, and as such couldn't suspend/hibernate before running out of power :-(
More information about this, and other breakage is available from:
Jaunty not even getting security updates. Posted Nov 25, 2010 18:59 UTC (Thu) by corbet (editor, #1) [Link] Have you complained to the ACPI developers and gotten this listed as a regression? That might just get it fixed. (Not that I know anything about this particular issue).
Jaunty not even getting security updates. Posted Nov 25, 2010 19:28 UTC (Thu) by dag- (subscriber, #30207) [Link]
I guess we didn't really consider these to be regressions, nor did we expect kernel developers to consider us, humble users of old but stable distributions ;-) However it would fit our goal for the kernel-ml offering to help upstream as much as possible with issues.
These kernels are not intended for production use, but provided as-is and as a means to help users to find newer drivers that can be backported, or detect regressions with drivers known to work. (Although they can be very useful nevertheless...)
I'll discuss this with the other team-members and see if they agree to report these upstream. Thanks for mentioning, Jon !
Jaunty not even getting security updates. Posted Nov 26, 2010 4:11 UTC (Fri) by promotion-account (guest, #70778) [Link] I guess we didn't really consider these to be regressions, nor did we expect kernel developers to consider us, humble users of old but stable distributions ;-) The kernel community usually take such issues very seriously, please report. If you want maximum effect, CC linus in the process with a subject like '2.6.36' breaks XXXX userspace' ;)
Small correction Posted Nov 25, 2010 19:30 UTC (Thu) by dag- (subscriber, #30207) [Link]
I intended to say that ELRepo packages were built specifically on _RHEL 5_, (but are intended for the various RHEL rebuilds as well). In the case of my laptop, it was using CentOS-5 but in the meantime I moved to RHEL 6 instead...
|
|||||||||||||