User: Password:
|
|
Subscribe / Log in / New account

Kernel.org's road to recovery

Kernel.org's road to recovery

Posted Oct 13, 2011 8:47 UTC (Thu) by malor (guest, #2973)
In reply to: Kernel.org's road to recovery by Klavs
Parent article: Kernel.org's road to recovery

And vonbrand is saying 'all bugs are security-related'. If that's true, which I do NOT grant, but if it is, then adding known security impacts to a bugfix note is irrelevant, because the bad guys are going to be looking at the code on EVERY patch.

Only good guys read changelogs, basically, so hiding security information only hurts good guys. And it makes the Linux kernel look more secure than it actually is, which is another form of lying by omission.

There is a reason why many many admins try to limit patches to known security-related issues... it's because they're constantly getting new features shoveled at them, with brand-new potential, unanalyzed security impacts. And programmers are very good at introducing weird and subtle regressions with their fixes. Architects and administrators only get shit when stuff breaks, so they try to change as little as possible with a setup, once they know it works. Even tiny tuning adjustments in the kernel code can throw a large-scale application out of kilter, so the people in charge of actually putting all that abstract code to real work in the world try to avoid running new code in a given application unless they either have to, or need new features.

The harder the programmers make it on the architects and administrators, the more appealing the BSDs, Solaris, and even Windows look. And hiding security impacts makes it much harder for them to do their jobs. Programmers just wave their hands and say "You should just run all the code we give you, no matter what", but they don't lose their jobs when the cluster dies.


(Log in to post comments)

Kernel.org's road to recovery

Posted Oct 13, 2011 17:33 UTC (Thu) by dlang (subscriber, #313) [Link]

and since the security impact of the patches is usually not known at the time the commit is written, if people only apply patches that say "this is a security patch" in the commit, they will skip installing a lot of security related fixes.

This can lead to worse security than not making such comments in the commit message.

In my opinion, this is a far bigger reason to not put such comments in the commit message than worries about bad guys reading them

Kernel.org's road to recovery

Posted Oct 13, 2011 20:20 UTC (Thu) by raven667 (subscriber, #5198) [Link]

This is probably something that reasonable people can disagree on, whether it is better to be protected against _some_ attacks but have a system which runs stably or be protected against _more_ attacks (but not all, the kernel developers do not claim perfection but instead the opposite) and suffer stability issues due to unrelated changes.

Kernel.org's road to recovery

Posted Oct 15, 2011 16:40 UTC (Sat) by PaXTeam (guest, #24616) [Link]

> if people only apply patches that say "this is a security patch" in the
> commit, they will skip installing a lot of security related fixes.

if security fixes are marked as such then how can they be missing 'security related fixes'?

> This can lead to worse security than not making such comments in the commit message.

how does fixing a security bug *decrease* security?

Kernel.org's road to recovery

Posted Oct 15, 2011 21:19 UTC (Sat) by dlang (subscriber, #313) [Link]

not all patches that have security implications are known at the time they are created

so if you only install fixes that were tagged as security fixes, you will miss other fixes that have security implications because those implications were not known at the time they were written, and so they were not tagged.

it's not that fixing a security bug decreases security. what decreases security is the attitude that if it's not tagged as being a security fix, then it doesn't have security implications.

tagged as a security fix guarantees security implications

not tagged as a security fix does not guarantee that there are no security implications.

And if even you are making the mistake that tagging known security fixes means that other fixes don't need to be applied (on the basis that they don't have security implications), then you have just proven the case that many of the kernel developers are trying to make, that tagging some patches as security related will cause people to ignore the others and have less security than updating to a newer version with all of the fixes

Kernel.org's road to recovery

Posted Oct 16, 2011 6:35 UTC (Sun) by malor (guest, #2973) [Link]

But less stability, because patches have an annoying habit of introducing both regressions and new, unwanted features, which can themselves, of course, have all kinds of nasty security implications.

you have just proven the case that many of the kernel developers are trying to make, that tagging some patches as security related will cause people to ignore the others and have less security than updating to a newer version with all of the fixes

That's up to them to decide. The guys running these huge, complex systems are pretty goddamn good at what they're doing, and you guys are forcing new, untested code down their throats.

Let people have their own agency, and make their own decisions. Don't try to force them to do things the way YOU think they should, sitting there coding on your laptop. Let the guys (and gals) standing in those roaring data centers full of thousands of machines make those calls for themselves.

Just be honest, and things will come out better for the people who choose to use your code. If you are not expert in large-scale systems management, you shouldn't try to substitute your judgement for those who are.

Kernel.org's road to recovery

Posted Oct 16, 2011 21:37 UTC (Sun) by PaXTeam (guest, #24616) [Link]

> not all patches that have security implications are known at the time they are created

so far so good.

> so if you only install fixes that were tagged as security fixes, you
> will miss other fixes that have security implications because those
> implications were not known at the time they were written, and so they
> were not tagged.

now, following this logic, noone will ever be able to apply all security fixes since the security impact of a given commit may reveal itself any time in the distant future. therefore everyone who applies anything (tagged or not) is in a constant state of 'not tagged as being a security fix, then it doesn't have security implications'. IOW, i don't see the usefulness of your statement, it looks like a tautology.

> what decreases security is the attitude that if it's not tagged as being
> a security fix, then it doesn't have security implications.

why does it decrease security?

and since you've just established that everyone can only do selective backporting, regardless of commits being tagged with whatever or not, this attitude is seemingly prevalent, even you suffer it yourself, so why does it matter again?

> And if even you are making the mistake that tagging known security fixes
> means that other fixes don't need to be applied (on the basis that they
> don't have security implications),

actually, i don't make that mistake, in fact, i don't see it as a mistake and you have yet to explain *why* it is a mistake at all. for a start, your acknowledging that fixing a security bug doesn't decrease security means that you're already in contradiction.

> then you have just proven the case that many of the kernel developers
> are trying to make, that tagging some patches as security related will
> cause people to ignore the others and have less security than updating
> to a newer version with all of the fixes

this one bleeds from several wounds, i'm afraid:

1. you haven't shown evidence that people are actually ignoring anything else but explicitly marked security fixes (i think i asked this one before ;).

2. you haven't shown evidence that ignoring anything but explicitly marked security fixes is a bad thing (you actually acknowledged that it's not, now what ;).

3. you haven't explained what 'all of the fixes' means. you and others already said that *everything* not proven otherwise is a security fix therefore the same everything must be backported by everyone who cares which in practice is possible only by following linus's git HEAD. i bet even you don't dare to do that to your company's servers (i actually wonder what you do given that you don't use -stable either).

4. you haven't shown evidence that *not* ignoring (i.e., backporting) random unmarked paches increases one's security/etc. you see, all those security and other fixes are the result of some *earlier* change that *introduced* the problem, so you'd have to somehow prove that the net result of backporting everything under the sun (i.e., following git HEAD) is positive, not negative.

Kernel.org's road to recovery

Posted Oct 17, 2011 1:09 UTC (Mon) by raven667 (subscriber, #5198) [Link]

3. you haven't explained what 'all of the fixes' means. you and others already said that *everything* not proven otherwise is a security fix therefore the same everything must be backported by everyone who cares which in practice is possible only by following linus's git HEAD. i bet even you don't dare to do that to your company's servers (i actually wonder what you do given that you don't use -stable either).

I don't know if you pay attention to kernel development but from my understanding running the latest Linus kernel release is what is recommended to have all the fixes. I'm sure there are some people who _do_ run raw Linus kernels who want the latest fixes as soon as they are out of the oven. The current Linus kernel certainly has more security relevant fixes than any vendor kernel which only has backports as the very nature of cherry picking backports is going to miss security fixes which aren't known at the time the fix is made. That is what the kernel release announcements recommend.

Many people think running the latest kernel.org release is potentially too disruptive due to other changes unrelated to bug and security fix work. Unfortunately trying to separate feature from fix work didn't work as a process from the kernel developers perspective which is why the development process was changed in the transition from 2.4 to 2.6 so that feature and architectural changes are fed right into the main line of development.

I think that the major vendors (RedHat, Debian, SuSE, various embedded, etc.) should continuously re-evaluate how close they can run to the main line of kernel.org kernels rather than trying to cherry pick backports and maintain their own "stable" forks. Ideally the regular kernel releases would be equivalent in stability and superior in security than the current situation.

Kernel.org's road to recovery

Posted Oct 17, 2011 6:53 UTC (Mon) by malor (guest, #2973) [Link]

Unfortunately trying to separate feature from fix work didn't work as a process from the kernel developers perspective

And that, right there, is the single core problem with Linux security.

Security is hard. It means more pain during development. Separating fixes and features is a pain in the ass. But if it doesn't get done, you end up in the snarl they're in now.

Even the developers themselves can't provide secure shared access to a single Linux kernel image. How can anyone else expect to?

Kernel.org's road to recovery

Posted Oct 17, 2011 7:28 UTC (Mon) by dlang (subscriber, #313) [Link]

the problem is that one person's 'bugfix' is another person's 'new feature'

especially when the bugfix can end up refactoring the code in the process.

yes, this is a big problem with Linux, but the rate of fixes (of all kinds) is the great strength of Linux. At this point nobody knows how to fix the weakness without giving up the strength. There are other OS groups (openBSD comes to mind) that seem like they follow the philosophy that you are advocating, but despite the fact that they had several years of a head start on Linux, their development models have caused them to be far less useful on current hardware. (and therefor any security benefits they may provide, far less useful)

I don't understand your comment about the kernel developers being unable to provide shared access to a single kernel image.

are you referring to the fact that there was a privilege escalation vulnerability on kernel.org? if so, any conclusions about what the problem was need to wait until we learn what happened. And in any case, the vast majority of the kernel developers were not involved in administering the systems (and note that it was several systems, not a single system)

Kernel.org's road to recovery

Posted Oct 13, 2011 18:32 UTC (Thu) by raven667 (subscriber, #5198) [Link]

And it makes the Linux kernel look more secure than it actually is, which is another form of lying by omission.

I just have to respond to this one thing. The kernel announcements and general discussions have been pretty open about the belief that it is _less_ secure than many people would like. Just the other day in a discussion about containers and namespaces, major kernel developers comment was that it wasn't worth the effort to increase security separation between containers because there will always be local root exploits that will break separation.

The kernel developers do not appear to be trying to claim more security by omission, they are explicitly claiming less.

Kernel.org's road to recovery

Posted Oct 14, 2011 1:29 UTC (Fri) by malor (guest, #2973) [Link]

major kernel developers comment was that it wasn't worth the effort to increase security separation between containers because there will always be local root exploits that will break separation.

Well, that's good in the sense that they're admitting there's a big problem. But I would argue that if they can't keep user accounts secure from gaining root access, then there's really not much point to even HAVING user accounts. If your summary is accurate, there's no way you can safely use Linux to share access between potentially hostile accounts on one kernel. You can sorta do it through virtualization, but running an entire kernel per user is a hell of a lot of overhead to carry around.

Security is probably the hardest problem in computing, and if they are indeed saying "there will always be root exploits", it sounds like they're giving up on the idea entirely. They want to make it go fast, and security be damned.

This is something that people need to be very aware of; that wording makes it sound like they're throwing in the towel. If so, Linux is no longer appropriate for many use cases, particularly when lives are at risk.

Kernel.org's road to recovery

Posted Oct 14, 2011 3:10 UTC (Fri) by dlang (subscriber, #313) [Link]

they are working to fix any problems they find as fast as they can.

the kernel developers are not giving up.

there was one person who made the claim in the discussion on containers that containers were not good enough, but on the other hand, I'm one of the people who says that virtualisation isn't good enough isolation for some applications due to possible bugs in the hypervisor. It all depends on how much security you are going for.

This is part of the reason that SELinux is optional.

Kernel.org's road to recovery

Posted Oct 14, 2011 7:14 UTC (Fri) by anselm (subscriber, #2796) [Link]

Security is probably the hardest problem in computing, and if they are indeed saying "there will always be root exploits", it sounds like they're giving up on the idea entirely.

Not necessarily. Maybe they're just being realistic while they're trying to fix problems as they are discovered (and prevent them where they can).

With a program of the size and complexity of the Linux kernel, I would be very sceptical of anybody claiming the logical opposite, namely that »there will never be even a single root exploit«. Not even the OpenBSD folks subscribe to that kind of hubris ;^)


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds