| |||||||||||||
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4)Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4)Posted Jan 24, 2012 13:06 UTC (Tue) by nye (guest, #51576)In reply to: Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) by dlang Parent article: Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4)
>this is exactly the disconnect.
> you assume that the person fixing the bug understood the security implications of it, from the comments (and from dealing with many developers over many years), I believe that they usually don't understand the security implications of bugs that they deal with.
You may not agree with PaXTeam, but bringing up this tired strawman is shamefully dishonest.
You know *very well*, as it's repeated *every time this comes up*, that nobody is asking for all security fixes to be flagged as such, but rather for known fixes to known security problems to *not have that information actively removed*.
(Log in to post comments)
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 24, 2012 19:40 UTC (Tue) by raven667 (subscriber, #5198) [Link]
This is probably something that will have to be repeated every time, along with a lot of other points, because every time it comes up there are people who don't understand and haven't been party to the previous discussions. Rather than getting angry with people it might be better to just work on an "elevator pitch" summary of the important arguments that you can cut-n-paste into any discussion for the n00bs 8-).
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 24, 2012 20:08 UTC (Tue) by PaXTeam (subscriber, #24616) [Link]
dlang's not 'n00bs', check https://lwn.net/Articles/461552/ for some history (should ring you a bell too while we're at it ;).
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 24, 2012 20:19 UTC (Tue) by raven667 (subscriber, #5198) [Link]
That's probably just my twitterbrain in action, responding to comments without checking the full history of the thread. You are right, dlang is just trolling in this instance, pretending not to understand. There has to be a better way to move the discussion forward though than escalated mutual trolling.
I hope you are doing well 8-)
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 26, 2012 3:23 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
I did not pretend to not understand PaxTeam's position, my initial post was pointing out that as far as I could tell from the information provided, this was an example of a fix being generated that was not recognized as a security fix at the time it was committed, and as such was not called out to be a security fix.
It sounds as if the security implications were recognized later while the patch was being discussed, but I don't know if it had been merged into the linus tree by that point (if not, then it could have been tagged as a security fix, if it had already been merged than it was too late)
the only reason to worry about if a patch was tagged as a security fix or not is the idea that someone will only apply security fixes, not all fixes. Is that isn't going to be the case, why does it matter if the fix is tagged as security related or not?
as was demonstrated in posts elsewhere, just applying fixes tagged as being security related can end up with a less secure system that not applying any patches. The best thing to do is to upgrade and get all fixes, because you don't know if they are really security related or not.
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 26, 2012 9:05 UTC (Thu) by fuhchee (subscriber, #40059) [Link]
"The best thing to do is to upgrade and get all fixes"
Questionable: I don't want to reboot everything daily (?) just for random fixes and unproven features.
"because you don't know if they are really security related or not."
True: the commit-message non-disclosure policy does its part in ensuring such ignorance.
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 26, 2012 9:21 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
kernel releases don't happen daily, but if you are running a system critical enough, you will be rebooting it frequently, and you won't be waiting for your distro to package the update either, you will have some person (or team) dedicated to finding problems, generating fixes (either by backporting patches or developing new ones), testing them and deploying them.
if you just take patches from the vendor and deploy them to production when the vendor gives them to you, you will not have a stable, secure production system (and it will be worse in many ways if you only apply the 'important' patches out of those that are provided)
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 26, 2012 9:50 UTC (Thu) by fuhchee (subscriber, #40059) [Link]
"... you will have some person (or team) dedicated to finding problems, generating fixes (either by backporting patches or developing new ones), testing them and deploying them"
So this alternative envisions having in-house kernel qa/dev talent.
"if you just take patches from the vendor and deploy them to production ..."
This alternative outsources the qa/dev talent to the vendor.
Neither alternative is simply running upstream kernels. Does anyone except for kernel developers do that?
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 26, 2012 10:22 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
blindly running the latest kernel.org kernel is just outsourcing this to the kernel developers. It doesn't solve things either.
the reality is that you need to do testing of new versions before you run them on your critical systems, no matter where it comes from (internal developers, kernel.org developers, RedHat, Debian, or any other distro)
now the only remaining question is which source to use. All of them try to only introduce good things and fix bugs, but they all miss bugs, and they all introduce new bugs in the process.
I think it's undisputed that the kernel.org developers fix the most bugs.
But it's also undisputed that the kernel.org developers introduce the most new bugs.
It's really going to be up to your organization to decide if they think that running kernel.org kernels that you have tested is best, or if running distro kernels that you have tested is best, or something else.
I've been running kernel.org kernels in production, at a large company (10K+ employees now) for 15 years. There are people who do so with great reliability. I have done more kernel updates with fewer problems than other teams in the company that have been running RedHat kernels (and they have historically been buying servers from 'better' vendors as well)
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 26, 2012 10:41 UTC (Thu) by fuhchee (subscriber, #40059) [Link]
I find I have trouble seeing what all that has to do with the need to know whether particular fixes represent security problems.
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 26, 2012 19:50 UTC (Thu) by raven667 (subscriber, #5198) [Link]
the point is that you don't need to know if you just follow kernel.org, you always get all fixes (and all new bugs)
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 31, 2012 9:16 UTC (Tue) by Klavs (subscriber, #10563) [Link]
If the machine is so important it "can't" be booted - it should be setup in a cluster, as no machines hardware is stable enough to ensure never rebooting.
And as dlang says new kernels releases is not happening every day - and if you like, you can rather easily (if you're a Linux sysadmin) follow mainline kernel instead of your distro's kernel - it's what a lot of us did in the 2.0 and 2.2 (and 2.4 even) days.
Back then - Linux did mark Security fixes as such - but always stated the one should always update anyhow - and clearly many people only up updated the kernel when they saw an actual security flaw mentioned.
I believe this issue would be solved, if only the release notes for the kernel, always stated (at the top) that many of the bugfixes, may well have a security impact as well - and we do not try "in any way" to try to identify if this is the case - so you should always stay updated.
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 31, 2012 16:34 UTC (Tue) by raven667 (subscriber, #5198) [Link]
> I believe this issue would be solved, if only the release notes for the kernel, always stated (at the
> top) that many of the bugfixes, may well have a security impact as well - and we do not try "in any > way" to try to identify if this is the case - so you should always stay updated
I thought that's what they did which as a policy is still causing a kerfluffle. Maybe the solution would be to become much more diligent about marking bugfix and feature updates separately and correctly and fully describing the bugfixes including known security impacts in the change log so that a "stable" kernel won't miss important backports. This is already done to an extent so strengthening that process might fix a lot of the complaints.
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 26, 2012 19:47 UTC (Thu) by raven667 (subscriber, #5198) [Link] It sounds as if the security implications were recognized later while the patch was being discussed, but I don't know if it had been merged into the linus tree by that point (if not, then it could have been tagged as a security fix, if it had already been merged than it was too late) I don't believe this to be true, the initial report was submitted to the security at kernel.org mail address as a local root exploit. The security implications were known from moment one.
|
|||||||||||||