A New Mindcraft Moment
Posted Nov 6, 2015 20:50 UTC (Fri) by PaXTeam (guest, #24616) [Link]
1. this WP article was the fifth in a series of articles following the security of the internet from its beginnings to relevant matters of as we speak. discussing the security of linux (or lack thereof) matches properly in there. it was also a nicely-researched article with over two months of research and interviews, one thing you cannot fairly claim yourself to your recent pieces on the topic. you do not just like the facts? then say so. and even higher, do something constructive about them like Kees and others have been trying. however silly comparisons to outdated crap just like the Mindcraft studies and fueling conspiracies don't exactly help your case. 2. "We do a reasonable job of discovering and fixing bugs." let's begin right here. is that this assertion primarily based on wishful pondering or cold onerous details you are going to share in your response? according to Kees, the lifetime of security bugs is measured in years. that's greater than the lifetime of many devices individuals buy and use and ditch in that interval. 3. "Issues, whether they are safety-associated or not, are patched shortly," some are, some aren't: let's not neglect the latest NMI fixes that took over 2 months to trickle all the way down to stable kernels and we also have a person who has been waiting for over 2 weeks now: http://thread.gmane.org/gmane.comp.file-systems.btrfs/49500 (FYI, the overflow plugin is the first one Kees is making an attempt to upstream, think about the shitstorm if bugreports will likely be treated with this perspective, let's hope btrfs guys are an exception, not the rule). anyway, two examples will not be statistics, so as soon as once more, do you may have numbers or is all of it wishful pondering? (it's partly a trick question as a result of you may even have to elucidate how something will get to be determined to be safety associated which as we all know is a messy business in the linux world) 4. "and the stable-update mechanism makes those patches out there to kernel customers." besides when it doesn't. and sure, i have numbers: grsec carries 200+ backported patches in our 3.14 stable tree. 5. "Particularly, the few builders who are working in this space have never made a critical attempt to get that work built-in upstream." you don't should be shy about naming us, in any case you did so elsewhere already. and we additionally defined the the reason why we haven't pursued upstreaming our code: https://lwn.web/Articles/538600/ . since i do not anticipate you and your readers to learn any of it, here's the tl;dr: in order for you us to spend hundreds of hours of our time to upstream our code, you'll have to pay for it. no ifs no buts, that is how the world works, that is how >90% of linux code gets in too. i personally discover it pretty hypocritic that properly paid kernel builders are bitching about our unwillingness and inability to serve them our code on a silver platter at no cost. and earlier than someone brings up the CII, go verify their mail archives, after some preliminary exploratory discussions i explicitly requested them about supporting this long drawn out upstreaming work and acquired no solutions.
Posted Nov 6, 2015 21:39 UTC (Fri) by patrick_g (subscriber, #44470) [Link]
Cash (aha) quote : > I suggest you spend none of your free time on this. Zero. I propose you receives a commission to do that. And effectively. No one count on you to serve your code on a silver platter free of charge. The Linux basis and big firms using Linux (Google, Purple Hat, Oracle, Samsung, and many others.) should pay security specialists such as you to upstream your patchs.
Posted Nov 6, 2015 21:57 UTC (Fri) by nirbheek (subscriber, #54111) [Hyperlink]
I would simply like to level out that the way in which you phrased this makes your comment a tone argument[1][2]; you have (probably unintentionally) dismissed the entire father or mother's arguments by pointing at its presentation. The tone of PAXTeam's comment displays the frustration constructed up over the years with the way issues work which I feel needs to be taken at face worth, empathized with, and understood relatively than simply dismissed. 1. http://rationalwiki.org/wiki/Tone_argument 2. http://geekfeminism.wikia.com/wiki/Tone_argument Cheers,
Posted Nov 7, 2015 0:55 UTC (Sat) by josh (subscriber, #17465) [Link]
Posted Nov 7, 2015 1:21 UTC (Sat) by PaXTeam (visitor, #24616) [Hyperlink]
why, is upstream known for its basic civility and decency? have you ever even read the WP submit beneath dialogue, by no means thoughts past lkml visitors?
Posted Nov 7, 2015 5:37 UTC (Sat) by josh (subscriber, #17465) [Hyperlink]
Posted Nov 7, 2015 5:34 UTC (Sat) by gmatht (guest, #58961) [Link]
No Argument
Posted Nov 7, 2015 6:09 UTC (Sat) by josh (subscriber, #17465) [Hyperlink]
Please don't; it does not belong there both, and it particularly does not want a cheering section as the tech press (LWN typically excepted) tends to provide.
Posted Nov 8, 2015 8:36 UTC (Solar) by gmatht (visitor, #58961) [Link]
Okay, however I was thinking of Linus Torvalds
Posted Nov 8, 2015 16:Eleven UTC (Sun) by pbonzini (subscriber, #60935) [Link]
Posted Nov 6, 2015 22:43 UTC (Fri) by PaXTeam (guest, #24616) [Hyperlink]
Posted Nov 6, 2015 23:00 UTC (Fri) by pr1268 (subscriber, #24648) [Hyperlink]
Why should you assume solely money will fix this problem? Yes, I agree extra sources needs to be spent on fixing Linux kernel safety issues, however do not assume somebody giving a company (ahem, PAXTeam) money is the only resolution. (Not imply to impugn PAXTeam's security efforts.)
The Linux growth neighborhood may have had the wool pulled over its collective eyes with respect to security points (both actual or perceived), however simply throwing cash at the problem will not fix this.
And yes, I do realize the commercial Linux distros do heaps (most?) of the kernel improvement lately, and that implies oblique financial transactions, but it's much more concerned than simply that.
Posted Nov 7, 2015 0:36 UTC (Sat) by PaXTeam (guest, #24616) [Hyperlink]
Posted Nov 7, 2015 7:34 UTC (Sat) by nix (subscriber, #2304) [Link]
Posted Nov 7, 2015 9:49 UTC (Sat) by PaXTeam (visitor, #24616) [Link]
Posted Nov 6, 2015 23:Thirteen UTC (Fri) by dowdle (subscriber, #659) [Link]
I feel you definitely agree with the gist of Jon's argument... not sufficient focus has been given to security within the Linux kernel... the article will get that part proper... cash hasn't been going in direction of security... and now it needs to. Aren't you glad?
Posted Nov 7, 2015 1:37 UTC (Sat) by PaXTeam (visitor, #24616) [Link]
they talked to spender, not me personally, but sure, this facet of the coin is nicely represented by us and others who have been interviewed. the same method Linus is an effective consultant of, effectively, his personal pet challenge referred to as linux. > And if Jon had solely talked to you, his would have been too. given that i'm the author of PaX (part of grsec) yes, talking to me about grsec issues makes it among the best ways to research it. but if you realize of another person, be my visitor and name them, i am fairly certain the not too long ago formed kernel self-safety folks would be dying to interact them (or not, i do not think there's a sucker on the market with thousands of hours of free time on their hand). > [...]it also contained fairly just a few of groan-worthy statements. nothing is ideal however contemplating the viewers of the WP, that is considered one of the higher journalistic pieces on the topic, no matter how you and others do not like the sorry state of linux security uncovered in there. in order for you to discuss extra technical details, nothing stops you from speaking to us ;). talking of your complaints about journalistic qualities, since a earlier LWN article saw it match to include a number of typical dismissive claims by Linus about the standard of unspecified grsec features with no evidence of what expertise he had with the code and how recent it was, how come we didn't see you or anyone else complaining about the quality of that article? > Aren't you glad? no, or not yet anyway. i've heard lots of empty phrases through the years and nothing ever manifested or worse, all the money has gone to the pointless exercise of fixing individual bugs and related circus (that Linus rightfully despises FWIW).
Posted Nov 7, 2015 0:18 UTC (Sat) by bojan (subscriber, #14302) [Link]
Posted Nov 8, 2015 13:06 UTC (Sun) by k3ninho (subscriber, #50375) [Link]
Right now we've obtained builders from huge names saying that doing all that the Linux ecosystem does *safely* is an itch that they have. Unfortunately, the surrounding cultural attitude of builders is to hit practical goals, and sometimes performance objectives. Safety goals are sometimes missed. Ideally, the culture would shift so that we make it tough to comply with insecure habits, patterns or paradigms -- that may be a process that can take a sustained effort, not merely the upstreaming of patches. Regardless of the culture, these patches will go upstream eventually anyway as a result of the ideas that they embody are actually well timed. I can see a option to make it occur: Linus will settle for them when a giant finish-user (say, Intel, Google, Facebook or Amazon) delivers stuff with notes like 'here is a set of enhancements, we're already using them to solve this kind of problem, here is how all the pieces will remain working because $proof, word fastidiously that you're staring down the barrels of a fork because your tree is now evolutionarily disadvantaged'. It is a game and will be gamed; I would favor that the community shepherds users to comply with the sample of declaring drawback + resolution + practical take a look at proof + performance check evidence + safety check proof. K3n.
Posted Nov 9, 2015 6:49 UTC (Mon) by jospoortvliet (guest, #33164) [Hyperlink]
And about that fork barrel: I might argue it is the other way around. Google forked and misplaced already.
Posted Nov 12, 2015 6:25 UTC (Thu) by Garak (guest, #99377) [Link]
Posted Nov 23, 2015 6:33 UTC (Mon) by jospoortvliet (guest, #33164) [Hyperlink]
Posted Nov 7, 2015 3:20 UTC (Sat) by corbet (editor, #1) [Hyperlink]
So I have to confess to a specific amount of confusion. I might swear that the article I wrote said precisely that, but you've put a fair amount of effort into flaming it...?
Posted Nov 8, 2015 1:34 UTC (Sun) by PaXTeam (visitor, #24616) [Hyperlink]
Posted Nov 6, 2015 22:Fifty two UTC (Fri) by flussence (subscriber, #85566) [Link]
I personally assume you and Nick Krause share reverse sides of the same coin. Programming capacity and primary civility.
Posted Nov 6, 2015 22:Fifty nine UTC (Fri) by dowdle (subscriber, #659) [Link]
Posted Nov 7, 2015 0:Sixteen UTC (Sat) by rahvin (guest, #16953) [Link]
I hope I'm mistaken, but a hostile angle isn't going to assist anyone receives a commission. It's a time like this where one thing you appear to be an "knowledgeable" at and there's a demand for that expertise where you show cooperation and willingness to participate as a result of it is an opportunity. I'm comparatively shocked that somebody would not get that, however I'm older and have seen just a few of these opportunities in my career and exploited the hell out of them. You only get a few of these in the typical profession, and handful at the most. Generally you must put money into proving your expertise, and this is a type of moments. It appears the Kernel group could finally take this security lesson to heart and embrace it, as mentioned in the article as a "mindcraft second". This is a chance for developers which will wish to work on Linux security. Some will exploit the chance and others will thumb their noses at it. In the end those builders that exploit the chance will prosper from it. I really feel outdated even having to write that.
Posted Nov 7, 2015 1:00 UTC (Sat) by josh (subscriber, #17465) [Hyperlink]
Perhaps there's a hen and egg downside here, but when looking for out and funding individuals to get code upstream, it helps to pick out people and teams with a history of having the ability to get code upstream. It's completely cheap to desire figuring out of tree, offering the flexibility to develop impressive and demanding safety advances unconstrained by upstream necessities. That is work somebody may also wish to fund, if that meets their needs.
Posted Nov 7, 2015 1:28 UTC (Sat) by PaXTeam (visitor, #24616) [Hyperlink]
Posted Nov 7, 2015 19:12 UTC (Sat) by jejb (subscriber, #6654) [Hyperlink]
You make this argument (implying you do research and Josh doesn't) after which fail to support it by any cite. It can be rather more convincing in case you give up on the Onus probandi rhetorical fallacy and really cite facts. > living proof, it was *them* who prompt that they would not fund out-of-tree work but would consider funding upstreaming work, besides when pressed for the small print, all i obtained was silence. For those following along at dwelling, this is the related set of threads: http://lists.coreinfrastructure.org/pipermail/cii-discuss... A quick precis is that they informed you your undertaking was unhealthy as a result of the code was never going upstream. You told them it was due to kernel developers perspective so they need to fund you anyway. They instructed you to submit a grant proposal, you whined extra concerning the kernel attitudes and finally even your apologist instructed you that submitting a proposal is likely to be the best thing to do. At that point you went silent, not vice versa as you indicate above. > obviously i will not spend time to write down up a begging proposal simply to be informed that 'no sorry, we do not fund multi-yr projects in any respect'. that's one thing that one ought to be instructed upfront (or heck, be a part of some public rules in order that others will know the foundations too). You seem to have a fatally flawed grasp of how public funding works. If you don't inform folks why you need the money and the way you may spend it, they're unlikely to disburse. Saying I'm sensible and I know the problem now hand over the money does not even work for many Academics who've a stable status in the sphere; which is why most of them spend >30% of their time writing grant proposals. > as for getting code upstream, how about you check the kernel git logs (minus the stuff that was not correctly credited)? jejb@jarvis> git log|grep -i 'Author: pax.*group'|wc -l 1 Stellar, I need to say. And earlier than you gentle off on these who have misappropriated your credit score, please do not forget that getting code upstream on behalf of reluctant or incapable actors is a hugely worthwhile and time consuming talent and certainly one of the explanations teams like Linaro exist and are well funded. If more of your stuff does go upstream, it is going to be because of the not inconsiderable efforts of other people in this area. You now have a business mannequin selling non-upstream security patches to customers. There's nothing incorrect with that, it is a fairly normal first stage business model, but it does relatively depend on patches not being upstream in the primary place, calling into question the earnestness of your attempt to place them there. Now this is some free recommendation in my field, which is helping corporations align their businesses in open supply: The selling out of tree patch route is all the time an eventual failure, significantly with the kernel, as a result of if the functionality is that helpful, it gets upstreamed or reinvented in your regardless of, leaving you with nothing to sell. If your marketing strategy B is selling experience, you've got to keep in mind that it will be a hard sell when you have no out of tree differentiator left and git historical past denies that you had anything to do with the in-tree patches. In truth "loopy safety person" will change into a self fulfilling prophecy. The recommendation? it was apparent to everybody else who learn this, however for you, it is do the upstreaming yourself earlier than it gets finished for you. That approach you have got a respectable historical declare to Plan B and you would possibly also have a Plan A selling a rollup of upstream track patches built-in and delivered earlier than the distributions get around to it. Even your utility to the CII couldn't be dismissed as a result of your work wasn't going wherever. Your various is to continue enjoying the function of Cassandra and doubtless undergo her eventual destiny.
Posted Nov 7, 2015 23:20 UTC (Sat) by PaXTeam (guest, #24616) [Link]
> Second, for the potentially viable items this would be a multi-12 months > full time job. Is the CII willing to fund tasks at that degree? If not > all of us would end up with lots of unfinished and partially broken features. please present me the answer to that question. with out a definitive 'yes' there isn't any level in submitting a proposal because that is the time-frame that in my view the job will take and any proposal with that requirement could be shot down instantly and be a waste of my time. and that i stand by my declare that such easy basic necessities needs to be public info. > Stellar, I have to say. "Lies, damned lies, and statistics". you understand there's a couple of strategy to get code into the kernel? how about you employ your git-fu to find all of the bugreports/instructed fixes that went in resulting from us? as for particularly me, Greg explicitly banned me from future contributions via af45f32d25cc1 so it's no marvel i don't ship patches immediately in (and that one commit you discovered that went in regardless of said ban is actually a very unhealthy instance as a result of it is also the one which Linus censored for no good reason and made me decide to never send safety fixes upstream till that practice adjustments). > You now have a business model promoting non-upstream safety patches to prospects. now? we've had paid sponsorship for our various stable kernel series for 7 years. i would not call it a enterprise mannequin although as it hasn't paid anyone's payments. > [...]calling into question the earnestness of your attempt to place them there. i have to be lacking one thing right here however what attempt? i've by no means in my life tried to submit PaX upstream (for all the reasons mentioned already). the CII mails were exploratory to see how critical that complete organization is about really securing core infrastructure. in a sense i've obtained my answers, there's nothing more to the story. as in your free recommendation, let me reciprocate: complex problems don't remedy themselves. code solving complicated issues does not write itself. folks writing code solving complex problems are few and much between that you will see out in brief order. such people (area specialists) don't work for free with few exceptions like ourselves. biting the hand that feeds you'll only end you up in starvation. PS: since you are so certain about kernel builders' capacity to reimplement our code, perhaps have a look at what parallel features i nonetheless maintain in PaX regardless of vanilla having a 'completely-not-reinvented-right here' implementation and check out to understand the explanation. or just take a look at all of the CVEs that affected say vanilla's ASLR but didn't have an effect on mine. PPS: Cassandra never wrote code, i do. criticizing the sorry state of kernel security is a side challenge when i'm bored or just ready for the next kernel to compile (i wish LTO was extra efficient).
Posted Nov 8, 2015 2:28 UTC (Solar) by jejb (subscriber, #6654) [Hyperlink]
In different phrases, you tried to outline their process for them ... I can not assume why that would not work. > "Lies, damned lies, and statistics". The problem with ad hominem assaults is that they are singularly ineffective towards a transparently factual argument. I posted a one line command anybody may run to get the variety of patches you have authored in the kernel. Why do not you publish an equal that offers figures you like more? > i've by no means in my life tried to submit PaX upstream (for all the reasons mentioned already). So the master plan is to reveal your experience by the number of patches you haven't submitted? great plan, world domination beckons, sorry that one got away from you, but I'm certain you won't let it happen again.
Posted Nov 8, 2015 2:56 UTC (Solar) by PaXTeam (visitor, #24616) [Hyperlink]
what? since when does asking a question outline anything? isn't that how we discover out what someone else thinks? isn't that what *they* have that webform (never thoughts the mailing lists) for as effectively? in different words you admit that my query was not actually answered . > The issue with ad hominem attacks is that they are singularly ineffective against a transparently factual argument. you did not have an argument to begin with, that is what i explained within the half you rigorously selected not to quote. i am not here to defend myself in opposition to your clearly idiotic makes an attempt at proving whatever you're making an attempt to show, as they are saying even in kernel circles, code speaks, bullshit walks. you'll be able to look at mine and decide what i can or cannot do (not that you have the knowledge to understand most of it, mind you). that said, there're clearly different more capable individuals who've carried out so and determined that my/our work was value something else no one would have been feeding off of it for the previous 15 years and still counting. and as unimaginable as it might seem to you, life would not revolve around the vanilla kernel, not everyone's dying to get their code in there particularly when it means to place up with such silly hostility on lkml that you just now additionally demonstrated right here (it is ironic the way you came to the defense of josh who specifically asked individuals not to deliver that infamous lkml fashion right here. nice job there James.). as for world domination, there're many ways to attain it and something tells me that you're clearly out of your league here since PaX has already achieved that. you are working such code that implements PaX options as we speak.
Posted Nov 8, 2015 16:Fifty two UTC (Solar) by jejb (subscriber, #6654) [Hyperlink]
I posted the one line git script giving your authored patches in response to this original request by you (this one, simply in case you have forgotten http://lwn.web/Articles/663591/): > as for getting code upstream, how about you examine the kernel git logs (minus the stuff that was not properly credited)? I take it, by the best way you've shifted ground in the earlier threads, that you just wish to withdraw that request?
Posted Nov 8, 2015 19:31 UTC (Solar) by PaXTeam (visitor, #24616) [Link]
Posted Nov 8, 2015 22:31 UTC (Sun) by pizza (subscriber, #46) [Hyperlink]
Please present one that is not wrong, or less fallacious. It can take much less time than you have already wasted right here.
Posted Nov 8, 2015 22:Forty nine UTC (Solar) by PaXTeam (visitor, #24616) [Hyperlink]
anyway, since it's you guys who've a bee in your bonnet, let's take a look at your stage of intelligence too. first determine my electronic mail deal with and venture name then try to seek out the commits that say they arrive from there (it introduced again some memories from 2004 already, how times flies! i'm surprised i truly managed to perform this much with explicitly not making an attempt, think about if i did :). it's an extremely complex process so by conducting it you may prove your self to be the highest canine right here on lwn, no matter that's worth ;).
Posted Nov 8, 2015 23:25 UTC (Solar) by pizza (subscriber, #46) [Link]
*shrug* Or do not; you are only sullying your individual reputation.
Posted Nov 9, 2015 7:08 UTC (Mon) by jospoortvliet (visitor, #33164) [Hyperlink]
Posted Nov 9, 2015 11:38 UTC (Mon) by hkario (subscriber, #94864) [Link]
I would not both
Posted Nov 12, 2015 2:09 UTC (Thu) by jschrod (subscriber, #1646) [Hyperlink]
Posted Nov 12, 2015 8:50 UTC (Thu) by nwmcsween (guest, #62367) [Hyperlink]
Posted Nov 8, 2015 3:38 UTC (Sun) by PaXTeam (visitor, #24616) [Link]
Posted Nov 12, 2015 13:47 UTC (Thu) by nix (subscriber, #2304) [Link]
Ah. I thought my reminiscence wasn't failing me. Compare to PaXTeam's response to <http: lwn.net articles 663612 />. PaXTeam is not averse to outright lying if it means he gets to appear proper, I see. Maybe PaXTeam's memory is failing, and this apparent contradiction just isn't a brazen lie, but provided that the 2 posts have been made inside a day of one another I doubt it. (PaXTeam's complete unwillingness to assume good faith in others deserves some reflection. Yes, I *do* suppose he is lying by implication here, and doing so when there's virtually nothing at stake. God alone is aware of what he is prepared to stoop to when something *is* at stake. Gosh I wonder why his fixes aren't going upstream very quick.)
Posted Nov 12, 2015 14:Eleven UTC (Thu) by PaXTeam (guest, #24616) [Link]
> and that one commit you discovered that went in regardless of said ban additionally someone's ban does not imply it's going to translate into another person's execution of that ban as it is clear from the commit in query. it is considerably unhappy that it takes a safety repair to expose the fallacy of this coverage although. the rest of your pithy ad hominem speaks for itself higher than i ever might ;).
Posted Nov 12, 2015 15:Fifty eight UTC (Thu) by andreashappe (subscriber, #4810) [Link]
Posted Nov 7, 2015 19:01 UTC (Sat) by cwillu (guest, #67268) [Link]
I do not see this message in my mailbox, so presumably it got swallowed.
Posted Nov 7, 2015 22:33 UTC (Sat) by ssmith32 (subscriber, #72404) [Hyperlink]
You're conscious that it is totally potential that everyone seems to be unsuitable here , proper? That the kernel maintainers have to focus extra on security, that the article was biased, that you're irresponsible to decry the state of security, and do nothing to help, and that your patchsets would not help that a lot and are the unsuitable course for the kernel? That just because the kernel maintainers aren't 100% right it doesn't suggest you're?
Posted Nov 9, 2015 9:50 UTC (Mon) by njd27 (visitor, #5770) [Link]
I believe you may have him backwards there. Jon is evaluating this to Mindcraft because he thinks that regardless of being unpalatable to quite a lot of the neighborhood, the article may in actual fact contain quite a lot of fact.
Posted Nov 9, 2015 14:03 UTC (Mon) by corbet (editor, #1) [Hyperlink]
Posted Nov 9, 2015 15:Thirteen UTC (Mon) by spender (visitor, #23067) [Link]
"There are rumors of darkish forces that drove the article within the hopes of taking Linux down a notch. All of this could well be true" Just as you criticized the article for mentioning Ashley Madison although within the very first sentence of the following paragraph it mentions it did not contain the Linux kernel, you can't give credence to conspiracy theories without incurring the identical criticism (in other words, you can't play the Glenn Beck "I am just asking the questions here!" whose "questions" gas the conspiracy theories of others). Much like mentioning Ashley Madison for instance for non-technical readers about the prevalence of Linux on the earth, if you're criticizing the mention then shouldn't likening a non-FUD article to a FUD article additionally deserve criticism, particularly given the rosy, self-congratulatory picture you painted of upstream Linux safety? As the PaX Staff pointed out within the initial publish, the motivations aren't laborious to know -- you made no mention at all about it being the fifth in a long-working collection following a fairly predictable time trajectory. No, we did not miss the overall analogy you were trying to make, we just don't think you may have your cake and eat it too. -Brad
Posted Nov 9, 2015 15:18 UTC (Mon) by karath (subscriber, #19025) [Link]
Posted Nov 9, 2015 17:06 UTC (Mon) by k3ninho (subscriber, #50375) [Link]
It's gracious of you to not blame your readers. I figure they're a good goal: there's that line about those ignorant of history being condemned to re-implement Unix -- as your readers are! :-) K3n.
Posted Nov 9, 2015 18:Forty three UTC (Mon) by bojan (subscriber, #14302) [Hyperlink]
Unfortunately, I do not perceive neither the "safety" people (PaXTeam/spender), nor the mainstream kernel people when it comes to their attitude. I confess I have completely no technical capabilities on any of those topics, but when they all determined to work together, as an alternative of getting infinite and pointless flame wars and blame recreation exchanges, numerous the stuff would have been accomplished already. And all the whereas everyone involved could have made one other huge pile of money on the stuff. They all seem to wish to have a better Linux kernel, so I've received no concept what the problem is. It appears that evidently no one is willing to yield any of their positions even somewhat bit. As an alternative, each sides seem like bent on making an attempt to insult their means into forcing the opposite aspect to quit. Which, of course, never works - it simply causes more pushback. Perplexing stuff...
Posted Nov 9, 2015 19:00 UTC (Mon) by sfeam (subscriber, #2841) [Link]
Posted Nov 9, 2015 19:Forty four UTC (Mon) by bojan (subscriber, #14302) [Hyperlink]
Take a scientific computational cluster with an "air gap", as an example. You'd probably need most of the security stuff turned off on it to gain most efficiency, because you possibly can trust all users. Now take a few billion mobile phones which may be tough or gradual to patch. You'd most likely wish to kill most of the exploit courses there, if these units can still run moderately nicely with most security features turned on. So, it is not either/or. It's most likely "it depends". However, if the stuff is not there for everyone to compile/use in the vanilla kernel, it will be more difficult to make it a part of on a regular basis choices for distributors and users.
Posted Nov 6, 2015 22:20 UTC (Fri) by artem (subscriber, #51262) [Link]
How sad. This Dijkstra quote involves mind instantly: Software engineering, in fact, presents itself as another worthy trigger, but that's eyewash: when you fastidiously read its literature and analyse what its devotees really do, you will uncover that software program engineering has accepted as its charter "Learn how to program if you cannot."
Posted Nov 7, 2015 0:35 UTC (Sat) by roc (subscriber, #30627) [Hyperlink]
I suppose that reality was too unpleasant to fit into Dijkstra's world view.
Posted Nov 7, 2015 10:Fifty two UTC (Sat) by ms (subscriber, #41272) [Hyperlink]
Indeed. And the fascinating factor to me is that once I attain that point, tests should not ample - model checking at a minimum and actually proofs are the one way forwards. I'm no security expert, my area is all distributed techniques. I understand and have carried out Paxos and i believe I can explain how and why it works to anybody. However I am currently performing some algorithms combining Paxos with a bunch of variations on VectorClocks and reasoning about causality and consensus. No take a look at is adequate because there are infinite interleavings of events and my head just couldn't cope with engaged on this either at the pc or on paper - I found I could not intuitively purpose about these items at all. So I started defining the properties and wished and step-by-step proving why every of them holds. With out my notes and proofs I can not even explain to myself, let alone anybody else, why this thing works. I find this each fully apparent that this may occur and totally terrifying - the maintenance value of these algorithms is now an order of magnitude larger.
Posted Nov 19, 2015 12:24 UTC (Thu) by Wol (subscriber, #4433) [Hyperlink]
> Certainly. And the fascinating factor to me is that once I reach that point, tests usually are not enough - model checking at a minimum and really proofs are the one method forwards. Or are you just utilizing the unsuitable maths? Hobbyhorse time again :-) but to quote a fellow Choose developer ... "I typically walk right into a SQL improvement shop and see that wall - you realize, the one with the massive SQL schema that no-one totally understands on it - and surprise how I can simply hold the entire schema for a Pick database of the identical or greater complexity in my head". However it's easy - by schooling I am a Chemist, by interest a Bodily Chemist (and by career an unemployed programmer :-). And when I'm thinking about chemistry, I can ask myself "what is an atom made of" and assume about things like the strong nuclear power. Next stage up, how do atoms stick together and make molecules, and suppose concerning the electroweak drive and electron orbitals, and the way do chemical reactions occur. Then I think about molecules stick collectively to make materials, and think about metals, and/or Van de Waals, and stuff. Point is, you might want to *layer* stuff, and look at things, and say "how can I split elements off into 'black boxes' so at anyone level I can assume the other levels 'just work'". For instance, with Pick a FILE (table to you) stores a class - a set of similar objects. One object per Document (row). And, similar as relational, one attribute per Field (column). Are you able to map your relational tables to reality so simply? :-) Going again THIRTY years, I remember a story about a guy who constructed little laptop crabs, that could fairly fortunately scuttle round in the surf zone. Because he did not attempt to work out how to solve all the issues without delay - every of his (extremely puny by immediately's requirements - that is the 8080/Z80 period!) processors was set to just process a bit of bit of the issue and there was no central "brain". MINECRAFT GALLERY Nevertheless it worked ... Possibly you should simply write a bunch of small modules to solve every individual problem, and let final reply "just occur". Cheers, Wol
Posted Nov 19, 2015 19:28 UTC (Thu) by ksandstr (guest, #60862) [Link]
To my understanding, this is strictly what a mathematical abstraction does. For instance in Z notation we'd assemble schemas for the various modifying ("delta") operations on the base schema, and then argue about preservation of formal invariants, properties of the end result, and transitivity of the operation when chained with itself, or the preceding aggregate schema composed of schemas A by way of O (for which they've been already argued). The end result is a set of operations that, executed in arbitrary order, result in a set of properties holding for the end result and outputs. Thus proving the formal design appropriate (w/ caveat lectors regarding scope, correspondence with its implementation [although that can be confirmed as well], and read-solely ["xi"] operations).
Posted Nov 20, 2015 11:23 UTC (Fri) by Wol (subscriber, #4433) [Hyperlink]
Wanting by the historical past of computing (and possibly loads of different fields too), you'll most likely find that folks "cannot see the wooden for the timber" more often that not. They dive into the detail and utterly miss the large image. (Drugs, and interest of mine, suffers from that too - I remember any person speaking in regards to the consultant eager to amputate a gangrenous leg to avoid wasting somebody's life - oblivious to the truth that the patient was dying of most cancers.) Cheers, Wol
Posted Nov 7, 2015 6:35 UTC (Sat) by dgc (subscriber, #6611) [Link]
https://www.youtube.com/watch?v=VpuVDfSXs-g (LCA 2015 - "Programming Thought-about Harmful") FWIW, I feel that this talk is very relevant to why writing secure software program is so hard.. -Dave.
Posted Nov 7, 2015 5:49 UTC (Sat) by kunitz (subscriber, #3965) [Hyperlink]
Whereas we are spending millions at a large number of safety issues, kernel points aren't on our high-precedence list. Honestly I remember only once having discussing a kernel vulnerability. The result of the evaluation has been that every one our systems had been working kernels that were older as the kernel that had the vulnerability. However "patch management" is an actual situation for us. Software program must proceed to work if we install safety patches or update to new releases due to the top-of-life policy of a vendor. The revenue of the company is relying on the IT systems operating. So "not breaking user space" is a safety characteristic for us, because a breakage of one element of our several ten thousands of Linux systems will stop the roll-out of the security replace. Another problem is embedded software or firmware. Nowadays virtually all hardware systems embody an operating system, typically some Linux model, offering a fill network stack embedded to assist distant management. Regularly those methods don't survive our obligatory safety scan, because distributors still didn't replace the embedded openssl. The actual problem is to supply a software program stack that can be operated within the hostile surroundings of the Internet sustaining full system integrity for ten years and even longer without any buyer upkeep. The present state of software program engineering would require support for an automatic replace process, but distributors should perceive that their enterprise mannequin should be capable of finance the resources offering the updates. General I'm optimistic, networked software shouldn't be the first know-how used by mankind causing problems that have been addressed later. Steam engine use might end in boiler explosions but the "engineers" have been in a position to reduce this danger considerably over a few many years.
Posted Nov 7, 2015 10:29 UTC (Sat) by ms (subscriber, #41272) [Hyperlink]
The following is all guess work; I might be keen to know if others have proof either a technique or another on this: The people who learn how to hack into these systems by kernel vulnerabilities know that they abilities they've learnt have a market. Thus they don't are inclined to hack with a purpose to wreak havoc - certainly on the entire where knowledge has been stolen with a view to launch and embarrass individuals, it _seems_ as if those hacks are by way of a lot easier vectors. I.e. lesser skilled hackers find there's an entire load of low-hanging fruit which they will get at. They don't seem to be being paid ahead of time for the data, so they turn to extortion as a substitute. They don't cowl their tracks, and they'll often be found and charged with criminal offences. So in case your security meets a certain basic level of proficiency and/or your organization is not doing something that places it near the highest of "corporations we would like to embarrass" (I suspect the latter is way more practical at preserving methods "safe" than the former), then the hackers that get into your system are more likely to be expert, paid, and doubtless not going to do much injury - they're stealing knowledge for a competitor / state. So that does not hassle your bottom line - at the very least not in a means which your shareholders will remember of. So why fund safety?
Posted Nov 7, 2015 17:02 UTC (Sat) by citypw (visitor, #82661) [Hyperlink]
Then again, some efficient mitigation in kernel degree could be very helpful to crush cybercriminal/skiddie's try. If one of your buyer running a future buying and selling platform exposes some open API to their shoppers, and if the server has some reminiscence corruption bugs can be exploited remotely. Then you recognize there are recognized assault strategies( such as offset2lib) will help the attacker make the weaponized exploit so much simpler. Will you explain the failosophy "A bug is bug" to your customer and tell them it might be ok? Btw, offset2lib is ineffective to PaX/Grsecurity's ASLR imp. To essentially the most industrial makes use of, more safety mitigation inside the software program will not value you extra finances. You'll nonetheless should do the regression test for each improve.
Posted Nov 12, 2015 16:14 UTC (Thu) by andreashappe (subscriber, #4810) [Link]
Remember that I specialize in exterior net-based penetration-assessments and that in-house tests (local LAN) will possible yield totally different results.
Posted Nov 7, 2015 20:33 UTC (Sat) by mattdm (subscriber, #18) [Hyperlink]
I keep studying this headline as "a new Minecraft second", and pondering that maybe they've determined to observe up the .Internet thing by open-sourcing Minecraft. Oh properly. I mean, safety is nice too, I assume.
Posted Nov 7, 2015 22:24 UTC (Sat) by ssmith32 (subscriber, #72404) [Link]
Posted Nov 12, 2015 17:29 UTC (Thu) by smitty_one_each (subscriber, #28989) [Hyperlink]
Posted Nov 8, 2015 10:34 UTC (Sun) by jcm (subscriber, #18262) [Link]
Posted Nov 9, 2015 7:15 UTC (Mon) by jospoortvliet (visitor, #33164) [Hyperlink]
Posted Nov 9, 2015 15:53 UTC (Mon) by neiljerram (subscriber, #12005) [Link]
(Oh, and I used to be additionally still questioning how Minecraft had taught us about Linux efficiency - so due to the other comment thread that identified the 'd', not 'e'.)
Posted Nov 9, 2015 11:31 UTC (Mon) by ortalo (guest, #4654) [Link]
I would just like so as to add that for my part, there is a normal downside with the economics of computer safety, which is very seen at the moment. Two issues even maybe. First, the money spent on pc safety is commonly diverted towards the so-referred to as security "circus": quick, easy solutions that are primarily chosen simply with a view to "do one thing" and get higher press. It took me a long time - perhaps decades - to claim that no security mechanism at all is better than a foul mechanism. But now I firmly believe in this angle and would fairly take the risk knowingly (provided that I can save cash/resource for myself) than take a bad strategy at fixing it (and haven't any cash/resource left after i realize I ought to have carried out something else). And that i find there are various dangerous or incomplete approaches currently accessible in the pc security field. Those spilling our uncommon money/resources on prepared-made useless instruments ought to get the unhealthy press they deserve. And, we certainly must enlighten the press on that because it is not really easy to understand the effectivity of protection mechanisms (which, by definition, ought to forestall things from happening). Second, and that could be newer and more worrying. The move of cash/useful resource is oriented within the direction of attack tools and vulnerabilities discovery a lot greater than in the path of latest safety mechanisms. This is especially worrying as cyber "protection" initiatives look more and more like the standard idustrial projects aimed at producing weapons or intelligence systems. Moreover, dangerous ineffective weapons, because they're only working in opposition to our very vulnerable current techniques; and unhealthy intelligence methods as even basic faculty-degree encryption scares them down to useless. Nevertheless, all of the ressources are for these adult teenagers enjoying the white hat hackers with not-so-tough programming tips or community monitoring or WWI-stage cryptanalysis. And now additionally for the cyberwarriors and cyberspies which have yet to show their usefulness fully (particularly for peace protection...). Personnally, I might fortunately depart them all of the hype; however I'll forcefully declare that they haven't any proper in anyway on any of the budget allocation selections. Only those working on safety ought to. And yep, it means we should always decide where to place there resources. We have now to assert the exclusive lock for ourselves this time. (and I assume the PaXteam could be among the first to benefit from such a change). While fascinated by it, I wouldn't even leave white-hat or cyber-guys any hype ultimately. That's extra publicity than they deserve. I crave for the day I will read in the newspaper that: "Another of these ill advised debutant programmer hooligans that pretend to be cyber-pirates/warriors modified some well-known virus program code exploiting a programmer mistake and managed however to bring one of those unfinished and dangerous quality applications, X, that we are all obliged to use to its knees, annoying millions of standard customers with his unlucky cyber-vandalism. All the protection consultants unanimously suggest that, once once more, the budget of the cyber-command be retargetted, or a minimum of leveled-off, to be able to deliver extra safety engineer positions in the educational domain or civilian trade. And that X's producer, XY Inc., be liable for the potential losses if proved to be unprofessional on this affair."
Hmmm - cyber-hooligans - I like the label. Although it doesn't apply well to the battlefield-oriented variant.
Posted Nov 9, 2015 14:28 UTC (Mon) by drag (visitor, #31333) [Link]
The state of 'software security business' is a f-ng catastrophe. Failure of the highest order. There is huge quantities of money that goes into 'cyber safety', however it is normally spent on government compliance and audit efforts. This implies instead of truly putting effort into correcting issues and mitigating future problems, nearly all of the hassle goes into taking present purposes and making them conform to committee-driven guidelines with the minimal amount of effort and changes. Some degree of regulation and standardization is absolutely needed, but lay individuals are clueless and are utterly unable to discern the distinction between any individual who has useful experience versus some company that has spent hundreds of thousands on slick advertising and 'native advertising' on large web sites and computer magazines. The people with the money sadly only have their very own judgment to depend on when shopping for into 'cyber safety'. > Those spilling our rare money/sources on ready-made ineffective tools should get the unhealthy press they deserve. There isn't any such factor as 'our rare cash/assets'. You've gotten your money, I've mine. Cash being spent by some company like Redhat is their money. Money being spent by governments is the government's money. (you, literally, have much more control in how Walmart spends it is money then over what your authorities does with their's) > This is particularly worrying as cyber "defense" initiatives look increasingly like the standard idustrial initiatives geared toward producing weapons or intelligence programs. Furthermore, bad ineffective weapons, because they are solely working in opposition to our very susceptible present systems; and unhealthy intelligence techniques as even basic school-stage encryption scares them all the way down to useless. Having secure software with robust encryption mechanisms within the fingers of the general public runs counter to the interests of most main governments. Governments, like any other for-revenue organization, are primarily considering self-preservation. Money spent on drone initiatives or banking auditing/oversight regulation compliance is Far more precious to them then trying to assist the public have a safe mechanism for making cellphone calls. Especially when those safe mechanisms interfere with information assortment efforts. Sadly you/I/us can not rely upon some magical benefactor with deep pockets to sweep in and make Linux better. It's simply not going to happen. Corporations like Redhat have been massively beneficial to spending assets to make Linux kernel more succesful.. however they're driven by a the need to show a revenue, which implies they should cater directly to the the kind of necessities established by their buyer base. Customers for EL are typically rather more centered on lowering prices related to administration and software growth then security at the low-level OS. Enterprise Linux customers are likely to depend on bodily, human coverage, and community security to protect their 'soft' interiors from being exposed to external threats.. assuming (rightly) that there's very little they'll do to actually harden their techniques. Actually when the selection comes between safety vs comfort I'm positive that most customers will happily defeat or strip out any security mechanisms launched into Linux. On top of that when most Enterprise software program is extremely bad. A lot in order that 10 hours spent on bettering a web front-end will yield extra real-world security advantages then a 1000 hours spent on Linux kernel bugs for most businesses. Even for 'regular' Linux users a security bug of their Firefox's NAPI flash plugin is way more devastating and poses a massively larger risk then a obscure Linux kernel buffer over move drawback. It's just not likely essential for attackers to get 'root' to get entry to the vital information... typically all of which is contained in a single person account. In the end it's as much as individuals like you and myself to put the trouble and money into bettering Linux security. For both ourselves and other people.
Posted Nov 10, 2015 11:05 UTC (Tue) by ortalo (visitor, #4654) [Hyperlink]
Spilling has always been the case, but now, to me and in pc safety, most of the money appears spilled as a consequence of bad faith. And this is mostly your cash or mine: both tax-fueled governemental resources or company costs which are straight reimputed on the prices of goods/software program we are advised we are *obliged* to buy. (Have a look at company firewalls, home alarms or antivirus software marketing discourse.) I believe it's time to level out that there are several "malicious malefactors" round and that there is an actual must establish and sanction them and confiscate the assets they have someway managed to monopolize. And i do *not* suppose Linus is among such culprits by the best way. However I believe he could also be amongst the ones hiding their heads in the sand concerning the aforementioned evil actors, whereas he probably has more leverage to counteract them or oblige them to reveal themselves than many people. I discover that to be of brown-paper-bag level (though head-in-the-sand is someway a brand new interpretation). In the end, I believe you might be right to say that currently it is only as much as us individuals to try truthfully to do one thing to enhance Linux or computer safety. However I nonetheless think that I am proper to say that this isn't normal; particularly while some very critical people get very serious salaries to distribute randomly some tough to evaluate budgets. [1] A paradoxical state of affairs once you give it some thought: in a site the place you might be at the start preoccupied by malicious individuals everyone should have factual, clear and honest habits as the primary precedence in their thoughts.
Posted Nov 9, 2015 15:47 UTC (Mon) by MarcB (subscriber, #101804) [Hyperlink]
It even has a pleasant, seven line Fundamental-pseudo-code that describes the present scenario and clearly exhibits that we are caught in an limitless loop. It doesn't answer the big query, though: How to write better software. The sad factor is, that that is from 2005 and all the issues that have been obviously stupid ideas 10 years ago have proliferated much more.
Posted Nov 10, 2015 11:20 UTC (Tue) by ortalo (visitor, #4654) [Hyperlink]
Note IMHO, we should examine additional why these dumb things proliferate and get a lot help. If it's only human psychology, nicely, let's combat it: e.g. Mozilla has proven us that they'll do wonderful things given the precise message. If we're going through energetic folks exploiting public credulity: let's determine and fight them. But, extra importantly, let's capitalize on this information and safe *our* techniques, to exhibit at a minimal (and more later on after all). Your reference conclusion is particularly nice to me. "challenge [...] the conventional wisdom and the established order": that job I might fortunately accept.
Posted Nov 30, 2015 9:39 UTC (Mon) by paulj (subscriber, #341) [Link]
That rant is itself a bunch of "empty calories". The converse to the items it rants about, which it's suggesting at some level, can be as bad or worse, and indicative of the worst kind of security thinking that has put lots of people off. Alternatively, it's just a rant that gives little of worth. Personally, I believe there's no magic bullet. Safety is and at all times has been, in human historical past, an arms race between defenders and attackers, and one that is inherently a commerce-off between usability, risks and prices. If there are mistakes being made, it's that we should always in all probability spend more resources on defences that might block total lessons of assaults. E.g., why is the GRSec kernel hardening stuff so onerous to apply to regular distros (e.g. there isn't any dependable supply of a GRSec kernel for Fedora or RHEL, is there?). Why does the whole Linux kernel run in one safety context? Why are we still writing lots of software in C/C++, often with none primary security-checking abstractions (e.g. fundamental bounds-checking layers in between I/O and parsing layers, say)? Can hardware do more to supply security with velocity? No doubt there are plenty of individuals engaged on "block lessons of assaults" stuff, the query is, why aren't there more assets directed there? FUN GALLERY
Posted Nov 10, 2015 2:06 UTC (Tue) by timrichardson (subscriber, #72836) [Link]
>There are a number of reasons why Linux lags behind in defensive safety applied sciences, however one in every of the important thing ones is that the companies earning money on Linux haven't prioritized the event and integration of those technologies. This looks as if a purpose which is de facto price exploring. Why is it so? I believe it is not apparent why this does not get some more attention. Is it potential that the individuals with the money are proper not to extra extremely prioritise this? Afterall, what interest have they got in an unsecure, exploitable kernel? The place there is frequent cause, linux improvement will get resourced. It's been this manner for many years. If filesystems qualify for common interest, surely security does. So there would not seem to be any apparent cause why this subject doesn't get more mainstream attention, except that it really already will get enough. It's possible you'll say that catastrophe has not struck but, that the iceberg has not been hit. However it appears to be that the linux growth course of is not overly reactive elsewhere.
Posted Nov 10, 2015 15:53 UTC (Tue) by raven667 (subscriber, #5198) [Hyperlink]
That is an interesting question, actually that is what they really believe regardless of what they publicly say about their commitment to security applied sciences. What's the truly demonstrated draw back for Kernel builders and the organizations that pay them, so far as I can inform there isn't enough consequence for the lack of Safety to drive more funding, so we're left begging and cajoling unconvincingly.
Posted Nov 12, 2015 14:37 UTC (Thu) by ortalo (guest, #4654) [Hyperlink]
The key challenge with this area is it relates to malicious faults. So, when penalties manifest themselves, it is simply too late to act. And if the present commitment to a scarcity of voluntary strategy persists, we're going to oscillate between phases of relaxed inconscience and anxious paranoia. Admittedly, kernel developpers appear fairly resistant to paranoia. That is an efficient thing. But I'm waiting for the days where armed land-drones patrol US streets in the vicinity of their children colleges for them to find the feeling. They aren't so distants the times when innocent lives will unconsciouly rely on the safety of (linux-based mostly) pc programs; underneath water, that is already the case if I remember appropriately my last dive, as well as in a number of latest automobiles in keeping with some reviews.
Posted Nov 12, 2015 14:32 UTC (Thu) by MarcB (subscriber, #101804) [Link]
Basic internet hosting corporations that use Linux as an uncovered entrance-finish system are retreating from improvement while HPC, cellular and "generic enterprise", i.E. RHEL/SLES, are pushing the kernel in their directions. This is actually not that shocking: For internet hosting needs the kernel has been "finished" for fairly some time now. In addition to support for present hardware there is not much use for newer kernels. Linux 3.2, or even older, works just fine. Hosting does not want scalability to lots of or thousands of CPU cores (one makes use of commodity hardware), complex instrumentation like perf or tracing (techniques are locked down as a lot as attainable) or advanced energy-management (if the system doesn't have constant excessive load, it is not making enough money). So why should internet hosting corporations nonetheless make strong investments in kernel growth? Even if they had one thing to contribute, the hurdles for contribution have become greater and better. For his or her security wants, hosting companies already use Grsecurity. I have no numbers, however some experience suggests that Grsecurity is mainly a set requirement for shared internet hosting. On the other hand, kernel security is almost irrelevant on nodes of a brilliant computer or on a system running large enterprise databases which are wrapped in layers of middle-ware. And mobile vendors merely do not care.
Posted Nov 10, 2015 4:18 UTC (Tue) by bronson (subscriber, #4806) [Link]
Linking
Posted Nov 10, 2015 13:15 UTC (Tue) by corbet (editor, #1) [Link]
Posted Nov 11, 2015 22:38 UTC (Wed) by rickmoen (subscriber, #6943) [Link]
The assembled doubtless recall that in August 2011, kernel.org was root compromised. I'm positive the system's exhausting drives were despatched off for forensic examination, and we have all been ready patiently for the answer to the most important question: What was the compromise vector? From shortly after the compromise was found on August 28, 2011, right through April 1st, 2013, kernel.org included this notice at the highest of the site Information: 'Because of all on your endurance and understanding during our outage and please bear with us as we deliver up the different kernel.org systems over the next few weeks. We will be writing up a report on the incident sooner or later.' (Emphasis added.) That comment was eliminated (together with the rest of the positioning Information) during a Could 2013 edit, and there hasn't been -- to my data -- a peep about any report on the incident since then. This has been disappointing. When the Debian Undertaking found sudden compromise of a number of of its servers in 2007, Wichert Akkerman wrote and posted a wonderful public report on exactly what occurred. Likewise, the Apache Foundation likewise did the appropriate thing with good public autopsies of the 2010 Internet site breaches. Arstechnica's Dan Goodin was nonetheless making an attempt to observe up on the lack of an autopsy on the kernel.org meltdown -- in 2013. Two years ago. He wrote: Linux developer and maintainer Greg Kroah-Hartman advised Ars that the investigation has but to be accomplished and gave no timetable for when a report might be released. [...] Kroah-Hartman additionally informed Ars kernel.org methods have been rebuilt from scratch following the attack. Officials have developed new tools and procedures since then, however he declined to say what they are. "There might be a report later this 12 months about site [sic] has been engineered, however do not quote me on when it will likely be launched as I'm not chargeable for it," he wrote. Who's responsible, then? Is anyone? Anybody? Bueller? Or is it a state secret, or what? Two years since Greg K-H mentioned there could be a report 'later this 12 months', and 4 years for the reason that meltdown, nothing yet. How about some information? Rick Moen [email protected]
Posted Nov 12, 2015 14:19 UTC (Thu) by ortalo (guest, #4654) [Hyperlink]
Much less critically, notice that if even the Linux mafia doesn't know, it have to be the venusians; they're notoriously stealth of their invasions.
Posted Nov 14, 2015 12:46 UTC (Sat) by error27 (subscriber, #8346) [Hyperlink]
I do know the kernel.org admins have given talks about some of the brand new protections which have been put into place. There are not any extra shell logins, as an alternative all the things makes use of gitolite. The different providers are on different hosts. There are more kernel.org staff now. Individuals are using two issue identification. Another stuff. Do a search for Konstantin Ryabitsev.
Posted Nov 14, 2015 15:Fifty eight UTC (Sat) by rickmoen (subscriber, #6943) [Link]
I beg your pardon if I was somehow unclear: That was mentioned to have been the path of entry to the machine (and that i can readily believe that, because it was additionally the exact path to entry into shells.sourceforge.net, a few years prior, round 2002, and into many different shared Web hosts for many years). However that's not what is of main interest, and is not what the forensic examine long promised would primarily concern: How did intruders escalate to root. To quote kernel.org administrator in the August 2011 Dan Goodin article you cited: 'How they managed to exploit that to root entry is presently unknown and is being investigated'. Ok, of us, you have now had four years of investigation. What was the trail of escalation to root? (Additionally, other particulars that would logically be lined by a forensic research, equivalent to: Whose key was stolen? Who stole the important thing?) This is the type of autopsy was promised prominently on the front web page of kernel.org, to reporters, and elsewhere for a very long time (and then summarily removed as a promise from the front page of kernel.org, without remark, along with the rest of the site Information section, and apparently dropped). It nonetheless can be applicable to know and share that information. Especially the datum of whether or not the path to root privilege was or was not a kernel bug (and, if not, what it was). Rick Moen [email protected]
Posted Nov 22, 2015 12:42 UTC (Solar) by rickmoen (subscriber, #6943) [Hyperlink]
I've done a closer review of revelations that got here out quickly after the break-in, and suppose I've found the answer, by way of a leaked copy of kernel.org chief sysadmin John H. 'Warthog9' Hawley's Aug. 29, 2011 e-mail to shell customers (two days before the public was informed), plus Aug. 31st comments to The Register's Dan Goodin by 'two safety researchers who had been briefed on the breach': Root escalation was through exploit of a Linux kernel security hole: Per the two safety researchers, it was one each extremely embarrassing (vast-open access to /dev/mem contents including the working kernel's image in RAM, in 2.6 kernels of that day) and known-exploitable for the prior six years by canned 'sploits, one in every of which (Phalanx) was run by some script kiddie after entry using stolen dev credentials. Other tidbits: - Site admins left the foundation-compromised Internet servers operating with all services still lit up, for a number of days. - Site admins and Linux Foundation sat on the knowledge and failed to inform the general public for those self same a number of days. - Site admins and Linux Foundation have by no means revealed whether trojaned Linux supply tarballs were posted within the http/ftp tree for the 19+ days before they took the site down. (Yes, git checkout was fine, however what in regards to the thousands of tarball downloads?) - After promising a report for a number of years after which quietly eradicating that promise from the entrance web page of kernel.org, Linux Foundation now stonewalls press queries.I posted my best attempt at reconstructing the story, absent a real report from insiders, to SVLUG's fundamental mailing checklist yesterday. (Necessarily, there are surmises. If the individuals with the information were extra forthcoming, we might know what happened for sure.) I do must surprise: If there's one other embarrassing screwup, will we even be advised about it in any respect? Rick Moen [email protected]
Posted Nov 22, 2015 14:25 UTC (Solar) by spender (visitor, #23067) [Link]
Additionally, it is preferable to use reside reminiscence acquisition previous to powering off the system, otherwise you lose out on reminiscence-resident artifacts you could carry out forensics on. -Brad
How about the lengthy overdue autopsy on the August 2011 kernel.org compromise?
Posted Nov 22, 2015 16:28 UTC (Solar) by rickmoen (subscriber, #6943) [Link]
Thanks to your feedback, Brad. I'd been counting on Dan Goodin's claim of Phalanx being what was used to realize root, within the bit where he cited 'two safety researchers who were briefed on the breach' to that impact. Goodin also elaborated: 'Fellow safety researcher Dan Rosenberg stated he was also briefed that the attackers used Phalanx to compromise the kernel.org machines.' This was the primary time I've heard of a rootkit being claimed to be bundled with an attack tool, and that i noted that oddity in my posting to SVLUG. That having been said, yeah, the Phalanx README doesn't specifically declare this, so then possibly Goodin and his a number of 'security researcher' sources blew that element, and nobody but kernel.org insiders but is aware of the escalation path used to achieve root. Also, it is preferable to make use of live memory acquisition previous to powering off the system, otherwise you lose out on memory-resident artifacts that you could carry out forensics on. Arguable, however a tradeoff; you possibly can poke the compromised reside system for state knowledge, but with the downside of leaving your system running below hostile management. I used to be all the time taught that, on balance, it is better to tug energy to finish the intrusion. Rick Moen [email protected]
Posted Nov 20, 2015 8:23 UTC (Fri) by toyotabedzrock (visitor, #88005) [Link]
Posted Nov 20, 2015 9:31 UTC (Fri) by gioele (subscriber, #61675) [Hyperlink]
With "something" you imply those that produce these closed source drivers, proper? If the "client product firms" simply stuck to using elements with mainlined open supply drivers, then updating their products would be a lot easier.
A brand new Mindcraft second?
Posted Nov 20, 2015 11:29 UTC (Fri) by Wol (subscriber, #4433) [Hyperlink]
They have ring 0 privilege, can access protected reminiscence directly, and cannot be audited. Trick a kernel into operating a compromised module and it's game over. Even tickle a bug in a "good" module, and it is most likely sport over - in this case quite literally as such modules are typically video drivers optimised for games ...
