A Brand New Mindcraft Moment

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

1. this WP article was the fifth in a sequence of articles following the safety of the internet from its beginnings to related subjects of in the present day. discussing the security of linux (or lack thereof) fits nicely in there. it was additionally a well-researched article with over two months of analysis and interviews, something you can't quite claim your self for your latest pieces on the subject. you do not just like the facts? then say so. and even better, do one thing constructive about them like Kees and others have been attempting. however silly comparisons to outdated crap like the Mindcraft studies and fueling conspiracies do not precisely assist your case. 2. "We do a reasonable job of finding and fixing bugs." let's begin right here. is this assertion primarily based on wishful thinking or chilly onerous information you are going to share in your response? in keeping with Kees, the lifetime of security bugs is measured in years. that is greater than the lifetime of many devices people purchase and use and ditch in that interval. 3. "Problems, whether or not they are security-associated or not, are patched quickly," some are, some aren't: let's not forget the latest NMI fixes that took over 2 months to trickle down to stable kernels and we also have a user 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 primary one Kees is making an attempt to upstream, imagine the shitstorm if bugreports shall be treated with this attitude, let's hope btrfs guys are an exception, not the rule). anyway, two examples aren't statistics, so once once more, do you have numbers or is it all wishful thinking? (it is partly a trick question as a result of you'll also have to clarify how something gets to be decided to be security related which as everyone knows is a messy business within the linux world) 4. "and the stable-replace mechanism makes these patches accessible to kernel users." besides when it doesn't. and sure, i've numbers: grsec carries 200+ backported patches in our 3.14 stable tree. 5. "In particular, the few builders who are working on this space have never made a serious try to get that work built-in upstream." you don't must be shy about naming us, after all you probably did so elsewhere already. and we also explained the the explanation why we haven't pursued upstreaming our code: https://lwn.internet/Articles/538600/ . since i do not anticipate you and your readers to learn any of it, here is the tl;dr: if you'd like 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 will get in too. i personally find it fairly hypocritic that properly paid kernel builders are bitching about our unwillingness and inability to serve them our code on a silver platter totally free. and earlier than someone brings up the CII, go examine their mail archives, after some initial exploratory discussions i explicitly asked them about supporting this long drawn out upstreaming work and received no answers.

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

Money (aha) quote : > I propose you spend none of your free time on this. Zero. I propose you get paid to do this. And properly. No person count on you to serve your code on a silver platter free of charge. The Linux basis and large companies using Linux (Google, Pink Hat, Oracle, Samsung, etc.) should pay security specialists such as you to upstream your patchs.

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

I would just prefer to level out that the way in which you phrased this makes your remark a tone argument[1][2]; you've got (in all probability unintentionally) dismissed the entire guardian's arguments by pointing at its presentation. The tone of PAXTeam's remark displays the frustration constructed up through the years with the best way things work which I think ought to be taken at face value, empathized with, and understood slightly than merely 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) [Hyperlink]

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

why, is upstream recognized for its primary civility and decency? have you even learn the WP put up beneath dialogue, by no means mind past 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) [Hyperlink]

No Argument

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

Please do not; it does not belong there both, and it particularly doesn't want a cheering part because the tech press (LWN generally excepted) tends to supply.

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

Ok, but I used to be considering 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 (visitor, #24616) [Link]

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

Why must you assume solely cash will fix this downside? Yes, I agree more sources needs to be spent on fixing Linux kernel safety points, however don't assume someone giving an organization (ahem, PAXTeam) money is the only resolution. (Not imply to impugn PAXTeam's security efforts.)

The Linux development neighborhood may have had the wool pulled over its collective eyes with respect to safety issues (either real or perceived), but simply throwing cash at the issue will not fix this.

And yes, I do realize the industrial Linux distros do lots (most?) of the kernel growth lately, and that implies indirect financial transactions, but it's much more involved than just that.

Posted Nov 7, 2015 0:36 UTC (Sat) by PaXTeam (visitor, #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) [Hyperlink]

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

I feel you positively agree with the gist of Jon's argument... not sufficient focus has been given to safety 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, however sure, this side of the coin is effectively represented by us and others who were interviewed. the same way Linus is a good consultant of, nicely, his own pet challenge referred to as linux. > And if Jon had only talked to you, his would have been too. given that i am the writer of PaX (part of grsec) yes, talking to me about grsec issues makes it the most effective methods to research it. but when you know of another person, be my guest and title them, i am fairly certain the just lately formed kernel self-protection of us would be dying to engage them (or not, i don't suppose there is a sucker on the market with thousands of hours of free time on their hand). > [...]it additionally contained fairly just a few of groan-worthy statements. nothing is ideal however contemplating the audience of the WP, this is one of the higher journalistic items on the topic, no matter how you and others do not like the sorry state of linux safety uncovered in there. in order for you to debate more technical particulars, nothing stops you from speaking to us ;). speaking of your complaints about journalistic qualities, since a previous LWN article saw it match to include several typical dismissive claims by Linus about the quality of unspecified grsec options with no evidence of what expertise he had with the code and the way latest 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 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) [Hyperlink]

Posted Nov 8, 2015 13:06 UTC (Solar) by k3ninho (subscriber, #50375) [Link]

Proper now we have obtained builders from large names saying that doing all that the Linux ecosystem does *safely* is an itch that they've. Sadly, the surrounding cultural perspective of builders is to hit purposeful goals, and occasionally performance targets. Security goals are often ignored. Ideally, the culture would shift so that we make it tough to observe insecure habits, patterns or paradigms -- that could 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 because 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 end-person (say, Intel, Google, Fb or Amazon) delivers stuff with notes like 'here's a set of enhancements, we're already using them to unravel this type of downside, this is how every thing will stay working because $proof, note carefully that you're staring down the barrels of a fork as a result of your tree is now evolutionarily disadvantaged'. It's a recreation and will be gamed; I'd favor that the group shepherds users to follow the pattern of declaring drawback + solution + purposeful take a look at proof + efficiency check proof + security check evidence. K3n.

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

And about that fork barrel: I'd argue it's the other means round. Google forked and lost already.

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

Posted Nov 23, 2015 6:33 UTC (Mon) by jospoortvliet (guest, #33164) [Link]

Posted Nov 7, 2015 3:20 UTC (Sat) by corbet (editor, #1) [Hyperlink]

So I need to confess to a certain quantity of confusion. I may swear that the article I wrote mentioned precisely that, but you have put a fair amount 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 assume you and Nick Krause share opposite sides of the identical coin. Programming ability and basic 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 am fallacious, but a hostile perspective is not going to help anyone get paid. It's a time like this the place something you appear to be an "knowledgeable" at and there is a demand for that expertise the place you display cooperation and willingness to participate because it is an opportunity. I am comparatively shocked that someone doesn't get that, however I am older and have seen just a few of these opportunities in my career and exploited the hell out of them. You solely get a couple of of these in the average profession, and handful at the most. Generally you need to put money into proving your expertise, and this is one of those moments. It seems the Kernel community may lastly take this safety lesson to heart and embrace it, as stated within the article as a "mindcraft second". This is an opportunity for developers that may want to work on Linux safety. Some will exploit the chance and others will thumb their noses at it. Ultimately those builders that exploit the opportunity will prosper from it. I really feel old even having to write that.

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

Maybe there is a chicken and egg problem here, but when looking for out and funding people to get code upstream, it helps to pick out folks and groups with a historical past of with the ability to get code upstream. It is completely cheap to want understanding of tree, offering the ability to develop spectacular and critical safety advances unconstrained by upstream requirements. That's work someone may also wish to fund, if that meets their needs.

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

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

You make this argument (implying you do research and Josh doesn't) after which fail to help it by any cite. It could be far more convincing for those who quit on the Onus probandi rhetorical fallacy and really cite information. > case in point, it was *them* who suggested that they would not fund out-of-tree work but would consider funding upstreaming work, except when pressed for the main points, all i obtained was silence. For those following along at dwelling, this is the relevant set of threads: http://lists.coreinfrastructure.org/pipermail/cii-talk about... A quick precis is that they informed you your venture was unhealthy because the code was by no means going upstream. You instructed them it was because of kernel builders 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 instructed you that submitting a proposal might be the smartest thing to do. At that time you went silent, not vice versa as you indicate above. > clearly i won't spend time to write down up a begging proposal just to be advised that 'no sorry, we don't fund multi-year initiatives at all'. that is something that one needs to be told prematurely (or heck, be part of some public guidelines in order that others will know the principles too). You seem to have a fatally flawed grasp of how public funding works. If you don't inform folks why you need the cash and how you may spend it, they're unlikely to disburse. Saying I'm brilliant and I do know the issue now hand over the money would not even work for many Teachers who've a strong 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 examine the kernel git logs (minus the stuff that was not correctly credited)? jejb@jarvis> git log|grep -i 'Author: pax.*team'|wc -l 1 Stellar, I have to say. And before you gentle off on these who've misappropriated your credit score, please remember that getting code upstream on behalf of reluctant or incapable actors is a vastly beneficial and time consuming talent and one in all the reasons teams like Linaro exist and are properly funded. If more of your stuff does go upstream, it will likely be because of the not inconsiderable efforts of different folks in this space. You now have a enterprise model promoting non-upstream security patches to clients. There's nothing incorrect with that, it's a reasonably ordinary first stage enterprise mannequin, but it does rather depend upon patches not being upstream in the first place, calling into query the earnestness of your attempt to place them there. Now this is some free advice in my field, which is aiding firms align their businesses in open supply: The selling out of tree patch route is at all times an eventual failure, notably with the kernel, as a result of if the performance is that useful, it gets upstreamed or reinvented in your despite, leaving you with nothing to promote. In case your business plan B is selling expertise, you've gotten to keep in mind that it's going to be a hard promote when you've no out of tree differentiator left and git historical past denies that you simply had anything to do with the in-tree patches. In truth "crazy safety individual" will develop into a self fulfilling prophecy. The advice? it was apparent to everyone else who read this, however for you, it's do the upstreaming your self earlier than it will get performed for you. That approach you have a legit historical declare to Plan B and you might actually have a Plan A promoting a rollup of upstream monitor patches built-in and delivered before the distributions get around to it. Even your software to the CII couldn't be dismissed because your work wasn't going wherever. Your various is to proceed playing the position of Cassandra and probably suffer her eventual destiny.

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

> Second, for the potentially viable pieces this can be a multi-year > full time job. Is the CII willing to fund tasks at that degree? If not > all of us would end up with a lot of unfinished and partially broken features. please present me the answer to that query. with no definitive 'yes' there is no level in submitting a proposal as a result of this is the time frame that for my part the job will take and any proposal with that requirement can be shot down immediately and be a waste of my time. and i stand by my claim that such simple primary necessities needs to be public info. > Stellar, I have to say. "Lies, damned lies, and statistics". you notice there's more than one option to get code into the kernel? how about you utilize your git-fu to seek out all of the bugreports/instructed fixes that went in attributable to us? as for particularly me, Greg explicitly banned me from future contributions by way of af45f32d25cc1 so it's no wonder i do not ship patches immediately in (and that one commit you found that went in regardless of stated ban is actually a really unhealthy instance as a result of additionally it is the one that Linus censored for no good motive and made me decide to never ship safety fixes upstream till that observe modifications). > You now have a business mannequin promoting non-upstream safety patches to prospects. now? we've had paid sponsorship for our various stable kernel collection for 7 years. i would not name it a business mannequin though because it hasn't paid anybody's bills. > [...]calling into question the earnestness of your attempt to put them there. i have to be lacking one thing here but what try? i've never in my life tried to submit PaX upstream (for all the explanations discussed already). the CII mails have been exploratory to see how serious that whole group is about actually securing core infrastructure. in a sense i've acquired my solutions, there's nothing extra to the story. as for your free advice, let me reciprocate: complex issues don't clear up themselves. code fixing advanced problems does not write itself. folks writing code fixing advanced issues are few and much between that you will see out briefly order. such individuals (domain experts) don't work for free with few exceptions like ourselves. biting the hand that feeds you will solely finish you up in hunger. PS: since you are so certain about kernel builders' skill to reimplement our code, maybe have a look at what parallel options i still maintain in PaX despite vanilla having a 'totally-not-reinvented-here' implementation and take a look at to grasp the rationale. or simply look at all the CVEs that affected say vanilla's ASLR but didn't have an effect on mine. PPS: Cassandra by no means wrote code, i do. criticizing the sorry state of kernel security is a side project when i am bored or just waiting for the subsequent kernel to compile (i wish LTO was more environment friendly).

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

In different phrases, you tried to define their course of for them ... I can not think why that would not work. > "Lies, damned lies, and statistics". The problem with advert hominem assaults is that they are singularly ineffective in opposition to a transparently factual argument. I posted a one line command anybody could run to get the number of patches you've got authored in the kernel. Why don't you post an equal that provides figures you like extra? > i've by no means in my life tried to submit PaX upstream (for all the explanations mentioned already). So the grasp plan is to display your expertise by the number of patches you have not submitted? nice plan, world domination beckons, sorry that one got away from you, however I'm positive you won't let it occur again.

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

what? since when does asking a query define something? isn't that how we discover out what someone else thinks? is not that what *they* have that webform (never thoughts the mailing lists) for as nicely? in other words you admit that my question was not actually answered . > The issue with advert hominem assaults is that they are singularly ineffective against a transparently factual argument. you didn't have an argument to begin with, that's what i defined in the part you rigorously selected not to quote. i am not right here to defend myself in opposition to your clearly idiotic attempts at proving no matter you are attempting to prove, as they are saying even in kernel circles, code speaks, bullshit walks. you possibly can take a look at mine and resolve what i can or cannot do (not that you have the knowledge to know most of it, mind you). that stated, there're clearly other extra capable people who have executed so and decided that my/our work was worth one thing else no person would have been feeding off of it for the previous 15 years and still counting. and as unimaginable as it might appear to you, life would not revolve around the vanilla kernel, not everybody's dying to get their code in there especially when it means to put up with such silly hostility on lkml that you just now also demonstrated here (it's ironic how you came to the defense of josh who specifically asked people to not convey that infamous lkml type here. good job there James.). as for world domination, there're some ways to achieve it and something tells me that you are clearly out of your league right here since PaX has already achieved that. you are running such code that implements PaX features as we communicate.

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 forgotten http://lwn.net/Articles/663591/): > as for getting code upstream, how about you check the kernel git logs (minus the stuff that was not correctly credited)? I take it, by the best way you have shifted ground within the earlier threads, that you simply want to withdraw that request?

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

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

Please provide one that is not unsuitable, or less improper. It's going to take much less time than you've already wasted here.

Posted Nov 8, 2015 22:Forty nine UTC (Sun) by PaXTeam (visitor, #24616) [Link]

anyway, since it is you guys who have a bee in your bonnet, let's check your stage of intelligence too. first work out my e mail address and undertaking identify then attempt to find the commits that say they arrive from there (it introduced again some reminiscences from 2004 already, how instances flies! i'm shocked i truly managed to perform this a lot with explicitly not making an attempt, think about if i did :). it is an incredibly complicated activity so by accomplishing it you will show yourself to be the top canine right here on lwn, no matter that is value ;).

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

*shrug* Or don't; you're only sullying your individual fame.

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 wouldn't 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 (Solar) by PaXTeam (visitor, #24616) [Hyperlink]

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

Ah. I believed my reminiscence wasn't failing me. Examine to PaXTeam's response to <http: lwn.net articles 663612 />. PaXTeam isn't averse to outright lying if it means he gets to seem proper, I see. Perhaps PaXTeam's memory is failing, and this apparent contradiction will not be a brazen lie, however on condition that the 2 posts have been made inside a day of each other I doubt it. (PaXTeam's whole unwillingness to assume good religion in others deserves some reflection. Yes, I *do* assume he's mendacity by implication here, and doing so when there's virtually nothing at stake. God alone knows what he's willing to stoop to when one thing *is* at stake. Gosh I'm wondering why his fixes aren't going upstream very fast.)

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

> and that one commit you found that went in despite stated ban also somebody's ban doesn't suggest it's going to translate into someone else's execution of that ban as it is clear from the commit in question. it's somewhat unhappy that it takes a safety repair to expose the fallacy of this coverage though. the remainder of your pithy ad hominem speaks for itself higher than i ever may ;).

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 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 conscious that it's entirely potential that everyone is fallacious here , right? That the kernel maintainers need to focus more on safety, that the article was biased, that you are irresponsible to decry the state of safety, and do nothing to help, and that your patchsets wouldn't help that much and are the improper route for the kernel? That just because the kernel maintainers aren't 100% proper it does not imply you're?

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

I think you've got him backwards there. Jon is comparing this to Mindcraft because he thinks that regardless of being unpalatable to plenty of the group, the article would possibly in truth comprise a variety 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 (guest, #23067) [Hyperlink]

"There are rumors of darkish forces that drove the article within the hopes of taking Linux down a notch. All of this might effectively be true" Simply as you criticized the article for mentioning Ashley Madison though in the very first sentence of the following paragraph it mentions it did not involve the Linux kernel, you cannot give credence to conspiracy theories without incurring the identical criticism (in different words, you can't play the Glenn Beck "I'm simply asking the questions right here!" whose "questions" gas the conspiracy theories of others). Very like mentioning Ashley Madison for instance for non-technical readers about the prevalence of Linux in the world, if you're criticizing the mention then mustn'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 security? As the PaX Crew pointed out within the preliminary put up, the motivations aren't laborious to know -- you made no point out in any respect about it being the 5th in a long-running collection following a pretty predictable time trajectory. No, we did not miss the overall analogy you were trying to make, we just don't suppose you'll be able to 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) [Hyperlink]

It's gracious of you not to blame your readers. I determine they're a good goal: there's that line about these ignorant of history being condemned to re-implement Unix -- as your readers are! :-) K3n. minecraft towny servers

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

Unfortunately, I do not perceive neither the "safety" folks (PaXTeam/spender), nor the mainstream kernel of us when it comes to their angle. I confess I've completely no technical capabilities on any of these matters, but if they all decided to work together, as an alternative of having countless and pointless flame wars and blame game exchanges, a variety of the stuff would have been performed already. And all of the whereas everybody concerned could have made another huge pile of money on the stuff. All of them appear to need to have a greater Linux kernel, so I've received no concept what the issue is. It appears that evidently no one is willing to yield any of their positions even a bit bit. Instead, both sides look like bent on attempting to insult their approach into forcing the opposite side to quit. Which, in fact, 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:44 UTC (Mon) by bojan (subscriber, #14302) [Hyperlink]

Take a scientific computational cluster with an "air gap", for example. You'd in all probability need most of the safety stuff turned off on it to realize maximum efficiency, because you'll be able to trust all customers. Now take a few billion mobile phones which may be difficult or gradual to patch. You'd probably wish to kill lots of the exploit courses there, if these devices can nonetheless run reasonably properly with most safety options turned on. So, it is not either/or. It's probably "it depends". But, if the stuff is not there for everybody to compile/use in the vanilla kernel, will probably be more difficult to make it part of on a regular basis selections for distributors and users.

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

How sad. This Dijkstra quote involves thoughts immediately: Software program engineering, after all, presents itself as one other worthy trigger, however that's eyewash: if you carefully read its literature and analyse what its devotees truly do, you'll discover that software program engineering has accepted as its charter "How one can program if you can't."

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

I assume that reality was too unpleasant to suit into Dijkstra's world view.

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

Indeed. And the attention-grabbing thing to me is that after I attain that time, assessments aren't enough - mannequin checking at a minimum and actually proofs are the only way forwards. I'm no safety professional, my discipline is all distributed programs. I perceive and have implemented Paxos and that i imagine I can explain how and why it works to anyone. But I'm at present doing some algorithms combining Paxos with a bunch of variations on VectorClocks and reasoning about causality and consensus. No take a look at is sufficient because there are infinite interleavings of occasions and my head simply could not cope with engaged on this both at the computer or on paper - I discovered I couldn't intuitively purpose about these things at all. So I began defining the properties and wished and step-by-step proving why every of them holds. With out my notes and proofs I am unable to even clarify to myself, not to mention anyone else, why this thing works. I find this both utterly apparent that this may occur and utterly terrifying - the maintenance cost of these algorithms is now an order of magnitude greater.

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

> Certainly. And the fascinating factor to me is that when I reach that point, exams will not be sufficient - mannequin checking at a minimal and actually proofs are the only manner forwards. Or are you simply utilizing the wrong maths? Hobbyhorse time once more :-) however to quote a fellow Pick developer ... "I typically walk into a SQL development shop and see that wall - you recognize, the one with the huge SQL schema that no-one fully understands on it - and surprise how I can simply hold the complete schema for a Pick database of the same or higher complexity in my head". However it's easy - by education I'm a Chemist, by interest a Physical Chemist (and by occupation an unemployed programmer :-). And when I am occupied with chemistry, I can ask myself "what is an atom fabricated from" and suppose about issues just like the strong nuclear drive. Subsequent stage up, how do atoms stick collectively and make molecules, and assume about the electroweak force and electron orbitals, and the way do chemical reactions happen. Then I believe about molecules stick together to make supplies, and think about metals, and/or Van de Waals, and stuff. Level is, you want to *layer* stuff, and have a look at issues, and say "how can I cut up components off into 'black boxes' so at anyone stage I can assume the other levels 'simply work'". For example, with Choose a FILE (desk to you) shops a category - a collection of equivalent objects. One object per Record (row). And, identical as relational, one attribute per Subject (column). Are you able to map your relational tables to reality so easily? :-) Going back THIRTY years, I remember a narrative about a guy who built little computer crabs, that might quite fortunately scuttle round in the surf zone. Because he didn't try to work out how to unravel all the issues directly - each of his (incredibly puny by at present's requirements - that is the 8080/Z80 period!) processors was set to just process a little bit little bit of the problem and there was no central "brain". Nevertheless it worked ... Perhaps it's best to simply write a bunch of small modules to unravel every particular person problem, and let ultimate reply "simply 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 example in Z notation we might construct schemas for the varied modifying ("delta") operations on the bottom schema, after which argue about preservation of formal invariants, properties of the outcome, and transitivity of the operation when chained with itself, or the preceding aggregate schema composed of schemas A by means of O (for which they've been already argued). The end result is a set of operations that, executed in arbitrary order, end in a set of properties holding for the result and outputs. Thus proving the formal design right (w/ caveat lectors concerning scope, correspondence with its implementation [though that may be proven as well], and skim-only ["xi"] operations).

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

Wanting by the historical past of computing (and possibly plenty of other fields too), you may most likely find that people "cannot see the wooden for the trees" extra typically that not. They dive into the element and completely miss the large image. (Drugs, and interest of mine, suffers from that too - I remember anyone speaking in regards to the guide desirous to amputate a gangrenous leg to save lots of someone's life - oblivious to the truth that the affected person was dying of cancer.) 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 of Harmful") FWIW, I believe that this speak is very related to why writing secure software program is so laborious.. -Dave.

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

Whereas we are spending hundreds of thousands at a multitude of security issues, kernel issues are usually not on our top-priority listing. Truthfully I remember solely once having discussing a kernel vulnerability. The results of the evaluation has been that each one our systems had been working kernels that have been older because the kernel that had the vulnerability. However "patch administration" is a real problem for us. Software should proceed to work if we set up security patches or update to new releases due to the end-of-life policy of a vendor. The revenue of the company is depending on the IT techniques working. So "not breaking user house" is a security characteristic for us, as a result of a breakage of 1 element of our a number of ten 1000's of Linux programs will cease the roll-out of the safety update. One other problem is embedded software program or firmware. As of late virtually all hardware systems include an operating system, typically some Linux model, offering a fill community stack embedded to assist distant administration. Recurrently these programs don't survive our obligatory safety scan, because vendors nonetheless did not update the embedded openssl. The real challenge is to supply a software stack that may be operated in the hostile atmosphere of the Internet maintaining 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 automated replace process, however vendors should understand that their business mannequin should be capable to finance the sources offering the updates. Total I'm optimistic, networked software program isn't the primary technology utilized by mankind inflicting issues that were addressed later. Steam engine use might end in boiler explosions however the "engineers" had been ready to reduce this risk significantly over a number of decades.

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

The following is all guess work; I would be eager to know if others have proof both a technique or another on this: The people who learn to hack into these techniques by kernel vulnerabilities know that they abilities they've learnt have a market. Thus they do not tend to hack in order to wreak havoc - indeed on the entire where data has been stolen in an effort to launch and embarrass people, it _seems_ as if these hacks are through much easier vectors. I.e. lesser expert hackers find there may be a whole load of low-hanging fruit which they can get at. They're not being paid forward of time for the info, so they turn to extortion as a substitute. They do not cover their tracks, and they will often be found and charged with criminal offences. So if your safety meets a sure fundamental level of proficiency and/or your company isn't doing something that places it near the top of "corporations we might prefer to embarrass" (I believe the latter is way more practical at maintaining programs "safe" than the previous), then the hackers that get into your system are prone to be expert, paid, and probably not going to do a lot harm - they're stealing data for a competitor / state. So that does not bother your backside line - at the least not in a manner which your shareholders will bear in mind of. So why fund safety?

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

On the other hand, some effective mitigation in kernel stage can be very helpful to crush cybercriminal/skiddie's attempt. If one in all your buyer operating a future buying and selling platform exposes some open API to their purchasers, and if the server has some memory corruption bugs will be exploited remotely. Then you understand there are known assault strategies( akin to offset2lib) can help the attacker make the weaponized exploit so much easier. Will you clarify the failosophy "A bug is bug" to your buyer and tell them it'd be ok? Btw, offset2lib is ineffective to PaX/Grsecurity's ASLR imp. To the most commercial makes use of, extra safety mitigation inside the software program won't price you extra price range. You may nonetheless have to do the regression take a look at for every upgrade.

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

Keep in mind that I concentrate on exterior web-based mostly penetration-assessments and that in-home tests (native LAN) will probably yield different results.

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

I keep reading this headline as "a new Minecraft second", and considering that possibly they've determined to observe up the .Net thing by open-sourcing Minecraft. Oh well. I mean, safety is nice too, I assume.

Posted Nov 7, 2015 22:24 UTC (Sat) by ssmith32 (subscriber, #72404) [Hyperlink]

Posted Nov 12, 2015 17:29 UTC (Thu) by smitty_one_every (subscriber, #28989) [Hyperlink]

Posted Nov 8, 2015 10:34 UTC (Solar) by jcm (subscriber, #18262) [Link]

Posted Nov 9, 2015 7:15 UTC (Mon) by jospoortvliet (visitor, #33164) [Link]

Posted Nov 9, 2015 15:53 UTC (Mon) by neiljerram (subscriber, #12005) [Hyperlink]

(Oh, and I used to be also nonetheless questioning how Minecraft had taught us about Linux efficiency - so because of the opposite remark thread that pointed out the 'd', not 'e'.)

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

I'd identical to to add that in my view, there is a normal downside with the economics of laptop security, which is very seen at present. Two issues even possibly. First, the cash spent on computer security is commonly diverted towards the so-known as safety "circus": quick, straightforward options which are primarily selected simply as a way to "do one thing" and get higher press. It took me a very long time - perhaps many years - to say that no safety mechanism in any respect is healthier than a bad mechanism. But now I firmly consider in this angle and would rather take the risk knowingly (offered that I can save cash/useful resource for myself) than take a bad strategy at solving it (and haven't any money/resource left once i understand I should have carried out one thing else). And i find there are numerous bad or incomplete approaches currently accessible in the computer security discipline. Those spilling our rare cash/assets on prepared-made useless tools should get the bad press they deserve. And, we certainly must enlighten the press on that as a result of it is not so easy to appreciate the effectivity of safety mechanisms (which, by definition, ought to forestall issues from taking place). Second, and that could be more recent and more worrying. The circulate of cash/resource is oriented within the course of attack tools and vulnerabilities discovery much greater than within the direction of recent safety mechanisms. This is particularly worrying as cyber "defense" initiatives look increasingly more like the standard idustrial initiatives geared toward producing weapons or intelligence systems. Moreover, dangerous useless weapons, because they are only working in opposition to our very weak present techniques; and unhealthy intelligence methods as even fundamental faculty-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-level cryptanalysis. And now additionally for the cyberwarriors and cyberspies which have but to show their usefulness fully (especially for peace safety...). Personnally, I'd fortunately depart them all the hype; but I will forcefully declare that they haven't any right in any respect on any of the funds allocation choices. Solely these engaged on protection ought to. And yep, it means we should always determine the place to place there sources. We've got to claim the exclusive lock for ourselves this time. (and I assume the PaXteam may very well be amongst the primary to profit from such a change). While fascinated about it, I wouldn't even go away white-hat or cyber-guys any hype in the end. That's extra publicity than they deserve. I crave for the day I'll read within the newspaper that: "One other of these ailing 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 deliver one of those unfinished and unhealthy high quality applications, X, that we are all obliged to use to its knees, annoying thousands and thousands of standard customers with his unfortunate cyber-vandalism. All the safety specialists unanimously recommend that, as soon as once more, the funds of the cyber-command be retargetted, or at the very least leveled-off, so as to convey more security engineer positions in the academic domain 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. Though it doesn't apply properly to the battlefield-oriented variant.

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

The state of 'software security business' is a f-ng catastrophe. Failure of the very best order. There is very large amounts of cash that goes into 'cyber security', however it is usually spent on authorities compliance and audit efforts. This means as a substitute of actually placing effort into correcting issues and mitigating future issues, nearly all of the effort goes into taking present applications and making them conform to committee-pushed pointers with the minimal amount of effort and adjustments. Some stage of regulation and standardization is absolutely wanted, however lay people are clueless and are utterly unable to discern the difference between any person who has useful experience versus some company that has spent hundreds of thousands on slick advertising and marketing and 'native advertising' on large web sites and laptop magazines. The people with the cash unfortunately only have their own judgment to depend on when shopping for into 'cyber security'. > These spilling our rare money/resources on ready-made ineffective instruments should get the bad press they deserve. There is no such factor as 'our rare money/sources'. You will have your money, I've mine. Money being spent by some corporation like Redhat is their money. Money being spent by governments is the federal government's cash. (you, actually, have much more management in how Walmart spends it's money then over what your authorities does with their's) > This is particularly worrying as cyber "protection" initiatives look increasingly more like the standard idustrial tasks aimed toward producing weapons or intelligence techniques. Furthermore, unhealthy useless weapons, as a result of they're solely working against our very weak current methods; and dangerous intelligence systems as even basic school-degree encryption scares them down to useless. Having safe software program with sturdy encryption mechanisms within the palms of the public runs counter to the pursuits of most main governments. Governments, like any other for-profit organization, are primarily considering self-preservation. Money spent on drone initiatives or banking auditing/oversight regulation compliance is Way more valuable to them then trying to assist the general public have a secure mechanism for making phone calls. Particularly when these safe mechanisms interfere with information collection efforts. Sadly you/I/us cannot depend on some magical benefactor with deep pockets to sweep in and make Linux higher. It is simply not going to happen. Firms like Redhat have been massively useful to spending sources to make Linux kernel more capable.. nevertheless they are driven by a the necessity to show a revenue, which suggests they should cater on to the the form of necessities established by their customer base. Customers for EL tend to be much more focused on lowering costs related to administration and software program growth then security on the low-degree OS. Enterprise Linux customers tend to rely on physical, human policy, and network safety to guard their 'delicate' interiors from being exposed to external threats.. assuming (rightly) that there is very little they will do to truly harden their programs. Actually when the choice comes between security vs comfort I am positive that the majority clients will happily defeat or strip out any security mechanisms launched into Linux. On prime of that when most Enterprise software program is extremely unhealthy. A lot in order that 10 hours spent on bettering an internet front-finish will yield extra actual-world security benefits then a a thousand hours spent on Linux kernel bugs for most businesses. Even for 'regular' Linux users a security bug in their Firefox's NAPI flash plugin is way more devastating and poses a massively greater threat then a obscure Linux kernel buffer over flow drawback. It's just probably not important for attackers to get 'root' to get entry to the vital information... generally all of which is contained in a single person account. Finally it's as much as people such as you and myself to put the hassle and cash into enhancing Linux security. For both ourselves and different folks.

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

Spilling has at all times been the case, but now, to me and in pc safety, most of the money appears spilled attributable to dangerous faith. And this is generally your money or mine: both tax-fueled governemental sources or company prices which can be immediately reimputed on the costs of goods/software program we are advised we're *obliged* to purchase. (Take a look at corporate firewalls, dwelling alarms or antivirus software advertising and marketing discourse.) I feel it is time to level out that there are several "malicious malefactors" round and that there is a real need to establish and sanction them and confiscate the sources they have by some means managed to monopolize. And i do *not* think Linus is among such culprits by the best way. However I think he may be amongst those hiding their heads in the sand in regards to the aforementioned evil actors, while he in all probability has extra leverage to counteract them or oblige them to reveal themselves than many people. I discover that to be of brown-paper-bag degree (though head-in-the-sand is one way or the other a brand new interpretation). In the end, I think you're proper to say that at present it is only as much as us people to strive actually to do something to enhance Linux or pc security. But I still suppose that I am right to say that this isn't normal; especially while some very serious individuals get very serious salaries to distribute randomly some difficult to guage budgets. [1] A paradoxical situation if you give it some thought: in a domain where you're firstly preoccupied by malicious individuals everyone ought to have factual, transparent and trustworthy behavior as the first priority in their mind.

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

It even has a nice, seven line Basic-pseudo-code that describes the current situation and clearly exhibits that we are caught in an limitless loop. It doesn't reply the big query, though: How to write better software program. The unhappy factor is, that this is from 2005 and all of the things that had been obviously stupid ideas 10 years in the past have proliferated even more.

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

Note IMHO, we should investigate additional why these dumb things proliferate and get so much assist. If it is solely human psychology, nicely, let's battle it: e.g. Mozilla has proven us that they'll do fantastic issues given the right message. If we are dealing with active people exploiting public credulity: let's establish and fight them. But, extra importantly, let's capitalize on this data and secure *our* programs, to showcase at a minimal (and more later on in fact). Your reference conclusion is especially good to me. "challenge [...] the standard wisdom and the status quo": that job I might fortunately accept.

Posted Nov 30, 2015 9:39 UTC (Mon) by paulj (subscriber, #341) [Hyperlink]

That rant is itself a bunch of "empty calories". The converse to the gadgets it rants about, which it is suggesting at some degree, could be as unhealthy or worse, and indicative of the worst sort of security considering that has put a lot of people off. Alternatively, it is only a rant that gives little of worth. Personally, I think there is not any magic bullet. Security is and at all times has been, in human history, an arms race between defenders and attackers, and one that is inherently a trade-off between usability, dangers and costs. If there are mistakes being made, it's that we should in all probability spend more sources on defences that could block total classes of attacks. E.g., why is the GRSec kernel hardening stuff so onerous to use to regular distros (e.g. there's no dependable supply of a GRSec kernel for Fedora or RHEL, is there?). Why does the complete Linux kernel run in one security context? Why are we nonetheless writing a lot of software program in C/C++, typically with none primary safety-checking abstractions (e.g. basic bounds-checking layers in between I/O and parsing layers, say)? Can hardware do more to offer safety with speed? Little doubt there are a lot of individuals engaged on "block classes of assaults" stuff, the query is, why aren't there more assets directed there?

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

>There are plenty of the reason why Linux lags behind in defensive safety applied sciences, however one among the key ones is that the businesses being profitable on Linux have not prioritized the event and integration of these technologies. This looks like a motive which is basically value exploring. Why is it so? I believe it isn't apparent why this would not get some extra consideration. Is it possible that the people with the money are right not to more extremely prioritise this? Afterall, what curiosity do they have in an unsecure, exploitable kernel? Where there's frequent trigger, linux growth gets resourced. It has been this manner for a few years. If filesystems qualify for frequent interest, absolutely security does. So there doesn't seem to be any apparent motive why this problem does not get extra mainstream attention, besides that it really already gets sufficient. You might say that catastrophe has not struck yet, that the iceberg has not been hit. Nevertheless it seems to be that the linux improvement process will not be overly reactive elsewhere.

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

That is an attention-grabbing query, certainly that's what they really believe no matter what they publicly say about their dedication to safety technologies. What is the truly demonstrated downside for Kernel developers and the organizations that pay them, so far as I can tell there shouldn't be sufficient consequence for the lack of Safety to drive extra funding, so we are left begging and cajoling unconvincingly.

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

The important thing concern with this domain is it relates to malicious faults. So, when penalties manifest themselves, it is too late to act. And if the current commitment to an absence of voluntary strategy persists, we are 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 days the place armed land-drones patrol US streets within the neighborhood of their youngsters colleges for them to find the feeling. They aren't so distants the times when innocent lives will unconsciouly depend on the security of (linux-primarily based) pc techniques; underneath water, that is already the case if I remember accurately my final dive, as well as in a number of latest vehicles according to some reports.

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

Basic hosting companies that use Linux as an uncovered entrance-end system are retreating from improvement while HPC, cell and "generic enterprise", i.E. RHEL/SLES, are pushing the kernel in their instructions. This is really not that shocking: For hosting wants the kernel has been "completed" for quite a while now. Besides help for current hardware there shouldn't be a lot use for newer kernels. Linux 3.2, and even older, works simply tremendous. Hosting does not need scalability to tons of or hundreds of CPU cores (one makes use of commodity hardware), complex instrumentation like perf or tracing (systems are locked down as a lot as doable) or advanced power-management (if the system does not have constant excessive load, it's not making sufficient money). So why ought to internet hosting companies still make robust investments in kernel development? Even if they'd one thing to contribute, the hurdles for contribution have turn into greater and higher. For his or her security wants, internet hosting companies already use Grsecurity. I don't have any numbers, but some experience suggests that Grsecurity is principally a hard and fast requirement for shared internet hosting. However, kernel security is sort of irrelevant on nodes of an excellent laptop or on a system running large business databases which might be wrapped in layers of center-ware. And cell distributors simply do not care.

Posted Nov 10, 2015 4:18 UTC (Tue) by bronson (subscriber, #4806) [Hyperlink]

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

The assembled doubtless recall that in August 2011, kernel.org was root compromised. I am positive the system's arduous drives have been despatched off for forensic examination, and we've all been waiting patiently for the reply to a very powerful question: What was the compromise vector? From shortly after the compromise was discovered on August 28, 2011, right via April 1st, 2013, kernel.org included this be aware at the highest of the site News: 'Because of all to your endurance and understanding throughout our outage and please bear with us as we carry up the different kernel.org methods over the subsequent few weeks. We will likely be writing up a report on the incident in the future.' (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 knowledge -- 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 an excellent public report on precisely what happened. Likewise, the Apache Foundation likewise did the correct factor 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 in the past. He wrote: Linux developer and maintainer Greg Kroah-Hartman informed Ars that the investigation has but to be accomplished and gave no timetable for when a report could be released. [...] Kroah-Hartman also instructed Ars kernel.org programs had been rebuilt from scratch following the attack. Officials have developed new instruments and procedures since then, but he declined to say what they're. "There will probably be a report later this year about site [sic] has been engineered, however do not quote me on when it will likely be launched as I'm not liable for it," he wrote. Who's responsible, then? Is anyone? Anyone? Bueller? Or is it a state secret, or what? Two years since Greg Okay-H said there could be a report 'later this 12 months', and four years because the meltdown, nothing but. How about some information? Rick Moen [email protected]

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

Less severely, word that if even the Linux mafia does not know, it should be the venusians; they are notoriously stealth in their invasions.

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

I know the kernel.org admins have given talks about some of the brand new protections that have been put into place. There aren't any more shell logins, as an alternative all the things makes use of gitolite. The different services are on different hosts. There are more kernel.org employees now. Individuals are utilizing two factor identification. Another stuff. Do a seek for Konstantin Ryabitsev.

Posted Nov 14, 2015 15:58 UTC (Sat) by rickmoen (subscriber, #6943) [Link]

I beg your pardon if I used to be somehow unclear: That was stated to have been the path of entry to the machine (and that i can readily believe that, because it was also the precise path to entry into shells.sourceforge.web, a few years prior, around 2002, and into many different shared Internet hosts for a few years). However that's not what is of main curiosity, and isn't what the forensic study lengthy 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 access is presently unknown and is being investigated'. Ok, people, you've now had 4 years of investigation. What was the trail of escalation to root? (Additionally, other details that may logically be lined by a forensic study, equivalent to: Whose key was stolen? Who stole the key?) That is the kind 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 entrance page of kernel.org, without remark, along with the remainder of the positioning News section, and apparently dropped). It still could be appropriate to know and share that data. 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 performed a more in-depth review of revelations that came out soon after the break-in, and think I've found the reply, by way of 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 general public was knowledgeable), plus Aug. 31st feedback to The Register's Dan Goodin by 'two security researchers who had been briefed on the breach': Root escalation was via exploit of a Linux kernel safety gap: Per the 2 safety researchers, it was one both extraordinarily embarrassing (broad-open entry to /dev/mem contents together with the running kernel's picture in RAM, in 2.6 kernels of that day) and identified-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 Web servers working with all providers still lit up, for a number of days. - Site admins and Linux Basis sat on the information 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 trojaned Linux source tarballs have been posted in the http/ftp tree for the 19+ days earlier than they took the site down. (Sure, git checkout was superb, however what in regards to the hundreds 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 Basis now stonewalls press queries.I posted my finest try at reconstructing the story, absent a real report from insiders, to SVLUG's foremost mailing listing yesterday. (Necessarily, there are surmises. If the people with the facts were more forthcoming, we would know what occurred for sure.) I do must wonder: If there's one other embarrassing screwup, will we even be told about it in any respect? Rick Moen [email protected]

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

Additionally, it's preferable to make use of stay reminiscence acquisition prior to powering off the system, in any other case you lose out on reminiscence-resident artifacts that you could perform forensics on. -Brad

How in regards to 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 in your comments, Brad. I might been relying on Dan Goodin's declare of Phalanx being what was used to achieve root, in the bit where he cited 'two safety researchers who have been briefed on the breach' to that impact. Goodin also elaborated: 'Fellow safety researcher Dan Rosenberg mentioned he was additionally 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 device, and that i noted that oddity in my posting to SVLUG. That having been said, yeah, the Phalanx README does not specifically claim this, so then perhaps Goodin and his a number of 'safety researcher' sources blew that detail, and no person however kernel.org insiders but knows the escalation path used to realize root. Additionally, it is preferable to use reside reminiscence acquisition prior to powering off the system, otherwise you lose out on reminiscence-resident artifacts which you can carry out forensics on. Arguable, however a tradeoff; you'll be able to poke the compromised dwell system for state knowledge, but with the disadvantage of leaving your system operating under hostile control. I used to be always taught that, on balance, it's higher to pull energy to finish the intrusion. Rick Moen [email protected]

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

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 corporations" just stuck to using parts with mainlined open supply drivers, then updating their merchandise can be much simpler.

A brand new Mindcraft second?

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

They have ring zero privilege, can access protected reminiscence straight, and cannot be audited. Trick a kernel into running a compromised module and it is recreation over. Even tickle a bug in a "good" module, and it's in all probability game over - in this case fairly literally as such modules are usually video drivers optimised for games ...