Notes

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

1. this WP article was the 5th in a series of articles following the safety of the internet from its beginnings to relevant subjects of right now. discussing the security of linux (or lack thereof) suits nicely in there. it was additionally a well-researched article with over two months of research and interviews, one thing you cannot quite declare yourself to your latest pieces on the subject. you don't just like the facts? then say so. and even better, do something constructive about them like Kees and others have been making an attempt. nonetheless foolish comparisons to outdated crap like the Mindcraft research and fueling conspiracies do not exactly help your case.
2. "We do an inexpensive job of finding and fixing bugs."
let's start right here. is this statement based mostly on wishful pondering or chilly hard information you are going to share in your response? in accordance with Kees, the lifetime of safety bugs is measured in years. that is more than the lifetime of many devices people purchase and use and ditch in that interval.
3. "Problems, whether they are security-associated or not, are patched shortly,"
some are, some aren't: let's not forget the latest NMI fixes that took over 2 months to trickle all the way down to stable kernels and we even have a person who has been ready for over 2 weeks now: http://thread.gmane.org/gmane.comp.file-methods.btrfs/49500 (FYI, the overflow plugin is the primary one Kees is making an attempt to upstream, imagine the shitstorm if bugreports might be treated with this attitude, let's hope btrfs guys are an exception, not the rule). anyway, two examples are usually not statistics, so once again, do you've numbers or is it all wishful thinking? (it is partly a trick query because you will even have to elucidate how something gets to be determined to be security related which as everyone knows is a messy business within the linux world)
4. "and the stable-replace mechanism makes those patches accessible to kernel users."
besides when it doesn't. and yes, i've numbers: grsec carries 200+ backported patches in our 3.14 stable tree.
5. "In particular, the few builders who're working in this area have never made a severe attempt to get that work built-in upstream."
you don't have to be shy about naming us, in spite of everything you probably did so elsewhere already. and we additionally defined the the explanation why we have not pursued upstreaming our code: https://lwn.internet/Articles/538600/ . since i don't anticipate you and your readers to learn any of it, here's the tl;dr: if you want 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's how the world works, that is how >90% of linux code gets in too. i personally discover it fairly hypocritic that well paid kernel developers are bitching about our unwillingness and inability to serve them our code on a silver platter at no cost. and earlier than somebody brings up the CII, go verify their mail archives, after some initial exploratory discussions i explicitly asked them about supporting this long drawn out upstreaming work and obtained no solutions.

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

Cash (aha) quote :
> I suggest you spend none of your free time on this. Zero. I suggest you get paid to do that. And effectively.
Nobody expect you to serve your code on a silver platter at no cost. The Linux foundation and huge firms using Linux (Google, Pink Hat, Oracle, Samsung, and so forth.) should pay safety specialists such as you to upstream your patchs.

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

I would simply prefer to point out that the way you phrased this makes your remark a tone argument[1][2]; you've (probably unintentionally) dismissed the entire parent's arguments by pointing at its presentation. The tone of PAXTeam's comment displays the frustration built up over the years with the way in which things work which I think ought to be taken at face worth, empathized with, and understood relatively than merely dismissed.
1. http://rationalwiki.org/wiki/Tone_argument
2. http://geekfeminism.wikia.com/wiki/Tone_argument
Cheers,

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

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

why, is upstream known for its primary civility and decency? have you ever even learn the WP put up below discussion, never mind past lkml site visitors?

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

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

No Argument

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

Please do not; it doesn't belong there both, and it particularly would not need a cheering part as the tech press (LWN generally excepted) tends to provide.

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

Ok, however I was thinking of Linus Torvalds

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

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

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

Why should you assume only money will repair this drawback? Yes, I agree extra sources ought to be spent on fixing Linux kernel safety issues, but don't assume somebody giving a company (ahem, PAXTeam) money is the only answer. (Not mean to impugn PAXTeam's security efforts.)

The Linux improvement community could have had the wool pulled over its collective eyes with respect to safety issues (both real or perceived), however merely throwing cash at the issue won't fix this.

And sure, I do realize the business Linux distros do tons (most?) of the kernel growth nowadays, and that implies oblique financial transactions, but it is a lot more concerned than just that.

Posted Nov 7, 2015 0:36 UTC (Sat) by PaXTeam (visitor, #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:Thirteen UTC (Fri) by dowdle (subscriber, #659) [Link]

I think you undoubtedly agree with the gist of Jon's argument... not enough focus has been given to security within the Linux kernel... the article will get that half proper... money hasn't been going in direction of security... and now it must. Aren't you glad?

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

they talked to spender, not me personally, however sure, this side of the coin is properly represented by us and others who had been interviewed. the same approach Linus is a good consultant of, well, his personal pet mission known as linux.
> And if Jon had only talked to you, his would have been too.
provided that i am the author of PaX (a part of grsec) yes, speaking to me about grsec matters makes it the most effective methods to analysis it. but if you realize of another person, be my visitor and name them, i'm pretty certain the just lately formed kernel self-protection folks can be dying to engage them (or not, i don't suppose there's a sucker out there with 1000's of hours of free time on their hand).
> [...]it additionally contained fairly a number of of groan-worthy statements.
nothing is ideal but considering the viewers of the WP, that is considered one of the higher journalistic pieces on the topic, regardless of how you and others don't like the sorry state of linux security exposed in there. if you'd like to debate extra technical particulars, nothing stops you from speaking to us ;).
speaking of your complaints about journalistic qualities, since a earlier LWN article noticed it match to incorporate several typical dismissive claims by Linus about the standard of unspecified grsec options with no evidence of what expertise he had with the code and the way recent it was, how come we didn't see you or anybody else complaining about the quality of that article?
> Aren't you glad?
no, or not but anyway. i've heard a number of 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) [Hyperlink]

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

Proper now we have got builders from massive names saying that doing all that the Linux ecosystem does *safely* is an itch that they have. Unfortunately, the encircling cultural attitude of developers is to hit useful targets, and sometimes performance goals. Safety objectives are sometimes neglected. Ideally, the tradition would shift so that we make it troublesome to comply with insecure habits, patterns or paradigms -- that could be a process that will take a sustained effort, not merely the upstreaming of patches.
Regardless of the culture, these patches will go upstream finally anyway as a result of the ideas that they embody are actually well timed. I can see a way to make it occur: Linus will settle for them when a big end-person (say, Intel, Google, Fb or Amazon) delivers stuff with notes like 'this is a set of enhancements, we're already utilizing them to unravel this type of problem, here is how every little thing will stay working because $proof, observe carefully that you're staring down the barrels of a fork as a result of your tree is now evolutionarily disadvantaged'. It is a sport and might be gamed; I might choose that the community shepherds customers to comply with the pattern of declaring problem + solution + functional test proof + performance test proof + safety take a look at evidence.
K3n.

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

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

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

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

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

So I need to confess to a specific amount of confusion. I might swear that the article I wrote stated exactly that, however you have put a good amount of effort into flaming it...?

Posted Nov 8, 2015 1:34 UTC (Solar) 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 means and fundamental civility.

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

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

I hope I am flawed, but a hostile attitude is not going to assist anyone receives a commission. It is a time like this where one thing you seem to be an "knowledgeable" at and there is a demand for that expertise the place you display cooperation and willingness to participate as a result of it's an opportunity. I'm comparatively shocked that somebody doesn't get that, but I am older and have seen a couple of of those alternatives in my profession and exploited the hell out of them. You only get just a few of these in the average profession, and handful at the most.
Sometimes it's a must to invest in proving your skills, and that is a type of moments. It seems the Kernel community may finally take this security lesson to heart and embrace it, as mentioned within the article as a "mindcraft second". This is a chance for developers that will wish to work on Linux security. Some will exploit the opportunity and others will thumb their noses at it. In the end these builders that exploit the chance will prosper from it.
I feel outdated even having to put in writing that.

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

Maybe there's a hen and egg downside here, however when searching for out and funding individuals to get code upstream, it helps to pick out folks and teams with a historical past of being able to get code upstream.
It is perfectly reasonable to favor working out of tree, offering the flexibility to develop impressive and significant security advances unconstrained by upstream requirements. That is work somebody might also want to fund, if that meets their wants.

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

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

You make this argument (implying you do analysis and Josh would not) and then fail to help it by any cite. It could be rather more convincing if you happen to give up on the Onus probandi rhetorical fallacy and really cite information.
> living proof, it was *them* who steered that they wouldn't fund out-of-tree work but would consider funding upstreaming work, besides when pressed for the main points, all i got was silence.
For these following alongside at home, that is the related set of threads:
http://lists.coreinfrastructure.org/pipermail/cii-focus on...
A quick precis is that they instructed you your mission was unhealthy as a result of the code was never going upstream. You told them it was due to kernel builders perspective so they should fund you anyway. They informed you to submit a grant proposal, you whined extra in regards to the kernel attitudes and finally even your apologist advised you that submitting a proposal may be the best thing to do. At that point you went silent, not vice versa as you imply above.
> obviously i will not spend time to write down up a begging proposal simply to be instructed that 'no sorry, we do not fund multi-year projects at all'. that is something that one must be told in advance (or heck, be a part of some public rules so that others will know the principles too).
You seem to have a fatally flawed grasp of how public funding works. If you do not tell individuals why you need the cash and how you'll spend it, they're unlikely to disburse. Saying I'm good and I know the issue now hand over the money does not even work for many Academics who've a stable 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 test the kernel git logs (minus the stuff that was not correctly credited)?
jejb@jarvis> git log|grep -i 'Writer: pax.*group'|wc -l
1
Stellar, I have to say. And earlier than you gentle off on these who've misappropriated your credit score, please do not forget that getting code upstream on behalf of reluctant or incapable actors is a vastly worthwhile and time consuming ability and one in all the reasons groups like Linaro exist and are effectively funded. If extra of your stuff does go upstream, it is going to be due to the not inconsiderable efforts of other folks on this area.
You now have a enterprise model selling non-upstream security patches to customers. There's nothing unsuitable with that, it is a reasonably common first stage enterprise mannequin, however it does rather depend upon patches not being upstream in the primary place, calling into query the earnestness of your attempt to place them there.
Now this is some free advice in my discipline, which is aiding firms align their businesses in open supply: The promoting out of tree patch route is all the time an eventual failure, particularly with the kernel, because if the performance is that helpful, it will get upstreamed or reinvented in your despite, leaving you with nothing to promote. If your marketing strategy B is promoting expertise, you have got to keep in mind that it's going to be a tough sell when you've got no out of tree differentiator left and git history denies that you simply had anything to do with the in-tree patches. Actually "crazy security individual" will turn out to be a self fulfilling prophecy. The recommendation? it was apparent to everybody else who read this, but for you, it is do the upstreaming yourself before it will get performed for you. That approach you may have a reliable historic declare to Plan B and you may actually have a Plan A promoting a rollup of upstream monitor 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 anyplace. Your alternative is to proceed taking part in the position of Cassandra and possibly suffer her eventual destiny.

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

> Second, for the probably viable items this can be a multi-12 months
> full time job. Is the CII willing to fund projects at that level? If not
> all of us would find yourself with numerous unfinished and partially broken features.
please show me the reply to that query. and not using a definitive 'sure' there is no such thing as a point 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 could be shot down immediately and be a waste of my time. and i stand by my declare that such simple fundamental necessities ought to be public information.
> Stellar, I need to say.
"Lies, damned lies, and statistics". you realize there's multiple strategy to get code into the kernel? how about you employ your git-fu to search out all of the bugreports/prompt fixes that went in as a consequence of us? as for particularly me, Greg explicitly banned me from future contributions through af45f32d25cc1 so it's no surprise i do not send patches directly in (and that one commit you found that went in regardless of said ban is actually a really unhealthy instance because it is also the one which Linus censored for no good purpose and made me decide to by no means send safety fixes upstream till that observe adjustments).
> You now have a enterprise model selling non-upstream security patches to clients.
now? we have had paid sponsorship for our numerous stable kernel collection for 7 years. i would not name it a business model though as it hasn't paid anyone's payments.
> [...]calling into query the earnestness of your try to place them there.
i should be missing one thing here however what try? i've by no means in my life tried to submit PaX upstream (for all the explanations mentioned already). the CII mails have been exploratory to see how critical that complete group is about truly securing core infrastructure. in a way i've got my solutions, there's nothing more to the story.
as for your free recommendation, let me reciprocate: complicated problems do not solve themselves. code fixing complicated problems doesn't write itself. people writing code solving complicated issues are few and much between that you will see that out briefly order. such people (domain consultants) do not work for free with few exceptions like ourselves. biting the hand that feeds you will solely finish you up in starvation.
PS: since you are so sure about kernel developers' ability to reimplement our code, perhaps look at what parallel options i still maintain in PaX despite vanilla having a 'completely-not-reinvented-right here' implementation and check out to know the rationale. or simply have a look at all the CVEs that affected say vanilla's ASLR but didn't affect mine.
PPS: Cassandra by no means wrote code, i do. criticizing the sorry state of kernel security is a aspect project when i am bored or simply waiting for the following kernel to compile (i wish LTO was more environment friendly).

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

In other phrases, you tried to define their course of for them ... I am unable to assume why that would not work.
> "Lies, damned lies, and statistics".
The issue with ad hominem assaults is that they're singularly ineffective against a transparently factual argument. I posted a one line command anyone might run to get the number of patches you've authored in the kernel. Why do not you put up an equal that provides figures you like extra?
> i've by no means in my life tried to submit PaX upstream (for all the reasons mentioned already).
So https://fakeroot.net/ is to demonstrate your expertise by the variety of patches you haven't submitted? great plan, world domination beckons, sorry that one received away from you, but I'm certain you won't let it occur again.

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

what? since when does asking a query define something? is not that how we find out what another person thinks? isn't that what *they* have that webform (never mind the mailing lists) for as effectively? in other words you admit that my query was not truly answered .
> The problem with ad hominem assaults is that they are singularly ineffective towards a transparently factual argument.
you didn't have an argument to begin with, that is what i defined within the part you fastidiously selected to not quote. i am not here to defend myself against your clearly idiotic attempts at proving no matter you're making an attempt to show, as they say even in kernel circles, code speaks, bullshit walks. you possibly can have a look at mine and determine what i can or can not do (not that you've got the information to understand most of it, thoughts you). that stated, there're clearly different extra succesful individuals who've accomplished 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 might appear to you, life does not revolve across the vanilla kernel, not everyone's dying to get their code in there especially when it means to put up with such silly hostility on lkml that you simply now additionally demonstrated right here (it's ironic the way you came to the protection of josh who specifically asked folks to not bring that infamous lkml style here. good job there James.). as for world domination, there're many ways to achieve it and something tells me that you're clearly out of your league right here since PaX has already achieved that. you're operating such code that implements PaX features as we communicate.

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

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

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

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

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

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

anyway, since it's you guys who have a bee in your bonnet, let's check your level of intelligence too. first figure out my e mail address and mission title then try to search out the commits that say they arrive from there (it brought back some reminiscences from 2004 already, how instances flies! i'm shocked i actually managed to accomplish this a lot with explicitly not making an attempt, imagine if i did :). it is an incredibly complex process so by engaging in it you will prove your self to be the highest canine right here on lwn, whatever that is worth ;).

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

*shrug* Or do not; you're only sullying your own repute.

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

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

I would not 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 (Solar) by PaXTeam (guest, #24616) [Hyperlink]

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

Ah. I thought my memory wasn't failing me. Examine to PaXTeam's response to .
PaXTeam is not averse to outright mendacity if it means he gets to look right, I see. Perhaps PaXTeam's memory is failing, and this obvious contradiction isn't a brazen lie, however provided that the two posts have been made inside a day of one another I doubt it. (PaXTeam's whole unwillingness to assume good religion in others deserves some reflection. Yes, I *do* suppose he is 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 something *is* at stake. Gosh I ponder why his fixes aren't going upstream very fast.)

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

> and that one commit you discovered that went in despite mentioned ban
additionally somebody's ban does not imply it will translate into another person's execution of that ban as it's clear from the commit in question. it is considerably sad that it takes a safety repair to expose the fallacy of this policy although. the rest of your pithy ad hominem speaks for itself higher than i ever could ;).

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

I don't see this message in my mailbox, so presumably it acquired swallowed.

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

You are aware that it is solely doable that everyone is improper right here , proper?
That the kernel maintainers must focus extra on safety, that the article was biased, that you are irresponsible to decry the state of safety, and do nothing to assist, and that your patchsets would not assist that much and are the mistaken route for the kernel? That just because the kernel maintainers aren't 100% right it doesn't suggest you are?

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

I feel you might have him backwards there. Jon is comparing this to Mindcraft as a result of he thinks that despite being unpalatable to plenty of the neighborhood, the article might in actual fact include a whole lot of truth.

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 dark forces that drove the article within the hopes of taking Linux down a notch. All of this might nicely be true"
Simply as you criticized the article for mentioning Ashley Madison regardless that within the very first sentence of the next paragraph it mentions it did not contain the Linux kernel, you cannot give credence to conspiracy theories without incurring the same criticism (in different words, you cannot play the Glenn Beck "I am simply asking the questions here!" whose "questions" fuel the conspiracy theories of others). Much like mentioning Ashley Madison for instance for non-technical readers in regards to the prevalence of Linux in the world, if you're criticizing the mention then should not likening a non-FUD article to a FUD article also deserve criticism, particularly given the rosy, self-congratulatory image you painted of upstream Linux safety?
As the PaX Group identified within the preliminary submit, the motivations aren't laborious to know -- you made no mention in any respect about it being the fifth in a protracted-running sequence following a pretty predictable time trajectory.
No, we didn't miss the overall analogy you had been attempting to make, we just 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) [Hyperlink]

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

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

Sadly, I do not perceive neither the "security" people (PaXTeam/spender), nor the mainstream kernel people when it comes to their attitude. I confess I have completely no technical capabilities on any of those matters, but if all of them decided to work collectively, as an alternative of getting infinite and pointless flame wars and blame sport exchanges, plenty of the stuff would have been completed already. And all of the while everyone concerned might have made another big pile of money on the stuff. All of them appear to wish to have a better Linux kernel, so I've acquired no idea what the problem is. Plainly nobody 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 way into forcing the opposite aspect to quit. Which, after all, by no means works - it just causes extra 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 hole", for example. You'd probably want most of the security stuff turned off on it to achieve most efficiency, because you may trust all users. Now take a few billion mobile phones which may be difficult or sluggish to patch. You'd probably wish to kill lots of the exploit classes there, if these units can nonetheless run moderately effectively with most security options turned on.
So, it's not either/or. It is in all probability "it relies upon". However, if the stuff isn't there for everybody to compile/use in the vanilla kernel, it will be harder to make it a part of everyday decisions for distributors and customers.

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

How sad. This Dijkstra quote comes to thoughts instantly:
Software program engineering, after all, presents itself as another worthy cause, but that is eyewash: in case you carefully read its literature and analyse what its devotees really do, you will uncover that software engineering has accepted as its charter "The way to program if you can't."

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

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

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

Certainly. And the interesting factor to me is that when I reach that time, tests usually are not adequate - mannequin checking at a minimal and really proofs are the only approach forwards. I'm no safety professional, my field is all distributed programs. I perceive and have carried out Paxos and i consider I can explain how and why it really works to anybody. However I am at the moment doing a little algorithms combining Paxos with a bunch of variations on VectorClocks and reasoning about causality and consensus. No test is adequate as a result of there are infinite interleavings of occasions and my head simply couldn't cope with working on this both at the computer or on paper - I discovered I could not intuitively reason about these items at all. So I began defining the properties and wished and step by step proving why each of them holds. Without my notes and proofs I am unable to even clarify to myself, not to mention anyone else, why this thing works. I find this each utterly obvious that this could occur and totally terrifying - the upkeep value of those algorithms is now an order of magnitude greater.

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

> Indeed. And the attention-grabbing factor to me is that when I attain that point, tests are usually not sufficient - mannequin checking at a minimum and really proofs are the only way forwards.
Or are you simply using the flawed maths? Hobbyhorse time again :-) but to quote a fellow Decide developer ... "I usually walk into a SQL development shop and see that wall - you recognize, the one with the large SQL schema that no-one absolutely understands on it - and marvel how I can easily hold the entire schema for a Pick database of the identical or larger complexity in my head".
But it is easy - by training I am a Chemist, by interest a Bodily Chemist (and by profession an unemployed programmer :-). And when I'm serious about chemistry, I can ask myself "what is an atom fabricated from" and suppose about things like the robust nuclear force. Subsequent stage up, how do atoms stick collectively and make molecules, and suppose concerning the electroweak force and electron orbitals, and how do chemical reactions occur. Then I believe about molecules stick together to make materials, and assume about metals, and/or Van de Waals, and stuff.
Point is, it's worthwhile to *layer* stuff, and look at things, and say "how can I split elements off into 'black packing containers' so at anyone level I can assume the opposite ranges 'just work'". For example, with Choose a FILE (table to you) shops a class - a set of identical objects. One object per Document (row). And, identical as relational, one attribute per Discipline (column). Are you able to map your relational tables to reality so simply? :-)
Going again THIRTY years, I remember a story about a man who constructed little computer crabs, that would fairly happily scuttle around in the surf zone. Because he didn't try to work out how to solve all the issues at once - every of his (incredibly puny by as we speak's requirements - this is the 8080/Z80 era!) processors was set to only course of a bit bit of the problem and there was no central "mind". However it worked ... Maybe it is best to just write a bunch of small modules to unravel each individual problem, and let final reply "simply happen".
Cheers,
Wol

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

To my understanding, this is precisely what a mathematical abstraction does. For instance in Z notation we might construct schemas for the various modifying ("delta") operations on the base schema, after which argue about preservation of formal invariants, properties of the result, and transitivity of the operation when chained with itself, or the preceding aggregate schema composed of schemas A by way of O (for which they've been already argued).
The end result is a set of operations that, executed in arbitrary order, result in a set of properties holding for the consequence and outputs. Thus proving the formal design right (w/ caveat lectors concerning scope, correspondence with its implementation [though that may be proven as nicely], and browse-only ["xi"] operations).

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

Trying via the history of computing (and probably plenty of other fields too), you'll probably find that individuals "cannot see the wood for the timber" extra usually that not. They dive into the detail and utterly miss the large image.
(Medicine, and curiosity of mine, suffers from that too - I remember any person speaking about the consultant eager to amputate a gangrenous leg to save someone's life - oblivious to the truth 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 Thought of Dangerous")
FWIW, I believe that this speak is very relevant to why writing safe software program is so hard..
-Dave.

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

While we are spending thousands and thousands at a multitude of safety issues, kernel points aren't on our prime-precedence record. Truthfully I remember solely once having discussing a kernel vulnerability. The results of the analysis has been that all our programs were working kernels that were older because the kernel that had the vulnerability.
However "patch administration" is an actual difficulty for us. Software program must continue to work if we install security patches or replace to new releases due to the top-of-life policy of a vendor. The revenue of the company is depending on the IT techniques operating. So "not breaking consumer house" is a safety function for us, as a result of a breakage of 1 component of our a number of ten thousands of Linux techniques will cease the roll-out of the security replace.
Another problem is embedded software program or firmware. Today almost all hardware systems embody an operating system, often some Linux model, providing a fill network stack embedded to assist distant administration. Repeatedly those systems don't survive our obligatory security scan, as a result of vendors still did not update the embedded openssl.
The real problem is to provide a software program stack that can be operated within the hostile environment of the Internet sustaining full system integrity for ten years and even longer without any buyer upkeep. The current state of software program engineering would require help for an automatic replace course of, but distributors must perceive that their business model should be capable of finance the assets offering the updates.
Overall I'm optimistic, networked software program just isn't the first know-how used by mankind causing problems that had been addressed later. Steam engine use could result in boiler explosions however the "engineers" have been ready to cut back this danger considerably over a few many years.

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

The following is all guess work; I would be eager to know if others have proof either a technique or another on this: The individuals who learn how to hack into these programs by means of kernel vulnerabilities know that they expertise they've learnt have a market. Thus they do not tend to hack in order to wreak havoc - indeed on the entire where knowledge has been stolen with the intention to release and embarrass people, it _seems_ as though those hacks are through much easier vectors. I.e. lesser skilled hackers find there's a whole load of low-hanging fruit which they will get at. They're not being paid ahead of time for the info, so that they flip to extortion as an alternative. They do not cover their tracks, and they will often be found and charged with criminal offences.
So if your security meets a sure fundamental level of proficiency and/or your company is not doing something that places it close to the highest of "corporations we might prefer to embarrass" (I believe the latter is way more effective at holding methods "protected" than the former), then the hackers that get into your system are likely to be expert, paid, and doubtless not going to do a lot injury - they're stealing data for a competitor / state. So that does not hassle your backside line - a minimum of not in a means which your shareholders will be aware of. So why fund safety?

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

On the other hand, some effective mitigation in kernel degree could be very useful to crush cybercriminal/skiddie's strive. If considered one of your buyer operating a future trading platform exposes some open API to their purchasers, and if the server has some reminiscence corruption bugs could be exploited remotely. Then you already know there are known assault strategies( similar to offset2lib) may also help the attacker make the weaponized exploit a lot easier. Will you clarify the failosophy "A bug is bug" to your customer and tell them it'd be okay? Btw, offset2lib is ineffective to PaX/Grsecurity's ASLR imp.
To the most industrial makes use of, more security mitigation within the software will not cost you extra finances. You will nonetheless need to do the regression test for every upgrade.

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

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

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

I keep studying this headline as "a new Minecraft moment", and considering that possibly they've determined to comply with up the .Internet thing by open-sourcing Minecraft. Oh nicely. I mean, security is sweet too, I assume.

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

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

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

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

Posted Nov 9, 2015 15:Fifty three 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 thanks to the other remark thread that identified the 'd', not 'e'.)

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

I'd similar to so as to add that for my part, there's a common downside with the economics of laptop safety, which is particularly seen presently. Two issues even maybe.
First, the money spent on laptop security is commonly diverted in the direction of the so-called safety "circus": fast, straightforward solutions that are primarily selected simply in an effort to "do one thing" and get better press. It took me a long time - possibly a long time - to say that no safety mechanism at all is best than a foul mechanism. But now I firmly believe in this angle and would reasonably take the danger knowingly (supplied that I can save cash/useful resource for myself) than take a nasty approach at solving it (and have no money/useful resource left when i realize I ought to have done one thing else). And that i discover there are numerous unhealthy or incomplete approaches at present available in the pc safety subject.
Those spilling our uncommon money/sources on prepared-made ineffective instruments ought to get the dangerous press they deserve. And, we certainly need to enlighten the press on that as a result of it isn't so easy to understand the effectivity of protection mechanisms (which, by definition, ought to stop issues from occurring).
Second, and which may be more recent and more worrying. The flow of cash/useful resource is oriented in the path of assault tools and vulnerabilities discovery a lot more than in the course of recent protection mechanisms.
This is especially worrying as cyber "defense" initiatives look increasingly like the usual idustrial initiatives geared toward producing weapons or intelligence techniques. Furthermore, unhealthy useless weapons, because they are solely working towards our very susceptible current methods; and dangerous intelligence systems as even fundamental college-degree encryption scares them all the way down to useless.
However, all the ressources are for these grownup teenagers taking part in the white hat hackers with not-so-troublesome programming methods or network monitoring or WWI-stage cryptanalysis. And now additionally for the cyberwarriors and cyberspies which have but to show their usefulness solely (especially for peace safety...).
Personnally, I would fortunately go away them all of the hype; but I'll forcefully declare that they have no right in any way on any of the price range allocation decisions. Only these working on protection should. And yep, it means we should always resolve the place to place there assets. We have now to say the unique lock for ourselves this time. (and I guess the PaXteam could possibly be among the first to benefit from such a change).
Whereas excited about it, I wouldn't even go away white-hat or cyber-guys any hype in the long run. That is extra publicity than they deserve.
I crave for the day I'll read within the newspaper that: "One other of those ailing suggested debutant programmer hooligans that pretend to be cyber-pirates/warriors modified some well known virus program code exploiting a programmer mistake and managed nevertheless to carry one of those unfinished and bad high quality packages, X, that we're all obliged to make use of to its knees, annoying thousands and thousands of standard customers with his unlucky cyber-vandalism. All of the protection consultants unanimously suggest that, as soon as once more, the price range of the cyber-command be retargetted, or not less than leveled-off, in an effort to carry more safety engineer positions in the tutorial area or civilian industry. 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 nicely to the battlefield-oriented variant.

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

The state of 'software program safety business' is a f-ng disaster. Failure of the very best order. There is massive amounts of cash that is going into 'cyber security', however it's usually spent on government compliance and audit efforts. This implies as a substitute of really putting effort into correcting points and mitigating future problems, nearly all of the hassle goes into taking present purposes and making them conform to committee-pushed tips with the minimal amount of effort and changes.
Some level of regulation and standardization is completely needed, but lay individuals are clueless and are completely unable to discern the difference between any person who has worthwhile expertise versus some firm that has spent hundreds of thousands on slick advertising and marketing and 'native promoting' on massive websites and laptop magazines. The people with the cash sadly solely have their own judgment to depend on when shopping for into 'cyber safety'.
> Those spilling our rare money/sources on prepared-made ineffective instruments should get the dangerous press they deserve.
There isn't a such thing as 'our rare cash/resources'. You have your money, I have mine. Money being spent by some corporation like Redhat is their cash. Cash being spent by governments is the government's cash. (you, literally, have far more control in how Walmart spends it is money then over what your authorities does with their's)
> This is very worrying as cyber "protection" initiatives look an increasing number of like the same old idustrial projects geared toward producing weapons or intelligence methods. Moreover, dangerous ineffective weapons, as a result of they are solely working against our very susceptible current techniques; and bad intelligence programs as even fundamental college-level encryption scares them all the way down to ineffective.
Having secure software with robust encryption mechanisms within the hands of the general public runs counter to the pursuits of most main governments. Governments, like every other for-profit organization, are primarily taken with self-preservation. Money spent on drone initiatives or banking auditing/oversight regulation compliance is Much more precious to them then making an attempt to help the public have a secure mechanism for making phone calls. Particularly when these secure mechanisms interfere with information assortment efforts.
Unfortunately you/I/us can't depend on some magical benefactor with deep pockets to sweep in and make Linux higher. It is simply not going to occur.
Firms like Redhat have been massively useful to spending assets to make Linux kernel more succesful.. nevertheless they're driven by a the need to turn a revenue, which suggests they need to cater on to the the sort of necessities established by their customer base. Customers for EL are usually rather more targeted on decreasing costs associated with administration and software program improvement then security on the low-degree OS.
Enterprise Linux customers tend to rely on bodily, human coverage, and network security to protect their 'gentle' interiors from being exposed to external threats.. assuming (rightly) that there's very little they can do to truly harden their techniques. In reality when the choice comes between security vs convenience I am certain that almost all prospects will happily defeat or strip out any safety mechanisms introduced into Linux.
On high of that when most Enterprise software program is extraordinarily bad. So much in order that 10 hours spent on enhancing an internet front-finish will yield extra real-world safety advantages then a 1000 hours spent on Linux kernel bugs for many businesses.
Even for 'normal' Linux users a security bug in their Firefox's NAPI flash plugin is much more devastating and poses a massively larger risk then a obscure Linux kernel buffer over movement problem. It is just not likely important for attackers to get 'root' to get entry to the essential data... typically all of which is contained in a single user account.
Ultimately it's up to people such as you and myself to place the trouble and cash 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 due to unhealthy religion. And this is mostly your money or mine: both tax-fueled governemental assets or company prices which are instantly reimputed on the costs of goods/software program we are instructed we are *obliged* to buy. (Take a look at company firewalls, dwelling alarms or antivirus software advertising discourse.)
I feel it is time to point out that there are several "malicious malefactors" around and that there is a real must identify and sanction them and confiscate the assets they have somehow managed to monopolize. And i do *not* assume Linus is among such culprits by the best way. However I believe he may be amongst the ones hiding their heads within the sand concerning the aforementioned evil actors, whereas he probably has extra leverage to counteract them or oblige them to reveal themselves than many people.
I find that to be of brown-paper-bag level (though head-in-the-sand is in some way a brand new interpretation).
In the long run, I feel you're proper to say that at the moment it is solely as much as us people to attempt truthfully to do one thing to improve Linux or pc safety. But I nonetheless suppose that I am proper to say that this is not regular; particularly while some very severe people get very critical salaries to distribute randomly some difficult to guage budgets.
[1] A paradoxical state of affairs once you think about it: in a website the place you're initially preoccupied by malicious individuals everyone ought to have factual, transparent and honest conduct as the first priority in their mind.

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

It even has a nice, seven line Primary-pseudo-code that describes the current situation and clearly reveals that we're caught in an infinite loop. It does not answer the massive query, although: How to jot down higher software program.
The sad factor is, that that is from 2005 and all of the things that have been obviously silly ideas 10 years in the past have proliferated even more.

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

Observe IMHO, we must always investigate additional why these dumb issues proliferate and get so much assist.
If it's only human psychology, properly, let's battle it: e.g. Mozilla has proven us that they can do fantastic things given the right message.
If we are dealing with lively individuals exploiting public credulity: let's determine and battle them.
However, extra importantly, let's capitalize on this data and safe *our* systems, to exhibit at a minimal (and extra later on after all).
Your reference conclusion is very nice to me. "challenge [...] the conventional wisdom and the established order": that job I would happily accept.

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

That rant is itself a bunch of "empty calories". The converse to the items it rants about, which it is suggesting at some level, would be as dangerous or worse, and indicative of the worst type of security thinking that has put a lot of people off. Alternatively, it's just a rant that gives little of worth.
Personally, I believe there is not any magic bullet. Security is and at all times has been, in human historical past, an arms race between defenders and attackers, and one that's inherently a trade-off between usability, dangers and costs. If there are mistakes being made, it's that we must always most likely spend more assets on defences that could block total courses of assaults. E.g., why is the GRSec kernel hardening stuff so exhausting to apply to regular distros (e.g. there isn't any dependable source of a GRSec kernel for Fedora or RHEL, is there?). Why does all the Linux kernel run in one safety context? Why are we nonetheless writing a number of software in C/C++, typically without any primary safety-checking abstractions (e.g. basic bounds-checking layers in between I/O and parsing layers, say)? Can hardware do extra to provide safety with pace?
Little doubt there are loads of individuals working on "block courses of attacks" stuff, the query is, why aren't there extra sources directed there?

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

>There are numerous reasons why Linux lags behind in defensive security applied sciences, however one of the key ones is that the companies making money on Linux have not prioritized the event and integration of these applied sciences.
This looks like a cause which is de facto price exploring. Why is it so?
I feel it is not apparent why this doesn't get some more consideration. Is it doable that the individuals with the money are right to not more extremely prioritise this? Afterall, what curiosity have they got in an unsecure, exploitable kernel? The place there may be widespread cause, linux development will get resourced. It's been this way for a few years. If filesystems qualify for widespread interest, surely security does. So there does not seem to be any obvious motive why this issue does not get extra mainstream attention, except that it really already will get sufficient. It's possible you'll say that disaster has not struck but, that the iceberg has not been hit. Nevertheless it appears to be that the linux improvement course of will not be overly reactive elsewhere.

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

That is an interesting query, definitely that is what they really imagine regardless of what they publicly say about their commitment to security technologies. What's the truly demonstrated downside for Kernel builders and the organizations that pay them, so far as I can inform there isn't ample consequence for the lack of Safety to drive more 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 subject with this area is it relates to malicious faults. So, when penalties manifest themselves, it is too late to act. And if the present dedication to a lack of voluntary strategy persists, we are going to oscillate between phases of relaxed inconscience and anxious paranoia.
Admittedly, kernel developpers appear fairly resistant to paranoia. That is an efficient factor. However I am ready for the times where armed land-drones patrol US streets within the neighborhood of their kids schools for them to find the feeling. They are not so distants the days when innocent lives will unconsciouly depend on the safety of (linux-based mostly) laptop systems; underneath water, that's already the case if I remember accurately my final dive, as well as in a number of latest vehicles in line with some experiences.

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

Classic hosting corporations that use Linux as an uncovered entrance-end system are retreating from development while HPC, mobile and "generic enterprise", i.E. RHEL/SLES, are pushing the kernel in their directions.
This is absolutely not that stunning: For hosting needs the kernel has been "finished" for quite some time now. Moreover help for current hardware there just isn't much use for newer kernels. Linux 3.2, and even older, works simply fine.
Hosting doesn't want scalability to a whole lot or 1000's of CPU cores (one uses commodity hardware), advanced instrumentation like perf or tracing (systems are locked down as much as possible) or advanced power-administration (if the system doesn't have constant high load, it is not making enough money). So why ought to internet hosting firms nonetheless make sturdy investments in kernel development? Even if they'd something to contribute, the hurdles for contribution have turn into increased and higher.
For his or her security wants, hosting firms already use Grsecurity. I don't have any numbers, however some experience suggests that Grsecurity is principally a fixed requirement for shared internet hosting.
Alternatively, kernel safety is nearly 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 vendors simply 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 positive the system's hard drives were despatched off for forensic examination, and we've all been ready patiently for the reply to a very powerful question: What was the compromise vector? From shortly after the compromise was found on August 28, 2011, right by means of April 1st, 2013, kernel.org included this be aware at the top of the positioning News: 'Because of all on your patience and understanding during our outage and please bear with us as we bring up the completely different kernel.org methods over the subsequent few weeks. We can be writing up a report on the incident sooner or later.' (Emphasis added.) That comment was removed (together with the rest 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 Project found sudden compromise of several of its servers in 2007, Wichert Akkerman wrote and posted a wonderful public report on precisely what happened. Likewise, the Apache Foundation likewise did the best factor with good public autopsies of the 2010 Net site breaches. Arstechnica's Dan Goodin was nonetheless attempting 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 told Ars that the investigation has but to be accomplished and gave no timetable for when a report might be released. [...] Kroah-Hartman additionally advised Ars kernel.org methods were rebuilt from scratch following the assault. Officials have developed new instruments and procedures since then, however he declined to say what they're. "There can be a report later this 12 months about site [sic] has been engineered, but don't quote me on when will probably be released as I'm not responsible for it," he wrote.
Who's responsible, then? Is anybody? Anybody? Bueller? Or is it a state secret, or what? Two years since Greg Ok-H stated there could be a report 'later this year', and four years because the meltdown, nothing but. How about some data? Rick Moen
[email protected]

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

Much less seriously, note that if even the Linux mafia doesn't know, it must be the venusians; they're notoriously stealth in their invasions.

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

I do know the kernel.org admins have given talks about some of the brand new protections which were put into place. There aren't any more shell logins, as a substitute every little thing makes use of gitolite. The completely different providers are on different hosts. There are more kernel.org staff now. Persons are utilizing two factor identification. Some other stuff. Do a seek for Konstantin Ryabitsev.

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

I beg your pardon if I was one way or the other unclear: That was mentioned to have been the trail of entry to the machine (and i can readily consider that, because it was also the precise path to entry into shells.sourceforge.web, many years prior, round 2002, and into many other shared Internet hosts for a few years). But that's not what is of major interest, and is not what the forensic study lengthy promised would primarily concern: How did intruders escalate to root. To quote kernel.org administrator within the August 2011 Dan Goodin article you cited: 'How they managed to use that to root access is at the moment unknown and is being investigated'. Okay, people, you have now had 4 years of investigation. What was the path of escalation to root? (Also, other particulars that may logically be covered by a forensic examine, corresponding to: Whose key was stolen? Who stole the important thing?) That is the type of autopsy was promised prominently on the front page of kernel.org, to reporters, and elsewhere for a very long time (and then summarily eliminated as a promise from the front web page of kernel.org, with out comment, together with the rest of the positioning Information section, and apparently dropped). It still would be applicable to know and share that information. Especially the datum of whether or not the path to root privilege was or was not a kernel bug (and, if not, what it was). Rick Moen
[email protected]

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

I've executed a more in-depth assessment of revelations that got here out soon 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 comments 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 including the operating 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 services still lit up, for a number of days. - Site admins and Linux Foundation sat on the data and failed to tell the public for those self same a number of days. - Site admins and Linux Foundation have never revealed whether or not trojaned Linux source tarballs were posted within the http/ftp tree for the 19+ days earlier than they took the site down. (Yes, git checkout was fine, however what in regards to the thousands of tarball downloads?) - After promising a report for several years and then 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 a real report from insiders, to SVLUG's primary mailing record yesterday. (Essentially, there are surmises. If the people with the details have been extra forthcoming, we would know what happened for sure.) I do must surprise: If there's another embarrassing screwup, will we even be advised about it in any respect? Rick Moen
[email protected]

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

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

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

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

Thanks for your comments, Brad. I'd been relying on Dan Goodin's declare of Phalanx being what was used to gain root, in the bit the place he cited 'two security researchers who have been briefed on the breach' to that effect. Goodin also elaborated: 'Fellow security researcher Dan Rosenberg mentioned he was also briefed that the attackers used Phalanx to compromise the kernel.org machines.' This was the primary time I've heard of a rootkit being claimed to be bundled with an assault software, and i noted that oddity in my posting to SVLUG. That having been stated, yeah, the Phalanx README would not particularly claim this, so then perhaps Goodin and his several 'security researcher' sources blew that detail, and no one but kernel.org insiders but knows the escalation path used to gain root. Also, it's preferable to make use of dwell memory acquisition prior to powering off the system, otherwise you lose out on reminiscence-resident artifacts that you may perform forensics on.
Arguable, but a tradeoff; you can poke the compromised reside system for state information, but with the downside of leaving your system operating beneath hostile management. I used to be all the time taught that, on steadiness, it is better to drag power to finish the intrusion. Rick Moen
[email protected]

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

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

With "something" you mean those that produce those closed supply drivers, right?
If the "client product firms" just caught to using components with mainlined open supply drivers, then updating their products can be much simpler.

A new Mindcraft second?

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

They've ring 0 privilege, can entry protected memory straight, and can't be audited. Trick a kernel into working a compromised module and it is sport over.
Even tickle a bug in a "good" module, and it is in all probability recreation over - in this case quite literally as such modules are typically video drivers optimised for games ...

Read More: https://fakeroot.net/