A Brand New Mindcraft Moment

From Chess Moves
Jump to: navigation, search

Posted Nov 6, 2015 20:50 UTC (Fri) by PaXTeam (visitor, #24616) [Hyperlink]



1. this WP article was the fifth in a collection of articles following the security of the internet from its beginnings to relevant matters of as we speak. discussing the safety of linux (or lack thereof) fits properly in there. it was also a well-researched article with over two months of research and interviews, something you can't quite claim yourself for your recent items on the topic. you don't just like the info? then say so. and even higher, do one thing constructive about them like Kees and others have been attempting. nonetheless silly comparisons to previous crap like the Mindcraft studies and fueling conspiracies don't precisely assist your case. 2. "We do a reasonable job of finding and fixing bugs." let's start here. is this assertion based mostly on wishful considering or cold laborious 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 gadgets folks purchase and use and ditch in that interval. 3. "Problems, whether or not they're security-associated or not, are patched rapidly," some are, some aren't: let's not overlook the current NMI fixes that took over 2 months to trickle down to stable kernels and we also have a consumer who has been ready for over 2 weeks now: http://thread.gmane.org/gmane.comp.file-techniques.btrfs/49500 (FYI, the overflow plugin is the first one Kees is making an attempt to upstream, imagine the shitstorm if bugreports shall be handled with this attitude, let's hope btrfs guys are an exception, not the rule). anyway, two examples should not statistics, so once again, do you've numbers or is all of it wishful considering? (it's partly a trick query as a result of you will also have to explain how one thing gets to be determined to be security related which as we all know is a messy enterprise in the linux world) 4. "and the stable-update mechanism makes these patches obtainable to kernel users." besides when it does not. and sure, i have numbers: grsec carries 200+ backported patches in our 3.14 stable tree. 5. "Particularly, the few developers who're working in this space have never made a serious try to get that work integrated upstream." you don't should be shy about naming us, in any case you did so elsewhere already. and we also explained the explanation why we have not pursued upstreaming our code: https://lwn.net/Articles/538600/ . since i don't count on you and your readers to read any of it, here is the tl;dr: if you want us to spend thousands of hours of our time to upstream our code, you will have to pay for it. no ifs no buts, that is how the world works, that is how >90% of linux code will get in too. i personally discover it fairly hypocritic that nicely paid kernel builders are bitching about our unwillingness and inability to serve them our code on a silver platter without cost. and before someone brings up the CII, go test their mail archives, after some preliminary exploratory discussions i explicitly requested them about supporting this lengthy drawn out upstreaming work and bought no solutions.



Posted Nov 6, 2015 21:39 UTC (Fri) by patrick_g (subscriber, #44470) [Hyperlink]



Cash (aha) quote : > I propose you spend none of your free time on this. Zero. I propose you receives a commission to do this. And nicely. Nobody anticipate you to serve your code on a silver platter without cost. The Linux basis and big firms utilizing Linux (Google, Crimson Hat, Oracle, Samsung, etc.) ought to pay safety specialists like you to upstream your patchs.



Posted Nov 6, 2015 21:57 UTC (Fri) by nirbheek (subscriber, #54111) [Link]



I would just like to point out that the way in which you phrased this makes your remark a tone argument[1][2]; you've got (most likely unintentionally) dismissed all of the father or mother's arguments by pointing at its presentation. The tone of PAXTeam's comment shows the frustration built up over time with the way in which things work which I feel must be taken at face worth, empathized with, and understood fairly than merely dismissed. 1. http://rationalwiki.org/wiki/Tone_argument 2. http://geekfeminism.wikia.com/wiki/Tone_argument Cheers,



Posted Nov 7, 2015 0:Fifty five UTC (Sat) by josh (subscriber, #17465) [Link]



Posted Nov 7, 2015 1:21 UTC (Sat) by PaXTeam (visitor, #24616) [Hyperlink]



why, is upstream identified for its basic civility and decency? have you ever even read the WP submit underneath discussion, never mind previous lkml visitors?



Posted Nov 7, 2015 5:37 UTC (Sat) by josh (subscriber, #17465) [Link]



Posted Nov 7, 2015 5:34 UTC (Sat) by gmatht (visitor, #58961) [Link]



No Argument



Posted Nov 7, 2015 6:09 UTC (Sat) by josh (subscriber, #17465) [Hyperlink]



Please do not; it doesn't belong there both, and it especially does not need a cheering part because the tech press (LWN usually excepted) tends to provide.



Posted Nov 8, 2015 8:36 UTC (Solar) by gmatht (visitor, #58961) [Link]



Ok, but I used to be thinking of Linus Torvalds



Posted Nov 8, 2015 16:Eleven UTC (Solar) by pbonzini (subscriber, #60935) [Hyperlink]



Posted Nov 6, 2015 22:Forty three UTC (Fri) by PaXTeam (guest, #24616) [Link]



Posted Nov 6, 2015 23:00 UTC (Fri) by pr1268 (subscriber, #24648) [Link]



Why must you assume only money will fix this drawback? Sure, I agree extra resources must be spent on fixing Linux kernel safety issues, but do not assume someone giving a corporation (ahem, PAXTeam) cash is the one resolution. (Not imply to impugn PAXTeam's security efforts.)



The Linux development group may have had the wool pulled over its collective eyes with respect to safety points (both actual or perceived), however merely throwing money at the issue will not fix this.



And sure, I do notice the commercial Linux distros do heaps (most?) of the kernel improvement today, and that implies indirect monetary transactions, however it is a lot more involved than just 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:Forty nine UTC (Sat) by PaXTeam (visitor, #24616) [Link]



Posted Nov 6, 2015 23:13 UTC (Fri) by dowdle (subscriber, #659) [Link]



I feel you positively agree with the gist of Jon's argument... not enough focus has been given to security within the Linux kernel... the article gets that part proper... money hasn't been going towards security... and now it needs to. Aren't you glad?



Posted Nov 7, 2015 1:37 UTC (Sat) by PaXTeam (guest, #24616) [Hyperlink]



they talked to spender, not me personally, but sure, this side of the coin is well represented by us and others who were interviewed. the identical method Linus is an efficient representative of, well, his personal pet challenge known as linux. > And if Jon had solely talked to you, his would have been too. provided that i am the writer of PaX (a part of grsec) yes, talking to me about grsec matters makes it the most effective methods to analysis it. but if you know of another person, be my guest and identify them, i am pretty sure the just lately formed kernel self-protection people can be dying to have interaction them (or not, i do not suppose there's a sucker on the market with hundreds of hours of free time on their hand). > [...]it also contained quite just a few of groan-worthy statements. nothing is ideal however considering the viewers of the WP, that is considered one of the better journalistic items on the subject, regardless of how you and others don't like the sorry state of linux safety exposed in there. if you would like to discuss more technical particulars, nothing stops you from speaking to us ;). speaking of your complaints about journalistic qualities, since a previous LWN article saw it fit to include a number of typical dismissive claims by Linus about the standard of unspecified grsec features with no proof of what experience he had with the code and the way recent it was, how come we didn't see you or anybody else complaining about the standard of that article? > Aren't you glad? no, or not but anyway. i've heard numerous empty phrases through the years and nothing ever manifested or worse, all the cash has gone to the pointless exercise of fixing particular person bugs and associated 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]



Proper now we've got developers from large names saying that doing all that the Linux ecosystem does *safely* is an itch that they've. Unfortunately, the encircling cultural angle of developers is to hit practical targets, and occasionally efficiency goals. Security objectives are sometimes ignored. Ideally, the tradition would shift in order that we make it troublesome to comply with insecure habits, patterns or paradigms -- that could be a activity that can take a sustained effort, not merely the upstreaming of patches. Whatever the tradition, these patches will go upstream eventually anyway because the ideas that they embody at the moment are timely. I can see a option to make it happen: Linus will accept them when a giant finish-person (say, Intel, Google, Facebook or Amazon) delivers stuff with notes like 'this is a set of enhancements, we're already utilizing them to resolve this type of downside, this is how the whole lot will remain working because $proof, word carefully that you are staring down the barrels of a fork as a result of your tree is now evolutionarily disadvantaged'. It's a sport and will be gamed; I'd desire that the neighborhood shepherds customers to follow the sample of declaring problem + resolution + practical check evidence + efficiency take a look at evidence + safety take a look at proof. K3n.



Posted Nov 9, 2015 6:49 UTC (Mon) by jospoortvliet (visitor, #33164) [Hyperlink]



And about that fork barrel: I'd argue it is the opposite way around. Google forked and misplaced already.



Posted Nov 12, 2015 6:25 UTC (Thu) by Garak (guest, #99377) [Hyperlink]



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 need to confess to a certain amount of confusion. I might swear that the article I wrote said exactly that, however you've put a fair quantity of effort into flaming it...?



Posted Nov 8, 2015 1:34 UTC (Solar) by PaXTeam (visitor, #24616) [Hyperlink]



Posted Nov 6, 2015 22:Fifty two UTC (Fri) by flussence (subscriber, #85566) [Hyperlink]



I personally suppose you and Nick Krause share opposite sides of the identical coin. Programming potential and primary civility.



Posted Nov 6, 2015 22:59 UTC (Fri) by dowdle (subscriber, #659) [Link]



Posted Nov 7, 2015 0:Sixteen UTC (Sat) by rahvin (visitor, #16953) [Hyperlink]



I hope I'm incorrect, however a hostile attitude isn't going to help anybody receives a commission. It is a time like this the place something you seem to be an "knowledgeable" at and there's a demand for that expertise the place you display cooperation and willingness to participate as a result of it is a chance. I am relatively shocked that someone does not get that, but I am older and have seen a couple of of those alternatives in my career and exploited the hell out of them. You only get a couple of of these in the typical career, and handful at probably the most. Typically it's a must to put money into proving your expertise, and this is a type of moments. It seems the Kernel group could lastly take this security lesson to coronary heart and embrace it, as stated in the article as a "mindcraft second". This is an opportunity for developers that will wish to work on Linux security. Some will exploit the opportunity and others will thumb their noses at it. In the end those builders that exploit the opportunity will prosper from it. I feel previous even having to write down that.



Posted Nov 7, 2015 1:00 UTC (Sat) by josh (subscriber, #17465) [Hyperlink]



Perhaps there's a rooster and egg problem right here, but when in search of out and funding people to get code upstream, it helps to pick people and groups with a historical past of with the ability to get code upstream. It's completely reasonable to want understanding of tree, providing the ability to develop spectacular and significant security advances unconstrained by upstream requirements. That's work somebody may also wish to fund, if that meets their wants.



Posted Nov 7, 2015 1:28 UTC (Sat) by PaXTeam (guest, #24616) [Link]



Posted Nov 7, 2015 19:12 UTC (Sat) by jejb (subscriber, #6654) [Hyperlink]



You make this argument (implying you do research and Josh would not) and then fail to support it by any cite. It can be rather more convincing if you quit on the Onus probandi rhetorical fallacy and really cite information. > working example, it was *them* who recommended that they wouldn't fund out-of-tree work however would consider funding upstreaming work, besides when pressed for the small print, all i obtained was silence. For those following along at home, this is the related set of threads: http://lists.coreinfrastructure.org/pipermail/cii-talk about... A quick precis is that they instructed you your venture was unhealthy as a result of the code was never going upstream. You told them it was due to kernel developers attitude 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 told you that submitting a proposal could be the neatest thing to do. At that time you went silent, not vice versa as you imply above. > obviously i won't spend time to write down up a begging proposal simply to be instructed that 'no sorry, we do not fund multi-yr initiatives at all'. that is one thing that one should be informed in advance (or heck, be part of some public guidelines in order that others will know the rules too). You appear to have a fatally flawed grasp of how public funding works. If you don't inform individuals why you need the cash and how you'll spend it, they're unlikely to disburse. Saying I'm sensible and I do know the issue now hand over the money does not even work for most Teachers who've a solid repute in the sector; which is why most of them spend >30% of their time writing grant proposals. > as for getting code upstream, how about you test the kernel git logs (minus the stuff that was not correctly credited)? jejb@jarvis> git log|grep -i 'Creator: pax.*staff'|wc -l 1 Stellar, I have to say. And earlier than you gentle off on these who've misappropriated your credit score, please keep in mind that getting code upstream on behalf of reluctant or incapable actors is a hugely invaluable and time consuming ability and considered one of the explanations groups like Linaro exist and are well funded. If extra of your stuff does go upstream, will probably be because of the not inconsiderable efforts of other individuals in this area. You now have a enterprise mannequin promoting non-upstream safety patches to prospects. There's nothing wrong with that, it is a fairly normal first stage enterprise mannequin, but it surely does slightly rely upon patches not being upstream in the first place, calling into query the earnestness of your attempt to put them there. Now here is some free recommendation in my area, which is assisting firms align their companies in open supply: The promoting out of tree patch route is all the time an eventual failure, particularly with the kernel, as a result of if the performance is that useful, it will get upstreamed or reinvented in your despite, leaving you with nothing to promote. In case your business plan B is promoting experience, you could have to bear in mind that it should be a hard sell when you've got no out of tree differentiator left and git history denies that you simply had something to do with the in-tree patches. In reality "loopy security person" will change into a self fulfilling prophecy. The recommendation? it was obvious to everybody else who read this, but for you, it is do the upstreaming your self earlier than it gets accomplished for you. That way you have got a reliable historical declare to Plan B and you may actually have a Plan A promoting a rollup of upstream track patches built-in and delivered earlier than the distributions get round to it. Even your utility to the CII could not be dismissed because your work wasn't going wherever. Your different is to proceed playing the function of Cassandra and probably suffer her eventual fate.



Posted Nov 7, 2015 23:20 UTC (Sat) by PaXTeam (guest, #24616) [Link]



> Second, for the probably viable items this would be a multi-year > full time job. Is the CII willing to fund projects at that level? If not > we all would find yourself with a number of unfinished and partially broken options. please present me the reply to that query. without a definitive 'yes' there isn't any point in submitting a proposal as a result of this is the time frame that in my view the job will take and any proposal with that requirement could be shot down immediately and be a waste of my time. and that i stand by my claim that such simple fundamental requirements needs to be public info. > Stellar, I need to say. "Lies, damned lies, and statistics". you notice there's multiple approach to get code into the kernel? how about you use your git-fu to seek out all the bugreports/instructed fixes that went in as a result of us? as for particularly me, Greg explicitly banned me from future contributions by way of af45f32d25cc1 so it's no marvel i don't ship patches instantly in (and that one commit you discovered that went in regardless of mentioned ban is actually a very dangerous example as a result of it's also the one which Linus censored for no good cause and made me resolve to never send safety fixes upstream till that observe modifications). > You now have a business mannequin promoting non-upstream security patches to customers. now? we have had paid sponsorship for our varied stable kernel collection for 7 years. i would not call it a enterprise model although because it hasn't paid anybody's payments. > [...]calling into question the earnestness of your try to place them there. i should be missing one thing right here however what try? i've never in my life tried to submit PaX upstream (for all the explanations mentioned already). the CII mails had been exploratory to see how severe that complete organization is about actually securing core infrastructure. in a sense i've received my answers, there's nothing more to the story. as for your free recommendation, let me reciprocate: complicated problems don't remedy themselves. code fixing advanced issues would not write itself. people writing code fixing complex problems are few and much between that you'll find out in short order. such folks (domain experts) do not work totally free with few exceptions like ourselves. biting the hand that feeds you'll solely end you up in starvation. PS: since you are so certain about kernel builders' potential to reimplement our code, maybe have a look at what parallel options i still maintain in PaX regardless of vanilla having a 'completely-not-reinvented-right here' implementation and take a look at to grasp the reason. or simply take a look at all the CVEs that affected say vanilla's ASLR however did not have an effect on mine. PPS: Cassandra never wrote code, i do. criticizing the sorry state of kernel safety is a aspect venture when i am bored or simply ready for the subsequent kernel to compile (i want LTO was extra efficient).



Posted Nov 8, 2015 2:28 UTC (Solar) by jejb (subscriber, #6654) [Hyperlink]



In other words, you tried to define their course of for them ... I can't suppose why that would not work. > "Lies, damned lies, and statistics". The problem with ad hominem assaults is that they're singularly ineffective in opposition to a transparently factual argument. I posted a one line command anybody could run to get the variety of patches you've authored within the kernel. Why don't you post an equivalent that offers figures you like extra? > i've by no means in my life tried to submit PaX upstream (for all the explanations discussed already). So the grasp plan is to demonstrate your experience by the number of patches you haven't submitted? great plan, world domination beckons, sorry that one received away from you, but I am certain you won't let it occur once more.



Posted Nov 8, 2015 2:56 UTC (Solar) by PaXTeam (visitor, #24616) [Hyperlink]



what? since when does asking a question outline something? isn't that how we discover out what another person thinks? isn't that what *they* have that webform (never thoughts the mailing lists) for as properly? in other words you admit that my query was not really answered . > The issue with ad hominem assaults is that they are singularly ineffective in opposition to a transparently factual argument. you did not have an argument to start with, that's what i explained within the part you rigorously chose to not quote. i am not here to defend myself in opposition to your clearly idiotic makes an attempt at proving no matter you're making an attempt to show, as they are saying even in kernel circles, code speaks, bullshit walks. you'll be able to have a look at mine and determine what i can or cannot do (not that you've got the data to know most of it, mind you). that mentioned, there're clearly other more capable folks who've done so and decided that my/our work was value something else nobody would have been feeding off of it for the previous 15 years and still counting. and as unimaginable as it could seem to you, life would not revolve across 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 simply now also demonstrated here (it is ironic the way you came to the defense of josh who particularly requested folks not to deliver that notorious lkml fashion right here. good job there James.). as for world domination, there're some ways to achieve it and one thing tells me that you are clearly out of your league right here since PaX has already achieved that. you're operating such code that implements PaX options as we speak.



Posted Nov 8, 2015 16:Fifty two UTC (Sun) by jejb (subscriber, #6654) [Link]



I posted the one line git script giving your authored patches in response to this original request by you (this one, just in case you've got forgotten http://lwn.web/Articles/663591/): > as for getting code upstream, how about you check the kernel git logs (minus the stuff that was not properly credited)? I take it, by the way you've got shifted ground in the earlier threads, that you simply want to withdraw that request?



Posted Nov 8, 2015 19:31 UTC (Solar) by PaXTeam (visitor, #24616) [Hyperlink]



Posted Nov 8, 2015 22:31 UTC (Solar) by pizza (subscriber, #46) [Link]



Please provide one that's not incorrect, or less mistaken. It is going to take less time than you've got already wasted here.



Posted Nov 8, 2015 22:49 UTC (Solar) by PaXTeam (guest, #24616) [Hyperlink]



anyway, since it is you guys who have a bee in your bonnet, let's take a look at your level of intelligence too. first figure out my email address and mission title then try to seek out the commits that say they come from there (it brought back some reminiscences from 2004 already, how occasions flies! i am surprised i truly managed to accomplish this much with explicitly not making an attempt, think about if i did :). it's an extremely complex process so by carrying out it you'll show your self to be the highest canine here on lwn, no matter that's worth ;).



Posted Nov 8, 2015 23:25 UTC (Solar) by pizza (subscriber, #46) [Link]



*shrug* Or don't; you're only sullying your own 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) [Hyperlink]



I wouldn't either



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) [Link]



Posted Nov 8, 2015 3:38 UTC (Solar) by PaXTeam (guest, #24616) [Link]



Posted Nov 12, 2015 13:Forty seven UTC (Thu) by nix (subscriber, #2304) [Hyperlink]



Ah. I thought my reminiscence wasn't failing me. Evaluate to PaXTeam's response to <http: lwn.net articles 663612 />. PaXTeam is not averse to outright mendacity if it means he will get to appear proper, I see. Maybe PaXTeam's reminiscence is failing, and this obvious contradiction will not be a brazen lie, however on condition that the 2 posts have been made within a day of each other I doubt it. (PaXTeam's complete unwillingness to assume good faith in others deserves some reflection. Yes, I *do* assume he's lying by implication right here, and doing so when there's almost nothing at stake. God alone is aware of what he is willing to stoop to when one thing *is* at stake. Gosh I'm wondering why his fixes aren't going upstream very quick.)



Posted Nov 12, 2015 14:Eleven UTC (Thu) by PaXTeam (visitor, #24616) [Hyperlink]



> and that one commit you found that went in despite said ban also somebody's ban does not imply it'll translate into someone else's execution of that ban as it's clear from the commit in question. it's considerably sad that it takes a safety fix to expose the fallacy of this policy although. the remainder of your pithy advert hominem speaks for itself higher than i ever might ;).



Posted Nov 12, 2015 15:Fifty eight UTC (Thu) by andreashappe (subscriber, #4810) [Hyperlink]



Posted Nov 7, 2015 19:01 UTC (Sat) by cwillu (visitor, #67268) [Hyperlink]



I don't 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 aware that it's entirely doable that everyone is incorrect right here , right? That the kernel maintainers need to focus more on security, that the article was biased, that you're irresponsible to decry the state of security, and do nothing to assist, and that your patchsets would not assist that much and are the unsuitable direction for the kernel? That simply because the kernel maintainers aren't 100% right it does not imply you're?



Posted Nov 9, 2015 9:50 UTC (Mon) by njd27 (guest, #5770) [Hyperlink]



I feel you have got him backwards there. Jon is evaluating this to Mindcraft because he thinks that regardless of being unpalatable to a lot of the community, the article would possibly in truth contain a lot of fact.



Posted Nov 9, 2015 14:03 UTC (Mon) by corbet (editor, #1) [Hyperlink]



Posted Nov 9, 2015 15:13 UTC (Mon) by spender (visitor, #23067) [Hyperlink]



"There are rumors of dark forces that drove the article in the hopes of taking Linux down a notch. All of this might nicely be true" Just as you criticized the article for mentioning Ashley Madison regardless that within the very first sentence of the following paragraph it mentions it did not involve the Linux kernel, you can't give credence to conspiracy theories with out incurring the same criticism (in other phrases, you cannot play the Glenn Beck "I am just asking the questions right here!" whose "questions" fuel the conspiracy theories of others). Much like mentioning Ashley Madison for instance for non-technical readers concerning the prevalence of Linux on this planet, if you're criticizing the mention then mustn't likening a non-FUD article to a FUD article also deserve criticism, particularly given the rosy, self-congratulatory picture you painted of upstream Linux security? As the PaX Crew pointed out in the initial publish, the motivations aren't onerous to know -- you made no point out in any respect about it being the 5th in a protracted-running sequence following a pretty predictable time trajectory. No, we did not miss the general analogy you have been attempting to make, we just don't suppose you possibly can have your cake and eat it too. -Brad



Posted Nov 9, 2015 15:18 UTC (Mon) by karath (subscriber, #19025) [Hyperlink]



Posted Nov 9, 2015 17:06 UTC (Mon) by k3ninho (subscriber, #50375) [Hyperlink]



It is gracious of you to not blame your readers. I figure they're a good target: there's that line about these ignorant of historical past being condemned to re-implement Unix -- as your readers are! :-) K3n.



Posted Nov 9, 2015 18:43 UTC (Mon) by bojan (subscriber, #14302) [Hyperlink]



Unfortunately, I don't perceive neither the "security" of us (PaXTeam/spender), nor the mainstream kernel of us by way of their angle. I confess I've totally no technical capabilities on any of those topics, but when they all determined to work collectively, instead of having countless and pointless flame wars and blame sport exchanges, loads of the stuff would have been accomplished already. And all of the while everybody concerned may have made another huge pile of cash on the stuff. They all appear to need to have a better Linux kernel, so I've got no concept what the problem is. Evidently no person is willing to yield any of their positions even a bit of bit. Instead, both sides seem like bent on making an attempt to insult their way into forcing the opposite aspect to give up. Which, in fact, never works - it simply causes extra pushback. Perplexing stuff...



Posted Nov 9, 2015 19:00 UTC (Mon) by sfeam (subscriber, #2841) [Hyperlink]



Posted Nov 9, 2015 19:Forty four UTC (Mon) by bojan (subscriber, #14302) [Hyperlink]



Take a scientific computational cluster with an "air hole", for example. You'd in all probability want most of the safety stuff turned off on it to realize maximum performance, as a result of you'll be able to belief all customers. Now take a few billion cellphones that could be difficult or sluggish to patch. You'd probably need to kill many of the exploit classes there, if these devices can still run fairly effectively with most security features turned on. So, it is not either/or. It's in all probability "it depends". But, if the stuff is not there for everybody to compile/use within the vanilla kernel, it will likely be more difficult to make it part of everyday choices for distributors and customers.



Posted Nov 6, 2015 22:20 UTC (Fri) by artem (subscriber, #51262) [Hyperlink]



How unhappy. This Dijkstra quote comes to thoughts immediately: Software engineering, in fact, presents itself as one other worthy cause, however that is eyewash: if you happen to carefully learn its literature and analyse what its devotees actually do, you will discover that software program engineering has accepted as its charter "Learn how to program if you can not."



Posted Nov 7, 2015 0:35 UTC (Sat) by roc (subscriber, #30627) [Hyperlink]



I suppose that fact was too unpleasant to fit into Dijkstra's world view.



Posted Nov 7, 2015 10:52 UTC (Sat) by ms (subscriber, #41272) [Hyperlink]



Certainly. And the fascinating factor to me is that when I attain that time, tests will not be sufficient - model checking at a minimal and really proofs are the one means forwards. I am no safety skilled, my area is all distributed programs. I understand and have carried out Paxos and that i imagine I can explain how and why it really works to anyone. However I'm at the moment performing some algorithms combining Paxos with a bunch of variations on VectorClocks and reasoning about causality and consensus. No test is enough because there are infinite interleavings of occasions and my head just could not cope with working on this either at the pc or on paper - I found I couldn't intuitively motive about this stuff in any respect. So I started defining the properties and wanted and step-by-step proving why every of them holds. With out my notes and proofs I am unable to even clarify to myself, let alone anybody else, why this thing works. I discover this each fully obvious that this could occur and utterly terrifying - the maintenance value of those algorithms is now an order of magnitude higher.



Posted Nov 19, 2015 12:24 UTC (Thu) by Wol (subscriber, #4433) [Hyperlink]



> Indeed. And the fascinating factor to me is that after I attain that time, tests will not be adequate - model checking at a minimal and really proofs are the one means forwards. Or are you just using the wrong maths? Hobbyhorse time again :-) however to quote a fellow Pick developer ... "I often stroll into a SQL growth store and see that wall - you realize, the one with the large SQL schema that no-one absolutely understands on it - and marvel how I can easily hold your entire schema for a Pick database of the identical or greater complexity in my head". But it is easy - by schooling I am a Chemist, by curiosity a Physical Chemist (and by profession an unemployed programmer :-). And when I'm desirous about chemistry, I can ask myself "what's an atom product of" and assume about issues like the robust nuclear power. Next level up, how do atoms stick collectively and make molecules, and suppose concerning the electroweak drive and electron orbitals, and how do chemical reactions happen. Then I think about molecules stick together to make supplies, and suppose about metals, and/or Van de Waals, and stuff. Point is, you must *layer* stuff, and have a look at things, and say "how can I cut up parts off into 'black boxes' so at anyone level I can assume the opposite ranges 'just work'". For example, with Decide a FILE (desk to you) shops a class - a group of identical objects. One object per File (row). And, identical as relational, one attribute per Field (column). Can you map your relational tables to reality so easily? :-) Going back THIRTY years, I remember a narrative about a man who constructed little computer crabs, that could quite fortunately scuttle round in the surf zone. minecraft servers Because he didn't try to work out how to unravel all the issues without delay - every of his (incredibly puny by at present's requirements - this is the 8080/Z80 period!) processors was set to just course of a bit of bit of the issue and there was no central "brain". But it surely labored ... Possibly you need to simply write a bunch of small modules to solve each 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 exactly what a mathematical abstraction does. For instance in Z notation we might construct schemas for the varied modifying ("delta") operations on the base schema, after which argue about preservation of formal invariants, properties of the result, and transitivity of the operation when chained with itself, or the previous aggregate schema composed of schemas A by means of O (for which they've been already argued). The outcome is a set of operations that, executed in arbitrary order, lead to a set of properties holding for the outcome and outputs. Thus proving the formal design correct (w/ caveat lectors concerning scope, correspondence with its implementation [though that can be proven as properly], and browse-solely ["xi"] operations).



Posted Nov 20, 2015 11:23 UTC (Fri) by Wol (subscriber, #4433) [Hyperlink]



Looking by the historical past of computing (and probably plenty of other fields too), you will probably find that individuals "can't see the wooden for the timber" extra usually that not. They dive into the detail and utterly miss the big image. (Medication, and curiosity of mine, suffers from that too - I remember anyone speaking about the consultant eager to amputate a gangrenous leg to save 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) [Hyperlink]



https://www.youtube.com/watch?v=VpuVDfSXs-g (LCA 2015 - "Programming Thought of Harmful") FWIW, I think that this discuss is very relevant to why writing safe software is so onerous.. -Dave.



Posted Nov 7, 2015 5:Forty nine UTC (Sat) by kunitz (subscriber, #3965) [Hyperlink]



Whereas we are spending hundreds of thousands at a multitude of security issues, kernel issues will not be on our prime-precedence checklist. Honestly I remember only once having discussing a kernel vulnerability. The result of the evaluation has been that every one our methods have been working kernels that have been older as the kernel that had the vulnerability. But "patch management" is a real concern for us. Software program should proceed to work if we install security patches or update to new releases because of the end-of-life policy of a vendor. The income of the corporate is relying on the IT programs working. So "not breaking consumer space" is a safety feature for us, because a breakage of 1 component of our a number of ten 1000's of Linux techniques will stop the roll-out of the safety update. One other drawback is embedded software program or firmware. As of late virtually all hardware methods embody an working system, typically some Linux version, offering a fill community stack embedded to support distant administration. Commonly these methods don't survive our obligatory safety scan, because vendors nonetheless did not update the embedded openssl. The actual challenge is to provide a software program stack that can be operated within the hostile setting of the Internet sustaining full system integrity for ten years and even longer with none customer maintenance. The present state of software engineering would require assist for an automated replace course of, but distributors must understand that their business model should be capable to finance the assets providing the updates. Total I'm optimistic, networked software will not be the primary know-how utilized by mankind causing issues that had been addressed later. Steam engine use might result in boiler explosions however the "engineers" have been able to cut back this threat significantly over a number of a long time.



Posted Nov 7, 2015 10:29 UTC (Sat) by ms (subscriber, #41272) [Hyperlink]



The following is all guess work; I would be keen to know if others have evidence either a technique or one other on this: The individuals who learn to hack into these programs by way of 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 - indeed on the entire the place knowledge has been stolen in an effort to release and embarrass folks, it _seems_ as though these hacks are through much easier vectors. I.e. lesser expert hackers discover there is a whole load of low-hanging fruit which they'll get at. They are not being paid ahead of time for the info, so they flip to extortion instead. They don't cowl their tracks, and they'll typically be found and charged with criminal offences. So if your security meets a certain fundamental level of proficiency and/or your company isn't doing anything that places it near the top of "corporations we'd like to embarrass" (I believe the latter is way more practical at holding techniques "protected" than the previous), then the hackers that get into your system are prone to be expert, paid, and probably not going to do much damage - they're stealing information for a competitor / state. So that doesn't bother your backside line - no less than not in a way which your shareholders will be aware of. So why fund safety?



Posted Nov 7, 2015 17:02 UTC (Sat) by citypw (visitor, #82661) [Hyperlink]



Alternatively, some effective mitigation in kernel level would be very helpful to crush cybercriminal/skiddie's strive. If one in all your customer running a future buying and selling platform exposes some open API to their shoppers, and if the server has some reminiscence corruption bugs might be exploited remotely. Then you understand there are known assault methods( equivalent to offset2lib) may help the attacker make the weaponized exploit a lot easier. Will you clarify 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 the most business uses, more security mitigation throughout the software won't cost you more budget. You'll still need to do the regression check for every upgrade.



Posted Nov 12, 2015 16:14 UTC (Thu) by andreashappe (subscriber, #4810) [Hyperlink]



Understand that I concentrate on external net-based mostly penetration-assessments and that in-home assessments (local LAN) will probably yield totally different outcomes.



Posted Nov 7, 2015 20:33 UTC (Sat) by mattdm (subscriber, #18) [Hyperlink]



I keep reading this headline as "a new Minecraft moment", and thinking that perhaps they've decided to follow up the .Internet thing by open-sourcing Minecraft. Oh effectively. I mean, security 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_every (subscriber, #28989) [Link]



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) [Hyperlink]



(Oh, and I used to be additionally still questioning how Minecraft had taught us about Linux efficiency - so because of the other comment thread that identified the 'd', not 'e'.)



Posted Nov 9, 2015 11:31 UTC (Mon) by ortalo (visitor, #4654) [Hyperlink]



I would identical to so as to add that in my view, there is a general problem with the economics of pc safety, which is very visible at present. Two issues even perhaps. First, the cash spent on laptop safety is commonly diverted towards the so-called security "circus": quick, straightforward options which are primarily selected simply with the intention to "do something" and get higher press. It took me a long time - perhaps many years - to claim that no security mechanism in any respect is healthier than a nasty mechanism. However now I firmly imagine on this attitude and would rather take the chance knowingly (supplied that I can save cash/useful resource for myself) than take a bad approach at solving it (and haven't any money/resource left once i realize I ought to have achieved one thing else). And that i discover there are various unhealthy or incomplete approaches presently obtainable in the computer safety area. These spilling our uncommon money/assets on ready-made useless instruments ought to get the dangerous press they deserve. And, we actually must enlighten the press on that because it is not really easy to appreciate the efficiency of safety mechanisms (which, by definition, ought to prevent issues from happening). Second, and that could be more moderen and more worrying. The circulate of cash/resource is oriented in the path of attack tools and vulnerabilities discovery much greater than within the route of recent safety mechanisms. This is especially worrying as cyber "defense" initiatives look increasingly more like the usual idustrial projects geared toward producing weapons or intelligence techniques. Furthermore, unhealthy useless weapons, because they are only working against our very susceptible present systems; and unhealthy intelligence systems as even basic school-stage encryption scares them down to useless. However, all the ressources are for these grownup teenagers playing the white hat hackers with not-so-tough programming methods or community monitoring or WWI-stage cryptanalysis. And now also for the cyberwarriors and cyberspies that have but to show their usefulness totally (especially for peace safety...). Personnally, I might fortunately go away them all of the hype; however I am going to forcefully claim that they haven't any proper whatsoever on any of the budget allocation choices. Solely these working on protection should. And yep, it means we should always decide the place to place there sources. We have now to say the exclusive lock for ourselves this time. (and I suppose the PaXteam could be amongst the first to benefit from such a change). Whereas fascinated about it, I would not even leave white-hat or cyber-guys any hype in the end. That's more publicity than they deserve. I crave for the day I'll read in the newspaper that: "Another of these ill suggested debutant programmer hooligans that pretend to be cyber-pirates/warriors modified some well-known virus program code exploiting a programmer mistake and managed nevertheless to deliver a kind of unfinished and bad high quality programs, X, that we are all obliged to use to its knees, annoying tens of millions of standard customers with his unfortunate cyber-vandalism. All the protection specialists unanimously suggest that, once again, the finances of the cyber-command be retargetted, or not less than leveled-off, in order to convey extra safety engineer positions in the educational area or civilian business. And that X's producer, XY Inc., be liable for the potential losses if proved to be unprofessional in this affair."



Hmmm - cyber-hooligans - I like the label. Although it does not apply well to the battlefield-oriented variant.



Posted Nov 9, 2015 14:28 UTC (Mon) by drag (guest, #31333) [Hyperlink]



The state of 'software program security industry' is a f-ng disaster. Failure of the highest order. There is very large amounts of money that goes into 'cyber security', however it is normally spent on authorities compliance and audit efforts. This implies as an alternative of actually placing effort into correcting points and mitigating future problems, nearly all of the hassle goes into taking present functions and making them conform to committee-driven tips with the minimal quantity of effort and changes. Some degree of regulation and standardization is totally wanted, but lay persons are clueless and are utterly unable to discern the difference between anyone who has helpful expertise versus some company that has spent tens of millions on slick marketing and 'native advertising' on large web sites and pc magazines. The folks with the cash sadly solely have their own judgment to rely on when buying into 'cyber security'. > These spilling our rare money/sources on prepared-made useless instruments ought to get the dangerous press they deserve. There is no such thing as a such thing as 'our uncommon money/assets'. You might have your money, I've mine. Cash being spent by some corporation like Redhat is their cash. Cash being spent by governments is the federal government's money. (you, actually, have far more management in how Walmart spends it is money then over what your authorities does with their's) > This is very worrying as cyber "defense" initiatives look an increasing number of like the usual idustrial initiatives aimed toward producing weapons or intelligence systems. Moreover, dangerous useless weapons, as a result of they are solely working towards our very susceptible current methods; and unhealthy intelligence methods as even primary college-stage encryption scares them right down to ineffective. Having safe software program with robust encryption mechanisms within the hands of the public runs counter to the interests of most major governments. Governments, like another for-revenue group, are primarily eager about self-preservation. Money spent on drone initiatives or banking auditing/oversight regulation compliance is Far more worthwhile to them then trying to assist the public have a secure mechanism for making telephone calls. Particularly when these safe mechanisms interfere with knowledge collection efforts. Sadly you/I/us can't rely on some magical benefactor with deep pockets to sweep in and make Linux higher. It's simply not going to happen. Corporations like Redhat have been massively useful to spending sources to make Linux kernel more succesful.. nevertheless they're driven by a the necessity to show a profit, which implies they need to cater directly to the the kind of requirements established by their buyer base. Clients for EL are typically way more targeted on decreasing prices related to administration and software program growth then security at the low-level OS. Enterprise Linux prospects are likely to depend on bodily, human coverage, and network security to guard their 'comfortable' interiors from being exposed to exterior threats.. assuming (rightly) that there's little or no they can do to actually harden their techniques. In truth when the selection comes between safety vs comfort I am certain that almost all customers will happily defeat or strip out any safety mechanisms introduced into Linux. On high of that when most Enterprise software is extremely unhealthy. A lot in order that 10 hours spent on bettering a web entrance-end will yield extra actual-world security benefits then a a thousand hours spent on Linux kernel bugs for many companies. Even for 'regular' Linux customers a safety bug in their Firefox's NAPI flash plugin is far more devastating and poses a massively increased risk then a obscure Linux kernel buffer over circulate problem. It's simply probably not important for attackers to get 'root' to get access to the important information... typically all of which is contained in a single consumer account. In the end it is up to people such as you and myself to place the hassle and money into bettering Linux security. For each ourselves and different folks.



Posted Nov 10, 2015 11:05 UTC (Tue) by ortalo (guest, #4654) [Link]



Spilling has always been the case, but now, to me and in pc safety, most of the cash seems spilled due to bad faith. And this is usually your money or mine: either tax-fueled governemental assets or company prices which might be instantly reimputed on the costs of products/software program we're told we're *obliged* to purchase. (Have a look at corporate firewalls, house alarms or antivirus software advertising and marketing discourse.) I think it's time to level out that there are several "malicious malefactors" round and that there is an actual need to determine and sanction them and confiscate the sources they've in some way managed to monopolize. And that i do *not* think Linus is amongst such culprits by the way. However I feel he may be amongst the ones hiding their heads in the sand in regards to the aforementioned evil actors, while he most likely has extra leverage to counteract them or oblige them to reveal themselves than many of us. I find that to be of brown-paper-bag stage (though head-in-the-sand is one way or the other a new interpretation). In the end, I believe you are right to say that presently it is only as much as us individuals to try honestly to do something to improve Linux or pc safety. However I nonetheless assume that I'm right to say that this is not normal; particularly whereas some very serious individuals get very severe salaries to distribute randomly some tough to judge budgets. [1] A paradoxical scenario when you think about it: in a website the place you're first and foremost preoccupied by malicious people everyone ought to have factual, transparent and sincere habits as the first precedence of their mind.



Posted Nov 9, 2015 15:Forty seven UTC (Mon) by MarcB (subscriber, #101804) [Hyperlink]



It even has a pleasant, seven line Primary-pseudo-code that describes the current state of affairs and clearly reveals that we are caught in an infinite loop. It doesn't answer the big query, although: How to write higher software. The sad factor is, that that is from 2005 and all of the issues that were obviously silly ideas 10 years ago have proliferated even more.



Posted Nov 10, 2015 11:20 UTC (Tue) by ortalo (visitor, #4654) [Hyperlink]



Note IMHO, we must always investigate further why these dumb issues proliferate and get a lot help. If it is solely human psychology, well, let's fight it: e.g. Mozilla has proven us that they can do fantastic issues given the correct message. If we are facing lively individuals exploiting public credulity: let's determine and combat them. But, extra importantly, let's capitalize on this knowledge and safe *our* methods, to showcase at a minimum (and extra later on of course). Your reference conclusion is particularly nice to me. "challenge [...] the typical knowledge and the status quo": that job I'd happily settle for.



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 objects it rants about, which it is suggesting at some level, can be as unhealthy or worse, and indicative of the worst type of safety considering that has put a lot of people off. Alternatively, it's just a rant that provides little of value. Personally, I think there is no magic bullet. Safety is and all the time has been, in human historical past, an arms race between defenders and attackers, and one that is inherently a trade-off between usability, risks and costs. If there are mistakes being made, it is that we should probably spend more sources on defences that might block total courses of assaults. E.g., why is the GRSec kernel hardening stuff so exhausting to apply to regular distros (e.g. there is no reliable supply of a GRSec kernel for Fedora or RHEL, is there?). Why does your complete Linux kernel run in a single safety context? Why are we nonetheless writing lots of software in C/C++, usually with none fundamental security-checking abstractions (e.g. fundamental bounds-checking layers in between I/O and parsing layers, say)? Can hardware do extra to offer security with speed? Little doubt there are a lot of people engaged on "block lessons of assaults" stuff, the query is, why aren't there more sources directed there?



Posted Nov 10, 2015 2:06 UTC (Tue) by timrichardson (subscriber, #72836) [Hyperlink]



>There are loads of explanation why Linux lags behind in defensive safety applied sciences, however one in every of the important thing ones is that the companies making a living on Linux haven't prioritized the event and integration of these applied sciences. This seems like a reason which is absolutely value exploring. Why is it so? I feel it isn't obvious why this does not get some extra consideration. Is it doable that the individuals with the money are right not to extra highly prioritise this? Afterall, what interest have they got in an unsecure, exploitable kernel? The place there's frequent cause, linux growth will get resourced. It has been this manner for a few years. If filesystems qualify for common interest, surely safety does. So there does not appear to be any apparent purpose why this situation does not get extra mainstream consideration, except that it really already gets sufficient. You may say that catastrophe has not struck but, that the iceberg has not been hit. But it surely seems to be that the linux development course of just isn't overly reactive elsewhere.



Posted Nov 10, 2015 15:53 UTC (Tue) by raven667 (subscriber, #5198) [Hyperlink]



That's an attention-grabbing question, certainly that's what they really consider regardless of what they publicly say about their commitment to security technologies. What is the really demonstrated downside for Kernel developers and the organizations that pay them, so far as I can inform there is not ample consequence for the lack of Security to drive extra funding, so we're left begging and cajoling unconvincingly.



Posted Nov 12, 2015 14:37 UTC (Thu) by ortalo (visitor, #4654) [Link]



The important thing problem with this domain is it pertains to malicious faults. So, when consequences manifest themselves, it is simply too late to act. And if the current dedication to an absence of voluntary technique persists, we're going to oscillate between phases of relaxed inconscience and anxious paranoia. Admittedly, kernel developpers appear pretty resistant to paranoia. That is an effective factor. But I am waiting for the times the place armed land-drones patrol US streets within the neighborhood of their children colleges for them to find the feeling. They aren't so distants the days when innocent lives will unconsciouly depend on the security of (linux-primarily based) laptop programs; beneath water, that's already the case if I remember correctly my last dive, in addition to in a number of recent cars according to some reports.



Posted Nov 12, 2015 14:32 UTC (Thu) by MarcB (subscriber, #101804) [Link]



Traditional hosting firms that use Linux as an exposed front-finish system are retreating from development while HPC, cellular and "generic enterprise", i.E. RHEL/SLES, are pushing the kernel of their directions. This is admittedly not that surprising: For internet hosting wants the kernel has been "completed" for quite a while now. In addition to help for present hardware there just isn't a lot use for newer kernels. Linux 3.2, and even older, works simply positive. Internet hosting doesn't want scalability to lots of or hundreds of CPU cores (one makes use of commodity hardware), complex instrumentation like perf or tracing (systems are locked down as much as attainable) or advanced energy-administration (if the system doesn't have fixed high load, it isn't making enough cash). So why should hosting firms still make sturdy investments in kernel growth? Even when they'd one thing to contribute, the hurdles for contribution have turn out to be increased and higher. For his or her safety wants, hosting firms already use Grsecurity. I have no numbers, but some experience means that Grsecurity is basically a hard and fast requirement for shared internet hosting. Alternatively, kernel security is almost irrelevant on nodes of an excellent laptop or on a system working giant enterprise databases which can be wrapped in layers of middle-ware. And cellular distributors simply don't 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) [Hyperlink]



Posted Nov 11, 2015 22:38 UTC (Wed) by rickmoen (subscriber, #6943) [Hyperlink]



The assembled doubtless recall that in August 2011, kernel.org was root compromised. I am sure the system's arduous drives have been sent off for forensic examination, and we've all been ready patiently for the reply to crucial query: What was the compromise vector? From shortly after the compromise was found on August 28, 2011, proper by April 1st, 2013, kernel.org included this notice at the highest of the positioning News: 'Because of all to your persistence and understanding throughout our outage and please bear with us as we deliver up the totally different kernel.org methods over the following few weeks. We can be writing up a report on the incident sooner or later.' (Emphasis added.) That remark was removed (together with the remainder of the location Information) throughout a May 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 Project discovered sudden compromise of several of its servers in 2007, Wichert Akkerman wrote and posted a superb public report on exactly what happened. Likewise, the Apache Foundation likewise did the correct factor with good public autopsies of the 2010 Net site breaches. Arstechnica's Dan Goodin was still trying to follow up on the lack of an autopsy on the kernel.org meltdown -- in 2013. Two years in the past. He wrote: Linux developer and maintainer Greg Kroah-Hartman informed Ars that the investigation has but to be completed and gave no timetable for when a report is perhaps launched. [...] Kroah-Hartman additionally instructed Ars kernel.org techniques were rebuilt from scratch following the assault. Officials have developed new tools and procedures since then, but he declined to say what they're. "There shall be a report later this 12 months about site [sic] has been engineered, but don't quote me on when it is going to be released as I am not chargeable for it," he wrote. Who's accountable, then? Is anybody? Anybody? Bueller? Or is it a state secret, or what? Two years since Greg K-H stated there can be a report 'later this yr', and four years for the reason that meltdown, nothing but. How about some information? Rick Moen [email protected]



Posted Nov 12, 2015 14:19 UTC (Thu) by ortalo (visitor, #4654) [Hyperlink]



Much less severely, observe that if even the Linux mafia doesn't know, it must be the venusians; they are notoriously stealth of their invasions.



Posted Nov 14, 2015 12:46 UTC (Sat) by error27 (subscriber, #8346) [Link]



I do know the kernel.org admins have given talks about a few of the brand new protections that have been put into place. There aren't any more shell logins, instead all the pieces makes use of gitolite. The completely different companies are on totally different hosts. There are extra kernel.org staff now. Persons are using two issue identification. Some other 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 used to be one way or the other unclear: That was mentioned to have been the trail of entry to the machine (and that i can readily consider that, as it was also the precise path to entry into shells.sourceforge.internet, a few years prior, around 2002, and into many different shared Internet hosts for many years). However that is not what's of main curiosity, and is not what the forensic examine long promised would primarily concern: How did intruders escalate to root. To quote kernel.org administrator within the August 2011 Dan Goodin article you cited: 'How they managed to exploit that to root entry is presently unknown and is being investigated'. Okay, of us, you have now had four years of investigation. What was the path of escalation to root? (Additionally, different details that might logically be coated by a forensic research, reminiscent of: Whose key was stolen? Who stole the important thing?) That is the type of autopsy was promised prominently on the front web page of kernel.org, to reporters, and elsewhere for a long time (after which summarily removed as a promise from the front page of kernel.org, without comment, along with the rest of the positioning Information section, and apparently dropped). It still can be applicable to know and share that knowledge. Particularly the datum of whether the trail 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:Forty two UTC (Solar) by rickmoen (subscriber, #6943) [Hyperlink]



I've completed a better evaluation of revelations that came out soon after the break-in, and suppose I've found the answer, via a leaked copy of kernel.org chief sysadmin John H. 'Warthog9' Hawley's Aug. 29, 2011 e-mail to shell users (two days before the public was informed), plus Aug. 31st feedback to The Register's Dan Goodin by 'two security researchers who have been briefed on the breach': Root escalation was by way of exploit of a Linux kernel safety gap: Per the 2 security researchers, it was one each extraordinarily embarrassing (large-open access to /dev/mem contents including the working kernel's image in RAM, in 2.6 kernels of that day) and recognized-exploitable for the prior six years by canned 'sploits, one in every of which (Phalanx) was run by some script kiddie after entry utilizing stolen dev credentials. Different tidbits: - Site admins left the basis-compromised Internet servers working with all services nonetheless lit up, for multiple days. - Site admins and Linux Foundation sat on the knowledge and failed to inform the public for those self same a number of days. - Site admins and Linux Foundation have by no means revealed whether or not trojaned Linux source tarballs were posted within the http/ftp tree for the 19+ days earlier than they took the positioning down. (Yes, git checkout was high quality, but what concerning the thousands of tarball downloads?) - After promising a report for several years and then quietly eradicating that promise from the front web page of kernel.org, Linux Foundation now stonewalls press queries.I posted my best try at reconstructing the story, absent a real report from insiders, to SVLUG's predominant mailing listing yesterday. (Necessarily, there are surmises. If the folks with the information have been more forthcoming, we would know what occurred for sure.) I do should wonder: If there's one other embarrassing screwup, will we even be instructed about it at all? Rick Moen [email protected]



Posted Nov 22, 2015 14:25 UTC (Sun) by spender (visitor, #23067) [Link]



Also, it's preferable to use reside reminiscence acquisition prior to powering off the system, otherwise you lose out on reminiscence-resident artifacts that you may perform forensics on. -Brad



How concerning the long overdue autopsy on the August 2011 kernel.org compromise?



Posted Nov 22, 2015 16:28 UTC (Sun) by rickmoen (subscriber, #6943) [Link]



Thanks on your comments, Brad. I'd been relying on Dan Goodin's claim of Phalanx being what was used to realize root, within the bit where he cited 'two safety researchers who had been briefed on the breach' to that effect. Goodin also elaborated: 'Fellow safety researcher Dan Rosenberg mentioned 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 instrument, and i famous that oddity in my posting to SVLUG. That having been stated, yeah, the Phalanx README does not specifically declare this, so then possibly Goodin and his a number of 'safety researcher' sources blew that detail, and no person but kernel.org insiders but knows the escalation path used to achieve root. Additionally, it is preferable to use live reminiscence acquisition prior to powering off the system, otherwise you lose out on reminiscence-resident artifacts that you would be able to carry out forensics on. Arguable, but a tradeoff; you may poke the compromised dwell system for state data, however with the downside of leaving your system operating under hostile management. I was always taught that, on steadiness, it's better to drag power to finish the intrusion. Rick Moen [email protected]



Posted Nov 20, 2015 8:23 UTC (Fri) by toyotabedzrock (guest, #88005) [Hyperlink]



Posted Nov 20, 2015 9:31 UTC (Fri) by gioele (subscriber, #61675) [Link]



With "one thing" you imply those that produce these closed source drivers, right? If the "client product companies" simply stuck to utilizing components with mainlined open source drivers, then updating their products could be much simpler.



A new Mindcraft second?



Posted Nov 20, 2015 11:29 UTC (Fri) by Wol (subscriber, #4433) [Hyperlink]



They've ring 0 privilege, can entry protected reminiscence straight, and cannot be audited. Trick a kernel into operating a compromised module and it is recreation over. Even tickle a bug in a "good" module, and it's probably recreation over - in this case quite actually as such modules are typically video drivers optimised for games ...