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

KS2010: Security

KS2010: Security

Posted Nov 5, 2010 12:24 UTC (Fri) by spender (subscriber, #23067)
In reply to: KS2010: Security by mingo
Parent article: KS2010: Security

I think you're horribly confused if you feel that upstream's security is somehow a responsibility of mine.

Let me make this clear: upstream collectively doesn't even have the common sense to acknowledge the existence of security bugs. The 'security circus' is a nice red herring to divert the blame for why Linux security is so atrocious. Maybe seven years ago you could complain about the one or two companies that embargoed vulns to make a name for themselves, but even then it would have been a poor excuse (again that anyone but upstream itself is somehow responsible for upstream's security). I hate to tell you, but those companies are long gone, and there's now nobody in the industry embargoing bugs for fame or anything else you attribute to this 'security circus.' Only notable exception being ITL with the stack/heap gap issue, though you were already notified about that in a 2005 presentation and did nothing about it; so sorry, you lose the ability to complain. That neither Linus nor anyone else has noticed this just illustrates how out of touch with the real world you all are. All you have now is people *volunteering* to try to fix things, and upstream acting like a bunch of idiots. Do you want a medal or something because upstream accepts submitted patches for trivial vulnerabilities found by volunteers? That's hardly a measure of success.

Complain about the 'security circus' all you want, this mythical boogieman that somehow magically prevents you from making any security improvements of your own, but until upstream takes a serious approach to security, I'm afraid the joke is on you. Distros taking a month to release updated kernels for vulnerabilities that only require reusing some of my enlightenment code to exploit is ridiculous. Time and again you have vulnerabilities capable of weaponized public exploits on day one; how many more years will it take for upstream to realize this is a serious problem worthy of actual attention?

Until then, keep up your "de-pessimizing" strategy to security: https://patchwork.kernel.org/patch/276921/

BTW, if I wanted to check for the existence of parasitic security poseurs, I'd probably look for more posts from this guy: http://lkml.org/lkml/2010/11/4/335

-Brad


(Log in to post comments)

KS2010: Security

Posted Nov 5, 2010 13:59 UTC (Fri) by Lionel_Debroux (subscriber, #30014) [Link]

* On the one hand, to the taste of a number of security researchers (represented here by one member both significant and vocal ;-) ), mainline (Linus' tree) isn't doing enough for security. On the other hand, to the taste of top kernel devs (represented by at least another significant member here), the grsecurity folks aren't doing much to reduce the gap between mainline and grsecurity. And the status quo is not good for users.

* It's sad that several hundreds low-controversy one-/few-liners from the huge grsecurity patch, which can be imported to mainline more easily than lots of other patches, without demonstrable performance or size penalty, remains developed outside of mainline.
Dan Rosenberg gets dozens of small patches, mostly fixes for information leaks, committed in mainline and backported to stable. So mainline does pay at least _some_ attention to security, and does prefer smaller patches, too.

* Brad says that new non-const struct instances are added all the time to mainline. And this is despite checkpatch.pl, which is supposed to be applied by authors before submitting patches, checking more than 30 _ops types for constness. But again, mainline certainly isn't against one-liner-per-type improvements to checkpatch.pl ;-)
And, in case somebody forgets to use checkpatch.pl (we programmers are just humans !), is there a gateway that passes each commit that enters mainline through checkpatch.pl ? Or a gateway integrated with the linux-next infrastructure, so that patches other than staging get hopefully fixed in the individual trees before they enter mainline ?

* The RO/NX patch for modules, one of the most recent incarnations of which seems to be http://lwn.net/Articles/372256/ / http://thread.gmane.org/gmane.linux.kernel.lsm/10347 , seems to have vanished: in the discussion thread, Kees Cook posts that he cannot find the patch in any tree he looked at... but there's a tip-bot notice for that patch ?

* Multiple patchsets (e.g. -mmotm and -ck) are provided, between other formats, as broken-out series, for easier consumption and review. I've looked for a broken-out series corresponding to grsecurity, but I haven't been able to find it. I haven't found the scripts for regenerating e.g. the _ops constification either - it's not that it's really hard to re-create them, but it's stupid to duplicate such work. Do I fail at reading Web pages or using a search engine ?

KS2010: Security

Posted Nov 5, 2010 15:07 UTC (Fri) by spender (subscriber, #23067) [Link]

> * On the one hand, to the taste of a number of security researchers (represented here by one member both significant and vocal ;-) ), mainline (Linus' tree) isn't doing enough for security. On the other hand, to the taste of top kernel devs (represented by at least another significant member here), the grsecurity folks aren't doing much to reduce the gap between mainline and grsecurity. And the status quo is not good for users.

Indeed, the status quo is not good for users. But I don't see how that is the problem of anyone but upstream. I only feel a responsibility toward my own users. Upstream is a lost cause for security, as far as I'm concerned. It's a waste of my time to deal with them and their narrow-minded view of security. If in the future they grow up and deal with security properly, then we'll re-evaluate working with them. As it stands, they continue to have the mentality that security just involves fixing bugs (which fits with the 'a bug is a bug' tautological stupidity).

And as I said earlier, when you go looking for "successes," it's mostly just them accepting trivial one-line patches for security issues found en masse via grep. What happens is quite different when a patch doesn't accompany the vulnerability report. So I reject this entire business of "the grsecurity folks aren't doing much to reduce the gap between mainline and grsecurity" -- it's not our job or what we want to be spending our time on.

> * It's sad that several hundreds low-controversy one-/few-liners from the huge grsecurity patch, which can be imported to mainline more easily than lots of other patches, without demonstrable performance or size penalty, remains developed outside of mainline.
> Dan Rosenberg gets dozens of small patches, mostly fixes for information leaks, committed in mainline and backported to stable. So mainline does pay at least _some_ attention to security, and does prefer smaller patches, too.

They prefer smaller patches, except when they don't. Look at the const patchset. First it wasn't split up enough, they complained, then somehow even though it was split up exactly as they asked, they complained that it was now split up too much. Sorry, but I view it as a failure of Linux if security improvements are dependent upon benevolent individuals with unlimited amounts of time to waste and an iron will.

-Brad

KS2010: Security

Posted Nov 5, 2010 15:16 UTC (Fri) by dlang (subscriber, #313) [Link]

thank you for the clear statement.

if you don't feel and responsibility for anyone but your users and have no intent to try and push the fixes upstream,then your tree just became pretty irrelavent to linux security for anyone except for your users.

some people may choose to try and parse things apart to get them upstream, but very few people will want to try, so the security fixes that get into the kernel will be developed independantly (even though you will make a lot of noise each time someone recreates your work)

if you don't care about normal linux users, only your users, please quiet down about upstreams's policies, you've just said you don't care about anyone that uses it, so why should you care about it's policies?

KS2010: Security

Posted Nov 5, 2010 15:35 UTC (Fri) by spender (subscriber, #23067) [Link]

Because upstream's policies affect me and my users? I don't really need to explain the hierarchy and why "upstream" is called "upstream", do I?

-Brad

KS2010: Security

Posted Nov 5, 2010 15:55 UTC (Fri) by PaXTeam (guest, #24616) [Link]

> if you don't feel and responsibility for anyone but your users [...]

so first it's our fault that our code isn't accepted in vanilla for whatever reasons then it's also our fault that we still dare to make it available for anyone who cares. and to crown the absurdity, we're at fault for caring about these people. man, are you sure you have anything to do with security? i'm seriously worried about *your* users.

> [...]and have no intent to try and push the fixes upstream

maybe you're not a native speaker, but if you re-read spender's post carefully, you'll note that he made the cooperation conditional. it's the sentence that starts with the 'if' word, i'm sure you'll be able to find all one instance of it.

> [...]then your tree just became pretty irrelavent to linux security for anyone except for your users.

wait, are you saying grsec *was* relevant up to this very moment in time for anyone but grsec users? wow, i take it you won't elaborate but i smell magic here.

> even though you will make a lot of noise each time someone recreates your work

only if they 'forget' to credit the people for the ideas and/or the code or if they fuck up the implementation. just ask ingo ;).

KS2010: Security

Posted Nov 5, 2010 16:25 UTC (Fri) by PaXTeam (guest, #24616) [Link]

> I haven't found the scripts for regenerating e.g. the _ops constification either - it's not that it's really hard to re-create them, but it's stupid to duplicate such work.

it's more work than you think, just talk to Emese about it. afaik, she still has the cocci scripts that she used for the initial patch series then she had to manually fix up things here and there (i.e., there's no substitute for a make allmodconfig ;). the current const patches are about 230k but they only represent a small fraction of 200 or so ops structures that could probably be all constified. good luck getting that work done!

KS2010: Security

Posted Nov 6, 2010 9:52 UTC (Sat) by Lionel_Debroux (subscriber, #30014) [Link]

Ah, I don't know why I somehow thought the constification was made using the "simple/ugly" script mentioned by Brad in http://lwn.net/Articles/346299/ . It's all good if the patches are created with Coccinelle.
Thanks for the clarification :)

I haven't seen any reply about the broken-out form, if any, of the large grsecurity patch ?

KS2010: Security

Posted Nov 6, 2010 11:19 UTC (Sat) by PaXTeam (guest, #24616) [Link]

> Ah, I don't know why I somehow thought the constification was made using the "simple/ugly" script mentioned by Brad

multiple people worked on this over time with different methods and eventually there was some evolution in that coccinelle proved smarter than grep/sed ;). note that it's still not all roses as according to Emese coccinelle has (or used to have, i'm not following this nowadays) some limitation in how it parsed include files (no recursion was the big problem, iirc) so when you do not only want to generate patches for specific structures but also want coccinelle to determine which ones could be constified at all automatically, then you'll have some extra work to do (or find/write another tool). and you'll want this level of automated help as checking every usage of those 200 ops structure types by hand is anything but fun (and no, compiling allyesconfig/allmodfconfig doesn't necessarily give you 100% coverage).

> I haven't seen any reply about the broken-out form, if any, of the large grsecurity patch ?

because there's no such thing, at most the const patches exist standalone but not the rest.


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