A Brand New Mindcraft Second

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 5th in a collection of articles following the security of the internet from its beginnings to related matters of at the moment. discussing the safety of linux (or lack thereof) suits properly in there. it was also a well-researched article with over two months of analysis and interviews, something you can't quite declare yourself on your current pieces on the topic. you don't just like the information? then say so. or even better, do something constructive about them like Kees and others have been attempting. nonetheless foolish comparisons to outdated crap just like the Mindcraft studies and fueling conspiracies don't precisely assist your case. 2. "We do a reasonable job of discovering and fixing bugs." let's start right here. is that this statement based mostly on wishful pondering or cold arduous information you are going to share in your response? according to Kees, the lifetime of safety bugs is measured in years. that's greater than the lifetime of many devices people purchase and use and ditch in that interval. 3. "Issues, whether or not they are safety-related or not, are patched rapidly," some are, some aren't: let's not overlook the recent NMI fixes that took over 2 months to trickle right down to stable kernels and we also have a user who has been ready for over 2 weeks now: http://thread.gmane.org/gmane.comp.file-programs.btrfs/49500 (FYI, the overflow plugin is the first one Kees is trying to upstream, imagine the shitstorm if bugreports will probably be handled with this perspective, let's hope btrfs guys are an exception, not the rule). anyway, two examples will not be statistics, so as soon as again, do you could have numbers or is it all wishful pondering? (it is partly a trick query as a result of you may also have to clarify how something gets to be determined to be safety related which as we all know is a messy enterprise in the linux world) 4. "and the stable-update mechanism makes these patches available to kernel customers." except when it does not. and sure, i've numbers: grsec carries 200+ backported patches in our 3.14 stable tree. 5. "Specifically, the few builders who are working on this area have never made a critical try to get that work built-in upstream." you do not should be shy about naming us, after all you did so elsewhere already. and we additionally explained the the explanation why we haven't pursued upstreaming our code: https://lwn.web/Articles/538600/ . since i do not expect you and your readers to read any of it, here is the tl;dr: if you need us to spend 1000's of hours of our time to upstream our code, you'll have to pay for it. no ifs no buts, that's how the world works, that is how >90% of linux code will get in too. i personally discover it fairly hypocritic that properly paid kernel builders are bitching about our unwillingness and inability to serve them our code on a silver platter without spending a dime. and before someone brings up the CII, go test their mail archives, after some preliminary 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) [Link]



Cash (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 for free. The Linux basis and large corporations utilizing Linux (Google, Crimson Hat, Oracle, Samsung, and so on.) ought to pay safety specialists like you to upstream your patchs.



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



I'd simply like to level out that the way you phrased this makes your comment a tone argument[1][2]; you have (probably unintentionally) dismissed the entire dad or mum's arguments by pointing at its presentation. The tone of PAXTeam's comment displays the frustration constructed up over time with the way in which issues work which I believe ought to be taken at face value, empathized with, and understood fairly than simply 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) [Hyperlink]



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



why, is upstream identified for its fundamental civility and decency? have you even read the WP post underneath discussion, by no means thoughts 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 (guest, #58961) [Link]



No Argument



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



Please don't; it would not belong there either, and it particularly would not need a cheering part because the tech press (LWN typically excepted) tends to supply.



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



Ok, but I used to be pondering of Linus Torvalds



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



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



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



Why should you assume solely cash will repair this problem? Yes, I agree more sources ought to be spent on fixing Linux kernel safety points, but don't assume someone giving a company (ahem, PAXTeam) money is the only resolution. (Not mean to impugn PAXTeam's safety efforts.)



The Linux growth group could have had the wool pulled over its collective eyes with respect to security issues (either real or perceived), but simply throwing money at the problem won't fix this.



And yes, I do notice the industrial Linux distros do heaps (most?) of the kernel development nowadays, and that implies oblique financial transactions, however it's much more involved than simply that.



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



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



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



I believe you undoubtedly agree with the gist of Jon's argument... not sufficient focus has been given to security within the Linux kernel... the article will get that part proper... cash hasn't been going in direction of safety... and now it needs to. Aren't you glad?



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



they talked to spender, not me personally, but sure, this aspect of the coin is effectively represented by us and others who were interviewed. the identical manner Linus is an efficient representative of, well, his own pet mission referred to as linux. > And if Jon had only talked to you, his would have been too. provided that i am the writer of PaX (part of grsec) yes, talking to me about grsec issues makes it among the finest ways to analysis it. but when you already know of another person, be my guest and name them, i am fairly sure the just lately formed kernel self-safety of us could be dying to have interaction them (or not, i don't think there is a sucker out there with thousands of hours of free time on their hand). > [...]it additionally contained fairly a couple of of groan-worthy statements. nothing is perfect however considering the audience of the WP, that is one in every of the better journalistic pieces on the subject, no matter the way you and others do not just like the sorry state of linux safety exposed in there. if you'd like to discuss extra technical details, nothing stops you from talking to us ;). speaking of your complaints about journalistic qualities, since a earlier LWN article noticed it fit to incorporate a number of typical dismissive claims by Linus about the standard of unspecified grsec options with no evidence of what experience he had with the code and how latest it was, how come we didn't see you or anyone else complaining about the standard of that article? > Aren't you glad? no, or not but anyway. i've heard numerous empty phrases over the years and nothing ever manifested or worse, all the money has gone to the pointless train of fixing individual 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 (Solar) by k3ninho (subscriber, #50375) [Link]



Proper now we've got builders from big names saying that doing all that the Linux ecosystem does *safely* is an itch that they have. Sadly, the encircling cultural perspective of builders is to hit useful targets, and occasionally performance goals. Safety targets are often missed. Ideally, the culture would shift so that we make it difficult to follow insecure habits, patterns or paradigms -- that may be a activity that may take a sustained effort, not merely the upstreaming of patches. Whatever the tradition, these patches will go upstream ultimately anyway as a result of the ideas that they embody at the moment are well timed. I can see a way to make it happen: Linus will settle for them when a giant finish-consumer (say, Intel, Google, Facebook or Amazon) delivers stuff with notes like 'here's a set of enhancements, we're already using them to unravel this type of problem, here's how every part will stay working as a result of $evidence, observe fastidiously 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 might be gamed; I'd favor that the community shepherds customers to follow the pattern of declaring problem + solution + useful take a look at evidence + efficiency take a look at proof + safety test proof. K3n.



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



And about that fork barrel: I'd argue it's the opposite approach around. Google forked and lost already.



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



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



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



So I must confess to a certain quantity of confusion. I might swear that the article I wrote said precisely that, however you have put a good amount of effort into flaming it...?



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



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



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



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



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



I hope I'm mistaken, but a hostile attitude isn't going to assist anybody receives a commission. It's a time like this where something you seem to be an "professional" at and there's a demand for that expertise where you show cooperation and willingness to take part as a result of it's an opportunity. I am relatively shocked that somebody doesn't get that, but I'm 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 essentially the most. Typically you need to put money into proving your skills, and that is a type of moments. It appears the Kernel group could lastly take this security lesson to heart and embrace it, as stated within the article as a "mindcraft second". This is a chance for developers that may want to work on Linux security. Some will exploit the opportunity and others will thumb their noses at it. In the end these builders that exploit the opportunity will prosper from it. I really feel outdated even having to jot down that.



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



Perhaps there is a chicken and egg problem here, however when seeking out and funding individuals to get code upstream, it helps to pick out people and groups with a historical past of having the ability to get code upstream. It's completely cheap to want figuring out of tree, offering the power to develop impressive and critical security advances unconstrained by upstream requirements. That is work someone may additionally wish to fund, if that meets their wants.



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 does not) after which fail to support it by any cite. It can be much more convincing in case you quit on the Onus probandi rhetorical fallacy and truly cite details. > living proof, it was *them* who instructed that they would not fund out-of-tree work but would consider funding upstreaming work, except when pressed for the details, all i received was silence. For those following alongside at home, that is the relevant set of threads: http://lists.coreinfrastructure.org/pipermail/cii-talk about... A quick precis is that they advised you your undertaking was unhealthy as a result of the code was never going upstream. You told them it was because of kernel developers perspective so they need to fund you anyway. They informed you to submit a grant proposal, you whined more in regards to the kernel attitudes and ultimately even your apologist advised you that submitting a proposal might be the neatest thing to do. At that point you went silent, not vice versa as you indicate above. > obviously i won't spend time to put in writing up a begging proposal simply to be told that 'no sorry, we do not fund multi-year tasks at all'. that is something that one ought to be informed in advance (or heck, be part of some public rules in order that others will know the principles too). You appear to have a fatally flawed grasp of how public funding works. If you don't tell individuals why you need the money and how you may spend it, they're unlikely to disburse. Saying I am sensible and I do know the issue now hand over the money would not even work for most Teachers who have a strong fame 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 verify the kernel git logs (minus the stuff that was not correctly credited)? jejb@jarvis> git log|grep -i 'Creator: pax.*team'|wc -l 1 Stellar, I have to say. And before you gentle off on those who've misappropriated your credit, please remember 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 nicely funded. If more of your stuff does go upstream, will probably be because of the not inconsiderable efforts of other individuals on this area. You now have a business mannequin selling non-upstream safety patches to prospects. There's nothing flawed with that, it's a fairly regular first stage business mannequin, but it does moderately depend upon patches not being upstream in the primary place, calling into question the earnestness of your attempt to place them there. Now here is some free recommendation in my subject, which is assisting companies align their companies in open source: The selling out of tree patch route is always an eventual failure, notably with the kernel, because if the performance is that helpful, it gets upstreamed or reinvented in your despite, leaving you with nothing to promote. If your business plan B is selling expertise, you might have to remember that it should 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. Actually "crazy security individual" will turn into a self fulfilling prophecy. The advice? it was apparent to everybody else who read this, however for you, it is do the upstreaming yourself before it gets accomplished for you. That way you have a legitimate historic declare to Plan B and also you might actually have a Plan A promoting a rollup of upstream track patches integrated and delivered earlier than the distributions get round to it. Even your software to the CII could not be dismissed as a result of your work wasn't going anywhere. Your alternative is to proceed taking part in the role of Cassandra and possibly suffer her eventual destiny.



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



> Second, for the probably viable items this could be a multi-year > full time job. Is the CII keen to fund tasks at that level? If not > we all would end up with numerous unfinished and partially broken features. please present me the answer to that question. with out a definitive 'sure' there is no point in submitting a proposal because this is the time-frame that in my opinion the job will take and any proposal with that requirement can be shot down immediately and be a waste of my time. and that i stand by my claim that such easy primary requirements must be public info. > Stellar, I have to say. "Lies, damned lies, and statistics". you realize there's more than one way to get code into the kernel? how about you employ your git-fu to seek out all the bugreports/advised fixes that went in resulting from us? as for specifically me, Greg explicitly banned me from future contributions through af45f32d25cc1 so it is no wonder i don't send patches immediately in (and that one commit you found that went in regardless of mentioned ban is definitely a really bad example as a result of it's also the one that Linus censored for no good reason and made me resolve to by no means send security fixes upstream until that apply changes). > You now have a business mannequin promoting non-upstream safety patches to clients. now? we've had paid sponsorship for our varied stable kernel sequence for 7 years. i wouldn't name it a enterprise mannequin though as it hasn't paid anybody's payments. > [...]calling into query the earnestness of your try to place them there. i should be missing something right here however what attempt? i've never in my life tried to submit PaX upstream (for all the reasons discussed already). the CII mails were exploratory to see how critical that complete organization is about truly securing core infrastructure. in a way i've got my solutions, there's nothing extra to the story. as to your free advice, let me reciprocate: complex problems don't resolve themselves. code solving advanced issues doesn't write itself. folks writing code fixing complicated issues are few and much between that you can see out briefly order. such folks (area consultants) don't work without spending a dime with few exceptions like ourselves. biting the hand that feeds you will only finish you up in starvation. PS: since you are so sure about kernel builders' capacity to reimplement our code, perhaps take a look at what parallel options i still maintain in PaX despite vanilla having a 'totally-not-reinvented-right here' implementation and try to grasp the rationale. or just look at all the CVEs that affected say vanilla's ASLR however didn't affect mine. PPS: Cassandra never wrote code, i do. criticizing the sorry state of kernel safety is a facet mission when i am bored or just waiting for the following kernel to compile (i wish LTO was more environment friendly).



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



In different phrases, you tried to define their process for them ... I can not suppose why that would not work. > "Lies, damned lies, and statistics". The problem with advert hominem attacks is that they are singularly ineffective towards a transparently factual argument. I posted a one line command anyone could run to get the variety of patches you have authored in the kernel. Why don't you publish an equal that gives figures you want more? > i've never in my life tried to submit PaX upstream (for all the reasons discussed already). So the grasp plan is to reveal your expertise by the number of patches you have not submitted? great plan, world domination beckons, sorry that one obtained away from you, however I am positive you will not let it occur again.



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



what? since when does asking a query outline anything? is not that how we discover out what another person thinks? isn't that what *they* have that webform (by no means mind the mailing lists) for as effectively? in different words you admit that my question was not truly answered . > The issue with advert hominem attacks is that they are singularly ineffective against a transparently factual argument. you didn't have an argument to begin with, that is what i defined within the part you rigorously selected not to quote. i am not here to defend myself against your clearly idiotic makes an attempt at proving no matter you are making an attempt to prove, as they are saying even in kernel circles, code speaks, bullshit walks. you may have a look at mine and decide what i can or can not do (not that you have the knowledge to know most of it, thoughts you). that stated, there're clearly different more capable individuals who have done so and decided that my/our work was value something else no one would have been feeding off of it for the past 15 years and still counting. and as unimaginable as it could seem to you, life would not revolve across the vanilla kernel, not everybody's dying to get their code in there especially when it means to place up with such silly hostility on lkml that you now additionally demonstrated right here (it is ironic how you came to the protection of josh who particularly requested folks not to bring that notorious lkml type here. good job there James.). as for world domination, there're some ways to realize it and one thing tells me that you're clearly out of your league right here since PaX has already achieved that. you are operating such code that implements PaX options as we speak.



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



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



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



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



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



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



anyway, since it is you guys who have a bee in your bonnet, let's test your stage of intelligence too. first determine my electronic mail handle and project name then attempt to search out the commits that say they come from there (it introduced again some recollections from 2004 already, how instances flies! i am shocked i really managed to perform this much with explicitly not trying, imagine if i did :). it is an incredibly advanced activity so by engaging in it you will show yourself to be the top dog here on lwn, whatever that is worth ;).



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



*shrug* Or do not; you're only sullying your personal reputation.



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



Posted Nov 9, 2015 11:38 UTC (Mon) by hkario (subscriber, #94864) [Link]



I wouldn't either



Posted Nov 12, 2015 2:09 UTC (Thu) by jschrod (subscriber, #1646) [Link]



Posted Nov 12, 2015 8:50 UTC (Thu) by nwmcsween (visitor, #62367) [Link]



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



Posted Nov 12, 2015 13:47 UTC (Thu) by nix (subscriber, #2304) [Link]



Ah. I thought my memory wasn't failing me. Examine to PaXTeam's response to <http: lwn.net articles 663612 />. PaXTeam is not averse to outright mendacity if it means he gets to appear right, I see. Possibly PaXTeam's reminiscence is failing, and this obvious contradiction shouldn't be a brazen lie, however given that the two 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. Sure, I *do* assume he's lying by implication right here, and doing so when there's nearly nothing at stake. God alone knows what he's willing to stoop to when one thing *is* at stake. Gosh I ponder why his fixes aren't going upstream very fast.)



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



> and that one commit you discovered that went in regardless of said ban also someone's ban does not imply it'll translate into another person's execution of that ban as it's clear from the commit in query. it is considerably sad that it takes a security fix to expose the fallacy of this coverage although. the remainder of your pithy ad hominem speaks for itself higher than i ever might ;).



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



Posted Nov 7, 2015 19:01 UTC (Sat) by cwillu (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) [Link]



You're aware that it is solely attainable that everyone is fallacious right here , right? That the kernel maintainers need to focus extra on safety, that the article was biased, that you're irresponsible to decry the state of safety, and do nothing to assist, and that your patchsets wouldn't assist that much and are the mistaken course for the kernel? That simply because the kernel maintainers aren't 100% right it doesn't mean you are?



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



I feel you have him backwards there. Jon is evaluating this to Mindcraft as a result of he thinks that regardless of being unpalatable to quite a lot of the neighborhood, the article might the truth is include a number of fact.



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



Posted Nov 9, 2015 15:Thirteen 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 properly be true" Simply as you criticized the article for mentioning Ashley Madison despite the fact that within the very first sentence of the next paragraph it mentions it did not contain the Linux kernel, you can't give credence to conspiracy theories without incurring the identical criticism (in different words, you can't play the Glenn Beck "I am just asking the questions here!" whose "questions" gasoline the conspiracy theories of others). Very similar to mentioning Ashley Madison for example for non-technical readers concerning the prevalence of Linux on the planet, if you are 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 identified within the initial put up, the motivations aren't laborious to know -- you made no point out in any respect about it being the 5th in an extended-running collection following a fairly predictable time trajectory. No, we didn't miss the general analogy you have been attempting to make, we simply do not assume you 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) [Link]



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



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



Sadly, I do not perceive neither the "security" of us (PaXTeam/spender), nor the mainstream kernel of us by way of their perspective. I confess I have completely no technical capabilities on any of those topics, but if all of them decided to work collectively, instead of having limitless and pointless flame wars and blame recreation exchanges, a variety of the stuff would have been finished already. And all the while everybody concerned might have made one other big pile of cash on the stuff. All of them appear to want to have a better Linux kernel, so I've acquired no idea what the issue is. It seems that no person is keen to yield any of their positions even a bit bit. As a substitute, each sides appear to be bent on attempting to insult their approach into forcing the other side to surrender. Which, after all, never works - it simply causes more pushback. Perplexing stuff...



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



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



Take a scientific computational cluster with an "air gap", as an illustration. You'd probably want most of the security stuff turned off on it to realize most efficiency, because you'll be able to belief all users. Now take a number of billion mobile phones that may be tough or sluggish to patch. You'd probably need to kill many of the exploit lessons there, if these gadgets can still run reasonably well with most safety options turned on. So, it is not both/or. It is in all probability "it depends". However, if the stuff isn't there for everybody to compile/use within the vanilla kernel, it will likely be harder to make it a part of everyday selections for distributors and users.



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



How unhappy. This Dijkstra quote involves thoughts immediately: Software program engineering, of course, presents itself as one other worthy cause, however that is eyewash: if you fastidiously read its literature and analyse what its devotees truly do, you will discover that software program engineering has accepted as its charter "Easy methods to program if you cannot."



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



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



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



Indeed. And the interesting thing to me is that when I attain that time, exams are not ample - mannequin checking at a minimal and really proofs are the one method forwards. I am no security professional, my discipline is all distributed systems. I understand and have carried out Paxos and i believe I can clarify how and why it works to anybody. But I'm at present performing some algorithms combining Paxos with a bunch of variations on VectorClocks and reasoning about causality and consensus. No check is adequate as a result of there are infinite interleavings of events and my head just couldn't cope with working on this both at the computer or on paper - I discovered I couldn't intuitively reason about this stuff in any respect. So I began defining the properties and wanted and step-by-step proving why each of them holds. Without my notes and proofs I am unable to even explain to myself, let alone anyone else, why this factor works. I discover this both fully apparent that this could happen and totally terrifying - the upkeep price of those algorithms is now an order of magnitude greater.



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



> Certainly. And the attention-grabbing thing to me is that after I attain that time, tests aren't ample - model checking at a minimal and actually proofs are the one means forwards. Or are you simply utilizing the unsuitable maths? Hobbyhorse time again :-) however to quote a fellow Decide developer ... "I typically walk into a SQL improvement shop and see that wall - you understand, the one with the large SQL schema that no-one absolutely understands on it - and surprise how I can simply hold all the schema for a Choose database of the same or larger complexity in my head". However it is simple - by training I'm a Chemist, by curiosity a Bodily Chemist (and by career an unemployed programmer :-). And when I'm interested by chemistry, I can ask myself "what is an atom product of" and assume about things like the robust nuclear drive. Next degree up, how do atoms stick collectively and make molecules, and think in regards to the electroweak power and electron orbitals, and the way do chemical reactions occur. Then I think about molecules stick together to make supplies, and assume about metals, and/or Van de Waals, and stuff. Level is, you could *layer* stuff, and look at issues, and say "how can I split parts off into 'black bins' so at any one level I can assume the other levels 'simply work'". For example, with Decide a FILE (desk to you) shops a class - a set of similar objects. One object per Record (row). And, same as relational, one attribute per Field (column). Can you map your relational tables to actuality so easily? :-) Going again THIRTY years, I remember a narrative about a man who built little laptop crabs, that might fairly happily scuttle around in the surf zone. As a result of he didn't attempt to work out how to unravel all the issues at once - every of his (incredibly puny by in the present day's standards - this is the 8080/Z80 period!) processors was set to simply course of slightly little bit of the problem and there was no central "brain". However it worked ... MINECRAFT SERVER LIST Possibly you should just write a bunch of small modules to solve every particular person downside, and let final reply "just occur". Cheers, Wol



Posted Nov 19, 2015 19:28 UTC (Thu) by ksandstr (guest, #60862) [Hyperlink]



To my understanding, this is strictly what a mathematical abstraction does. For example in Z notation we would assemble schemas for the varied modifying ("delta") operations on the base schema, and then 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 outcome is a set of operations that, executed in arbitrary order, lead to a set of properties holding for the result and outputs. Thus proving the formal design appropriate (w/ caveat lectors regarding scope, correspondence with its implementation [although that can be confirmed as effectively], and browse-solely ["xi"] operations).



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



Trying via the historical past of computing (and possibly loads of different fields too), you will most likely discover that folks "cannot see the wooden for the timber" more usually that not. They dive into the element and completely miss the large image. (Medicine, and curiosity of mine, suffers from that too - I remember somebody talking about the consultant eager to amputate a gangrenous leg to avoid wasting someone's life - oblivious to the fact that the affected person was dying of most cancers.) Cheers, Wol



Posted Nov 7, 2015 6:35 UTC (Sat) by dgc (subscriber, #6611) [Link]



https://www.youtube.com/watch?v=VpuVDfSXs-g (LCA 2015 - "Programming Considered Dangerous") FWIW, I feel that this talk is very related to why writing secure software is so exhausting.. -Dave.



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



Whereas we are spending tens of millions at a mess of safety problems, kernel points should not on our top-precedence checklist. Honestly I remember solely as soon as having discussing a kernel vulnerability. The results of the analysis has been that all our programs were operating kernels that had been older as the kernel that had the vulnerability. However "patch management" is a real challenge for us. Software program should continue to work if we set up security patches or update to new releases due to the top-of-life coverage of a vendor. The income of the company is depending on the IT techniques working. So "not breaking consumer area" is a safety feature for us, as a result of a breakage of one element of our a number of ten thousands of Linux techniques will stop the roll-out of the safety update. Another problem is embedded software or firmware. Nowadays nearly all hardware systems include an operating system, usually some Linux model, offering a fill community stack embedded to help distant administration. MINECRAFT SERVER LIST Frequently those programs don't survive our obligatory safety scan, as a result of vendors still didn't update the embedded openssl. The actual problem is to supply a software program stack that may be operated within the hostile environment of the Web maintaining full system integrity for ten years or even longer with none buyer maintenance. The present state of software engineering would require help for an automatic update course of, but vendors should perceive that their enterprise mannequin must have the ability to finance the sources providing the updates. General I am optimistic, networked software program isn't the primary expertise used by mankind causing problems that were addressed later. Steam engine use may end in boiler explosions but the "engineers" had been in a position to reduce this risk significantly over a few many years.



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



The next is all guess work; I would be eager to know if others have evidence both a method or another on this: The people who learn to hack into these programs via kernel vulnerabilities know that they expertise they've learnt have a market. Thus they don't are inclined to hack with the intention to wreak havoc - certainly on the whole where information has been stolen to be able to release and embarrass individuals, it _seems_ as if these hacks are by way of much simpler vectors. I.e. lesser expert hackers find there's a complete load of low-hanging fruit which they can get at. They're not being paid ahead of time for the information, so they flip to extortion as a substitute. They do not cover their tracks, and they can usually be found and charged with criminal offences. So in case your safety meets a certain fundamental level of proficiency and/or your organization isn't doing something that places it close to the highest of "firms we'd wish to embarrass" (I believe the latter is much more practical at preserving techniques "safe" than the previous), then the hackers that get into your system are likely to be skilled, paid, and probably not going to do a lot harm - they're stealing knowledge for a competitor / state. So that does not hassle your backside line - at the least not in a means which your shareholders will remember of. So why fund safety?



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



Then again, some efficient mitigation in kernel stage can be very helpful to crush cybercriminal/skiddie's strive. If one of your buyer working a future buying and selling platform exposes some open API to their clients, and if the server has some memory corruption bugs can be exploited remotely. Then you already know there are recognized assault strategies( comparable to offset2lib) may also help the attacker make the weaponized exploit so much simpler. Will you explain the failosophy "A bug is bug" to your customer and tell them it might be ok? Btw, offset2lib is ineffective to PaX/Grsecurity's ASLR imp. To the most commercial makes use of, extra security mitigation inside the software will not cost you extra budget. You will nonetheless must 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 specialise in exterior internet-based mostly penetration-assessments and that in-home assessments (native LAN) will doubtless yield different results.



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



I keep reading this headline as "a brand new Minecraft moment", and thinking that perhaps they've determined to observe up the .Net factor by open-sourcing Minecraft. Oh effectively. I imply, security is sweet too, I guess.



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



Posted Nov 12, 2015 17:29 UTC (Thu) by smitty_one_each (subscriber, #28989) [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:Fifty three UTC (Mon) by neiljerram (subscriber, #12005) [Hyperlink]



(Oh, and I used to be additionally still questioning how Minecraft had taught us about Linux performance - so thanks to the other comment thread that pointed out 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 opinion, there's a general problem with the economics of laptop safety, which is especially visible currently. Two problems even perhaps. First, the money spent on computer safety is usually diverted towards the so-known as safety "circus": fast, simple options which are primarily selected simply with a purpose to "do something" and get higher press. It took me a long time - perhaps a long time - to assert that no security mechanism at all is better than a foul mechanism. However now I firmly consider in this attitude and would relatively take the danger knowingly (supplied that I can save money/resource for myself) than take a bad method at fixing it (and have no money/useful resource left when i understand I should have achieved something else). And i find there are various dangerous or incomplete approaches currently out there in the pc security subject. Those spilling our rare money/assets on ready-made ineffective tools ought to get the unhealthy press they deserve. And, we certainly need to enlighten the press on that as a result of it is not so easy to understand the efficiency of protection mechanisms (which, by definition, should forestall issues from taking place). Second, and that may be newer and more worrying. The movement of cash/resource is oriented in the path of attack tools and vulnerabilities discovery much greater than within the direction of recent safety mechanisms. This is particularly worrying as cyber "protection" initiatives look an increasing number of like the usual idustrial projects aimed at producing weapons or intelligence programs. Furthermore, unhealthy useless weapons, because they are only working towards our very weak present systems; and dangerous intelligence methods as even fundamental college-stage encryption scares them down to useless. However, all the ressources are for these adult teenagers taking part in the white hat hackers with not-so-tough programming tips or community monitoring or WWI-level cryptanalysis. And now also for the cyberwarriors and cyberspies which have yet to prove their usefulness totally (particularly for peace protection...). Personnally, I might happily go away them all of the hype; but I will forcefully declare that they don't have any proper in any way on any of the finances allocation decisions. Solely those engaged on protection should. And yep, it means we should decide the place to put there assets. We've got to say the unique lock for ourselves this time. (and I guess the PaXteam could possibly be amongst the primary to benefit from such a change). While serious about it, I wouldn't even leave white-hat or cyber-guys any hype ultimately. That is more publicity than they deserve. I crave for the day I'll learn in 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 convey a type of unfinished and bad high quality packages, X, that we are all obliged to use to its knees, annoying thousands and thousands of regular users along with his unfortunate cyber-vandalism. All of the safety consultants unanimously advocate that, as soon as once more, the price range of the cyber-command be retargetted, or at the least leveled-off, with a purpose to bring more safety engineer positions in the educational area or civilian industry. And that X's producer, XY Inc., be liable for the potential losses if proved to be unprofessional on this affair."



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



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



The state of 'software program security industry' is a f-ng disaster. Failure of the best order. There is massive amounts of money that goes into 'cyber safety', but it's usually spent on government compliance and audit efforts. This means as a substitute of truly placing effort into correcting issues and mitigating future problems, the vast majority of the effort goes into taking existing purposes and making them conform to committee-pushed guidelines with the minimal amount of effort and changes. Some degree of regulation and standardization is absolutely wanted, but lay individuals are clueless and are completely unable to discern the distinction between somebody who has valuable expertise versus some firm that has spent hundreds of thousands on slick marketing and 'native advertising' on massive web sites and pc magazines. The people with the cash sadly only have their own judgment to rely on when buying into 'cyber security'. > Those spilling our uncommon money/sources on prepared-made ineffective instruments ought to get the bad press they deserve. There is no such thing as 'our uncommon cash/assets'. You have your money, I've mine. Money being spent by some company like Redhat is their money. Money being spent by governments is the federal government's money. (you, actually, have far more control in how Walmart spends it is cash then over what your government does with their's) > This is particularly worrying as cyber "defense" initiatives look an increasing number of like the standard idustrial tasks aimed toward producing weapons or intelligence programs. Moreover, bad useless weapons, because they are solely working in opposition to our very vulnerable present techniques; and bad intelligence methods as even primary school-stage encryption scares them all the way down to ineffective. Having safe software program with sturdy encryption mechanisms within the fingers of the public runs counter to the pursuits of most main governments. Governments, like any other for-revenue organization, are primarily inquisitive about self-preservation. Cash spent on drone initiatives or banking auditing/oversight regulation compliance is Far more useful to them then attempting to help the public have a secure mechanism for making telephone calls. Particularly when these safe mechanisms interfere with data assortment efforts. Sadly you/I/us can't rely upon some magical benefactor with deep pockets to sweep in and make Linux higher. It is simply not going to happen. Corporations like Redhat have been massively useful to spending resources to make Linux kernel more succesful.. nevertheless they're driven by a the necessity to turn a revenue, which implies they need to cater directly to the the sort of necessities established by their customer base. Prospects for EL tend to be way more targeted on reducing costs associated with administration and software program growth then security on the low-level OS. Enterprise Linux prospects tend to depend on physical, human policy, and network security to protect their 'smooth' interiors from being uncovered to exterior threats.. assuming (rightly) that there's little or no they will do to really harden their methods. In reality when the choice comes between security vs comfort I'm certain that the majority prospects will fortunately defeat or strip out any safety mechanisms introduced into Linux. On top of that when most Enterprise software is extremely unhealthy. So much in order that 10 hours spent on enhancing an online entrance-finish will yield extra actual-world security benefits then a 1000 hours spent on Linux kernel bugs for many businesses. Even for 'regular' Linux customers a security bug in their Firefox's NAPI flash plugin is far more devastating and poses a massively higher risk then a obscure Linux kernel buffer over movement drawback. It's simply not really necessary for attackers to get 'root' to get access to the important data... usually all of which is contained in a single person account. Finally it is as much as people like you and myself to place the trouble and money into bettering Linux safety. For each ourselves and different folks.



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



Spilling has always been the case, however now, to me and in laptop security, most of the money seems spilled as a result of unhealthy religion. And this is mostly your cash or mine: either tax-fueled governemental assets or company costs which can be instantly reimputed on the prices of goods/software we are instructed we are *obliged* to buy. (Look at company firewalls, house alarms or antivirus software program advertising and marketing discourse.) I believe it's time to level out that there are a number of "malicious malefactors" around and that there is an actual need to identify and sanction them and confiscate the assets they have in some way managed to monopolize. And that i do *not* think Linus is amongst such culprits by the way. However I feel he could also be amongst the ones hiding their heads within the sand concerning the aforementioned evil actors, whereas he probably has more 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 someway a new interpretation). In the long run, I believe you're right to say that at present it's only up to us people to strive truthfully to do something to enhance Linux or pc security. But I still assume that I am proper to say that this is not regular; especially while some very critical folks get very serious salaries to distribute randomly some difficult to judge budgets. [1] A paradoxical situation if you think about it: in a site where you are first and foremost preoccupied by malicious people everybody should have factual, clear and honest conduct as the first precedence in their thoughts.



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



It even has a pleasant, seven line Basic-pseudo-code that describes the present situation and clearly exhibits that we're caught in an infinite loop. It does not answer the massive query, although: How to put in writing better software. The unhappy thing is, that that is from 2005 and all the issues that have been clearly silly concepts 10 years in the past have proliferated much more.



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



Word IMHO, we should investigate further why these dumb things proliferate and get a lot help. If it is only human psychology, nicely, let's combat it: e.g. Mozilla has shown us that they can do wonderful things given the fitting message. If we are going through active folks exploiting public credulity: let's identify and fight them. But, more importantly, let's capitalize on this knowledge and secure *our* systems, to show off at a minimal (and extra later on of course). Your reference conclusion is very nice to me. "problem [...] the conventional wisdom and the status quo": that job I might fortunately settle for.



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 objects it rants about, which it is suggesting at some level, could be as unhealthy or worse, and indicative of the worst form of safety pondering that has put a lot of people off. Alternatively, it's only a rant that gives little of worth. Personally, I believe there is not any magic bullet. Security is and all the time has been, in human history, an arms race between defenders and attackers, and one that's inherently a commerce-off between usability, dangers and costs. If there are mistakes being made, it's that we should in all probability spend extra sources on defences that would block total classes of attacks. E.g., why is the GRSec kernel hardening stuff so arduous to use to common distros (e.g. there is not any dependable 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 still writing plenty of software program in C/C++, often with none fundamental security-checking abstractions (e.g. primary bounds-checking layers in between I/O and parsing layers, say)? Can hardware do extra to supply security with pace? No doubt there are loads of people engaged on "block lessons of attacks" stuff, the question is, why aren't there more sources directed there?



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



>There are a whole lot of the explanation why Linux lags behind in defensive security applied sciences, however one among the important thing ones is that the businesses earning profits on Linux haven't prioritized the event and integration of those technologies. This looks as if a reason which is admittedly value exploring. Why is it so? I feel it's not apparent why this does not get some extra consideration. Is it doable that the individuals with the money are proper not to extra highly prioritise this? Afterall, what curiosity do they have in an unsecure, exploitable kernel? The place there's common cause, linux growth will get resourced. It's been this way for a few years. If filesystems qualify for common interest, absolutely security does. So there doesn't seem to be any apparent motive why this situation doesn't get extra mainstream consideration, except that it truly already will get enough. You could say that catastrophe has not struck but, that the iceberg has not been hit. But it surely seems to be that the linux improvement course of is just not overly reactive elsewhere.



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



That's an attention-grabbing question, definitely that is what they really imagine regardless of what they publicly say about their dedication to safety applied sciences. What is the really demonstrated downside for Kernel builders and the organizations that pay them, as far as I can inform there shouldn't be 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) [Hyperlink]



The important thing difficulty with this area is it relates to malicious faults. So, when consequences manifest themselves, it is just too late to act. And if the current commitment to a scarcity of voluntary technique persists, we are going to oscillate between phases of relaxed inconscience and anxious paranoia. Admittedly, kernel developpers seem fairly resistant to paranoia. That is an efficient thing. But I am ready for the times the place armed land-drones patrol US streets in the neighborhood of their kids faculties for them to find the feeling. They are not so distants the days when innocent lives will unconsciouly rely on the safety of (linux-based) pc methods; below water, that is already the case if I remember appropriately my final dive, as well as in several latest vehicles in accordance with some reviews.



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



Classic hosting corporations that use Linux as an uncovered front-end system are retreating from development while HPC, cell and "generic enterprise", i.E. RHEL/SLES, are pushing the kernel in their directions. This is actually not that stunning: For hosting needs the kernel has been "finished" for quite a while now. Apart from support for present hardware there is just not a lot use for newer kernels. Linux 3.2, and even older, works simply effective. Hosting doesn't need scalability to a whole bunch or hundreds of CPU cores (one uses commodity hardware), complicated instrumentation like perf or tracing (programs are locked down as much as doable) or superior power-management (if the system does not have fixed excessive load, it isn't making sufficient money). So why should internet hosting companies nonetheless make sturdy investments in kernel development? Even when that they had one thing to contribute, the hurdles for contribution have develop into higher and higher. For their security wants, hosting firms already use Grsecurity. I don't have any numbers, however some experience means that Grsecurity is principally a fixed requirement for shared hosting. However, kernel safety is sort of irrelevant on nodes of an excellent computer or on a system operating large enterprise databases that are wrapped in layers of center-ware. And cellular vendors merely don't 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) [Hyperlink]



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



The assembled doubtless recall that in August 2011, kernel.org was root compromised. I am sure the system's hard drives had been despatched off for forensic examination, and we've all been ready patiently for the answer to a very powerful question: What was the compromise vector? From shortly after the compromise was found on August 28, 2011, right by April 1st, 2013, kernel.org included this notice at the highest of the positioning News: 'Because of all to your patience and understanding during our outage and please bear with us as we bring up the different kernel.org systems over the next few weeks. We will probably be writing up a report on the incident sooner or later.' (Emphasis added.) That remark was removed (together with the remainder of the site Information) during a May 2013 edit, and there hasn't been -- to my information -- a peep about any report on the incident since then. This has been disappointing. When the Debian Challenge discovered sudden compromise of a number of of its servers in 2007, Wichert Akkerman wrote and posted an excellent public report on precisely what occurred. Likewise, the Apache Basis likewise did the right factor with good public autopsies of the 2010 Net site breaches. Arstechnica's Dan Goodin was still trying to observe up on the lack of an autopsy on the kernel.org meltdown -- in 2013. Two years ago. He wrote: Linux developer and maintainer Greg Kroah-Hartman advised Ars that the investigation has but to be completed and gave no timetable for when a report could be released. [...] Kroah-Hartman additionally informed Ars kernel.org methods had been rebuilt from scratch following the attack. Officials have developed new instruments and procedures since then, however he declined to say what they're. "There shall be a report later this year about site [sic] has been engineered, however don't quote me on when it will be launched as I'm not liable for it," he wrote. Who's accountable, then? Is anyone? Anyone? Bueller? Or is it a state secret, or what? Two years since Greg Okay-H mentioned there can be a report 'later this year', and four years for the reason that meltdown, nothing yet. How about some data? Rick Moen [email protected]



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



Much less critically, notice that if even the Linux mafia does not know, it must be the venusians; they're notoriously stealth in 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 which were put into place. There aren't any more shell logins, as a substitute every thing makes use of gitolite. The totally different companies are on totally different hosts. There are more kernel.org workers now. Persons are using two issue identification. Some other stuff. Do a search 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 said 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.internet, a few years prior, around 2002, and into many different shared Internet hosts for many years). But that isn't what is of major curiosity, and isn't what the forensic examine 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 take advantage of that to root access is presently unknown and is being investigated'. Okay, people, you've got now had four years of investigation. What was the path of escalation to root? (Also, other particulars that might logically be lined by a forensic study, resembling: Whose key was stolen? Who stole the key?) This is the kind of autopsy was promised prominently on the front web page of kernel.org, to reporters, and elsewhere for a very long time (and then summarily removed as a promise from the entrance page of kernel.org, with out comment, along with the remainder of the site Information section, and apparently dropped). It nonetheless could be appropriate to know and share that knowledge. Especially the datum of whether or not 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:42 UTC (Sun) by rickmoen (subscriber, #6943) [Link]



I've completed a more in-depth overview of revelations that got here out quickly after the break-in, and suppose I've discovered 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 general public was informed), plus Aug. Thirty first feedback to The Register's Dan Goodin by 'two safety researchers who have been briefed on the breach': Root escalation was by way of exploit of a Linux kernel security hole: Per the two security researchers, it was one both extremely embarrassing (wide-open access to /dev/mem contents including the working kernel's image in RAM, in 2.6 kernels of that day) and known-exploitable for the prior six years by canned 'sploits, one in every of which (Phalanx) was run by some script kiddie after entry using stolen dev credentials. Other tidbits: - Site admins left the root-compromised Internet servers operating with all companies still lit up, for multiple days. - Site admins and Linux Basis sat on the knowledge and failed to tell the public for those same a number of days. - Site admins and Linux Foundation have by no means revealed whether or not trojaned Linux supply tarballs have been posted within the http/ftp tree for the 19+ days earlier than they took the positioning down. (Sure, git checkout was fine, however what in regards to the 1000's of tarball downloads?) - After promising a report for several years after which quietly removing that promise from the front web page of kernel.org, Linux Basis now stonewalls press queries.I posted my best try at reconstructing the story, absent an actual report from insiders, to SVLUG's primary mailing checklist yesterday. (Necessarily, there are surmises. If the individuals with the details had been more forthcoming, we'd know what happened for sure.) I do have to wonder: If there's one other embarrassing screwup, will we even be instructed about it in any respect? Rick Moen [email protected]



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



Also, it's preferable to use live memory acquisition prior to powering off the system, in any other case you lose out on memory-resident artifacts which you can perform forensics on. -Brad



How in regards to the long overdue autopsy on the August 2011 kernel.org compromise?



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



Thanks to your feedback, Brad. I'd been counting on Dan Goodin's declare of Phalanx being what was used to gain root, within the bit the place he cited 'two safety researchers who had been briefed on the breach' to that effect. Goodin also elaborated: 'Fellow security 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 assault tool, and i noted that oddity in my posting to SVLUG. That having been mentioned, yeah, the Phalanx README doesn't specifically declare this, so then perhaps Goodin and his several 'security researcher' sources blew that detail, and no one however kernel.org insiders yet is aware of the escalation path used to achieve root. Also, it is preferable to make use of reside reminiscence acquisition previous to powering off the system, otherwise you lose out on reminiscence-resident artifacts you can carry out forensics on. Arguable, but a tradeoff; you possibly can poke the compromised stay system for state information, however with the drawback of leaving your system running under hostile control. I was always taught that, on stability, it is better to tug energy to end the intrusion. Rick Moen [email protected]



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



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



With "one thing" you mean those that produce those closed source drivers, proper? If the "consumer product corporations" just caught to utilizing components with mainlined open source drivers, then updating their products could be a lot easier.



A new Mindcraft moment?



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



They've ring zero privilege, can entry protected memory immediately, and can't be audited. Trick a kernel into operating a compromised module and it is sport over. Even tickle a bug in a "good" module, and it's in all probability game over - on this case quite literally as such modules are usually video drivers optimised for games ...