A New Mindcraft Moment?
Posted Nov 6, 2015 20:50 UTC (Fri) by PaXTeam (visitor, #24616) [Link]
1. this WP article was the fifth in a sequence of articles following the safety of the web from its beginnings to related matters of right this moment. discussing the safety of linux (or lack thereof) suits nicely in there. it was also a effectively-researched article with over two months of research and interviews, something you cannot fairly declare yourself for your current items on the topic. you do not just like the details? then say so. and even higher, do something constructive about them like Kees and others have been trying. nevertheless silly comparisons to old crap just like the Mindcraft research and fueling conspiracies don't precisely help your case.
2. "We do an affordable job of discovering and fixing bugs."
let's begin here. is that this statement based mostly on wishful thinking or cold laborious facts you are going to share in your response? in keeping with Kees, the lifetime of safety bugs is measured in years. that's more than the lifetime of many gadgets individuals purchase and use and ditch in that period.
3. "Problems, whether or not they are safety-associated or not, are patched shortly,"
some are, some aren't: let's not overlook the latest NMI fixes that took over 2 months to trickle all the way down to stable kernels and we also have a person who has been waiting for over 2 weeks now: http://thread.gmane.org/gmane.comp.file-systems.btrfs/49500 (FYI, the overflow plugin is the primary one Kees is making an attempt to upstream, think about the shitstorm if bugreports will probably be treated with this perspective, let's hope btrfs guys are an exception, not the rule). anyway, two examples are usually not statistics, so as soon as again, do you may have numbers or is all of it wishful pondering? (it is partly a trick question because you'll also have to explain how one thing will get to be decided to be security related which as everyone knows is a messy business within the linux world)
4. "and the stable-replace mechanism makes those patches obtainable to kernel users."
except when it doesn't. and sure, i've numbers: grsec carries 200+ backported patches in our 3.14 stable tree.
5. "Specifically, the few developers who are working on this area have never made a severe try and get that work integrated upstream."
you don't should be shy about naming us, in spite of everything you did so elsewhere already. and we additionally defined the reasons why we haven't pursued upstreaming our code: https://lwn.internet/Articles/538600/ . since i do not anticipate you and your readers to learn any of it, here is the tl;dr: if you need us to spend thousands of hours of our time to upstream our code, you will have to pay for it. no ifs no buts, that'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 free of charge. and earlier than somebody brings up the CII, go examine their mail archives, after some preliminary exploratory discussions i explicitly asked them about supporting this lengthy drawn out upstreaming work and acquired no answers.
Posted Nov 6, 2015 21:39 UTC (Fri) by patrick_g (subscriber, #44470) [Link]
Money (aha) quote :
> I suggest you spend none of your free time on this. Zero. I propose you receives a commission to do this. And properly.
No person anticipate you to serve your code on a silver platter at no cost. The Linux foundation and massive companies utilizing Linux (Google, Pink Hat, Oracle, Samsung, and so on.) ought to pay security specialists like you to upstream your patchs.
Posted Nov 6, 2015 21:57 UTC (Fri) by nirbheek (subscriber, #54111) [Hyperlink]
I'd just like to level out that the best way you phrased this makes your comment a tone argument[1][2]; you've got (probably unintentionally) dismissed all the mum or dad's arguments by pointing at its presentation. The tone of PAXTeam's comment shows the frustration constructed up over time with the way in which things work which I think ought to be taken at face value, empathized with, and understood quite than merely dismissed.
1. http://rationalwiki.org/wiki/Tone_argument
2. http://geekfeminism.wikia.com/wiki/Tone_argument
Cheers,
Posted Nov 7, 2015 0:55 UTC (Sat) by josh (subscriber, #17465) [Link]
Posted Nov 7, 2015 1:21 UTC (Sat) by PaXTeam (guest, #24616) [Hyperlink]
why, is upstream identified for its basic civility and decency? have you even learn the WP post below dialogue, never thoughts previous lkml visitors?
Posted Nov 7, 2015 5:37 UTC (Sat) by josh (subscriber, #17465) [Hyperlink]
Posted Nov 7, 2015 5:34 UTC (Sat) by gmatht (visitor, #58961) [Hyperlink]
No Argument
Posted Nov 7, 2015 6:09 UTC (Sat) by josh (subscriber, #17465) [Link]
Please don't; it doesn't belong there either, and it especially doesn't need a cheering part as the tech press (LWN typically excepted) tends to provide.
Posted Nov 8, 2015 8:36 UTC (Solar) by gmatht (visitor, #58961) [Hyperlink]
Ok, however I was considering of Linus Torvalds
Posted Nov 8, 2015 16:Eleven UTC (Sun) by pbonzini (subscriber, #60935) [Link]
Posted Nov 6, 2015 22:Forty three UTC (Fri) by PaXTeam (guest, #24616) [Hyperlink]
Posted Nov 6, 2015 23:00 UTC (Fri) by pr1268 (subscriber, #24648) [Hyperlink]
Why must you assume only cash will repair this downside? Yes, I agree extra sources should be spent on fixing Linux kernel safety points, but do not assume somebody giving an organization (ahem, PAXTeam) cash is the one answer. (Not mean to impugn PAXTeam's security efforts.)
The Linux development community could have had the wool pulled over its collective eyes with respect to safety issues (either actual or perceived), but simply throwing cash at the problem won't repair this.
And yes, I do notice the business Linux distros do tons (most?) of the kernel improvement nowadays, and that implies oblique monetary transactions, but it's a lot more involved than just that.
Posted Nov 7, 2015 0:36 UTC (Sat) by PaXTeam (guest, #24616) [Hyperlink]
Posted Nov 7, 2015 7:34 UTC (Sat) by nix (subscriber, #2304) [Hyperlink]
Posted Nov 7, 2015 9:49 UTC (Sat) by PaXTeam (guest, #24616) [Hyperlink]
Posted Nov 6, 2015 23:13 UTC (Fri) by dowdle (subscriber, #659) [Link]
I think you positively 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 half proper... cash 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 (visitor, #24616) [Link]
they talked to spender, not me personally, but sure, this facet of the coin is properly represented by us and others who have been interviewed. the identical means Linus is a good representative of, effectively, his personal pet challenge known as linux.
> And if Jon had solely talked to you, his would have been too.
given that i'm the creator of PaX (a part of grsec) sure, speaking to me about grsec issues makes it the most effective methods to research it. but if you understand of another person, be my guest and title them, i'm fairly sure the just lately formed kernel self-safety people could be dying to engage them (or not, i do not think there is a sucker out there with 1000's of hours of free time on their hand).
> [...]it also contained fairly just a few of groan-worthy statements.
nothing is perfect but contemplating the audience of the WP, this is one in every of the higher journalistic pieces on the subject, no matter how you and others do not like the sorry state of linux security uncovered in there. in order for you to debate extra technical particulars, nothing stops you from speaking to us ;).
speaking of your complaints about journalistic qualities, since a previous LWN article saw it fit to incorporate a number of typical dismissive claims by Linus about the standard of unspecified grsec options with no proof of what expertise he had with the code and how latest it was, how come we didn't see you or anyone else complaining about the quality of that article?
> Aren't you glad?
no, or not yet anyway. i've heard lots of empty phrases over the years and nothing ever manifested or worse, all the cash has gone to the pointless exercise of fixing particular person bugs and related circus (that Linus rightfully despises FWIW).
Posted Nov 7, 2015 0:18 UTC (Sat) by bojan (subscriber, #14302) [Link]
Posted Nov 8, 2015 13:06 UTC (Sun) by k3ninho (subscriber, #50375) [Hyperlink]
Right now we've obtained builders from massive names saying that doing all that the Linux ecosystem does *safely* is an itch that they have. Sadly, the encircling cultural attitude of builders is to hit functional goals, and occasionally performance objectives. Security objectives are sometimes overlooked. Ideally, the tradition would shift in order that we make it difficult to comply with insecure habits, patterns or paradigms -- that could be a activity that may take a sustained effort, not merely the upstreaming of patches.
Whatever the culture, these patches will go upstream finally anyway because the ideas that they embody are now timely. I can see a approach to make it occur: Linus will settle for them when an enormous end-user (say, Intel, Google, Facebook or Amazon) delivers stuff with notes like 'this is a set of improvements, we're already utilizing them to unravel this kind of downside, this is how every little thing will stay working because $proof, observe rigorously that you are 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 would favor that the neighborhood shepherds users to observe the sample of declaring problem + solution + functional test proof + efficiency take a look at proof + safety check proof.
K3n.
Posted Nov 9, 2015 6:49 UTC (Mon) by jospoortvliet (guest, #33164) [Hyperlink]
And about that fork barrel: I might argue it is the other way around. Google forked and lost already.
Posted Nov 12, 2015 6:25 UTC (Thu) by Garak (guest, #99377) [Link]
Posted Nov 23, 2015 6:33 UTC (Mon) by jospoortvliet (guest, #33164) [Link]
Posted Nov 7, 2015 3:20 UTC (Sat) by corbet (editor, #1) [Hyperlink]
So I must confess to a certain amount of confusion. I might swear that the article I wrote said exactly that, however you've got put a fair amount of effort into flaming it...?
Posted Nov 8, 2015 1:34 UTC (Sun) by PaXTeam (guest, #24616) [Link]
Posted Nov 6, 2015 22:52 UTC (Fri) by flussence (subscriber, #85566) [Link]
I personally suppose you and Nick Krause share opposite sides of the identical coin. Programming means and primary civility.
Posted Nov 6, 2015 22:59 UTC (Fri) by dowdle (subscriber, #659) [Link]
Posted Nov 7, 2015 0:16 UTC (Sat) by rahvin (visitor, #16953) [Link]
I hope I'm incorrect, but a hostile angle isn't going to help anybody get paid. It is a time like this where something you appear to be an "professional" at and there's a demand for that experience where you display cooperation and willingness to participate because it's a possibility. I am relatively shocked that someone doesn't get that, however I am older and have seen a few of those alternatives in my career and exploited the hell out of them. You solely get just a few of those in the typical profession, and handful at essentially the most.
Typically it's a must to invest in proving your expertise, and that is a type of moments. It appears the Kernel community might finally take this security lesson to coronary heart and embrace it, as stated within the article as a "mindcraft moment". This is an opportunity for developers that will wish to work on Linux security. Some will exploit the opportunity and others will thumb their noses at it. In the long run those developers that exploit the opportunity will prosper from it.
I really feel outdated even having to write down that.
Posted Nov 7, 2015 1:00 UTC (Sat) by josh (subscriber, #17465) [Link]
Maybe there's a rooster and egg downside right here, but when seeking out and funding individuals to get code upstream, it helps to pick out people and groups with a history of being able to get code upstream.
It's completely cheap to want understanding of tree, providing the power to develop spectacular and demanding security advances unconstrained by upstream requirements. That's work somebody might also wish to fund, if that meets their needs.
Posted Nov 7, 2015 1:28 UTC (Sat) by PaXTeam (visitor, #24616) [Hyperlink]
Posted Nov 7, 2015 19:12 UTC (Sat) by jejb (subscriber, #6654) [Link]
You make this argument (implying you do research and Josh does not) after which fail to support it by any cite. It could be rather more convincing for those who surrender on the Onus probandi rhetorical fallacy and truly cite information.
> working example, it was *them* who instructed that they wouldn't fund out-of-tree work but would consider funding upstreaming work, besides when pressed for the main points, all i bought was silence.
For those following alongside at residence, this is the related set of threads:
http://lists.coreinfrastructure.org/pipermail/cii-focus on...
A quick precis is that they informed you your project was unhealthy as a result of the code was never going upstream. You advised them it was due to kernel builders perspective so they need to fund you anyway. They instructed you to submit a grant proposal, you whined more about the kernel attitudes and finally even your apologist told you that submitting a proposal might be the neatest thing to do. At that point you went silent, not vice versa as you imply above.
> clearly i won't spend time to write up a begging proposal just to be informed that 'no sorry, we do not fund multi-yr initiatives at all'. that is one thing that one should be informed in advance (or heck, be part of some public rules in order that others will know the foundations too).
You appear to have a fatally flawed grasp of how public funding works. If you don't tell folks why you want the cash and the way you'll spend it, they're unlikely to disburse. Saying I'm sensible and I do know the issue now hand over the cash does not even work for many Academics who've a solid reputation 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 check the kernel git logs (minus the stuff that was not properly credited)?
jejb@jarvis> git log|grep -i 'Writer: pax.*crew'|wc -l
1
Stellar, I need to say. And before you gentle off on these who've misappropriated your credit, please keep in mind that getting code upstream on behalf of reluctant or incapable actors is a vastly valuable and time consuming talent and one among the reasons teams like Linaro exist and are well funded. If extra of your stuff does go upstream, will probably be due to the not inconsiderable efforts of different people on this space.
You now have a business model promoting non-upstream security patches to clients. There's nothing flawed with that, it's a fairly traditional first stage business mannequin, but it does reasonably rely upon patches not being upstream in the first place, calling into query the earnestness of your try to put them there.
Now here is some free recommendation in my field, which is assisting companies align their companies in open supply: The selling out of tree patch route is at all times an eventual failure, significantly with the kernel, because if the functionality is that helpful, it will get upstreamed or reinvented in your despite, leaving you with nothing to promote. In case your business plan B is promoting expertise, you have to remember that it will be a tough sell when you have no out of tree differentiator left and git history denies that you had anything to do with the in-tree patches. In fact "loopy safety individual" will grow to be a self fulfilling prophecy. The advice? it was obvious to everybody else who read this, but for you, it's do the upstreaming yourself earlier than it will get executed for you. That way you will have a reliable historical declare to Plan B and also you may even have a Plan A promoting a rollup of upstream track patches integrated and delivered earlier than the distributions get around to it. Even your utility to the CII couldn't be dismissed as a result of your work wasn't going wherever. Your different is to continue enjoying the role of Cassandra and possibly undergo her eventual fate.
Posted Nov 7, 2015 23:20 UTC (Sat) by PaXTeam (guest, #24616) [Link]
> Second, for the doubtlessly viable pieces this could be a multi-yr
> full time job. Is the CII keen to fund projects at that level? If not
> we all would end up with a lot of unfinished and partially broken options.
please present me the reply to that query. with no definitive 'yes' there isn't a level in submitting a proposal because this is the time frame that for my part the job will take and any proposal with that requirement could be shot down instantly and be a waste of my time. and i stand by my claim that such simple primary necessities needs to be public information.
> Stellar, I need to say.
"Lies, damned lies, and statistics". you notice there's more than one technique 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 via af45f32d25cc1 so it's no wonder i do not send patches instantly in (and that one commit you found that went in regardless of mentioned ban is actually a very dangerous example because it's also the one that Linus censored for no good cause and made me decide to by no means ship security fixes upstream till that apply adjustments).
> You now have a enterprise model promoting non-upstream security patches to prospects.
now? we've had paid sponsorship for our various stable kernel series for 7 years. i would not call it a enterprise mannequin although because it hasn't paid anyone's payments.
> [...]calling into question the earnestness of your attempt to put them there.
i must be lacking something here however what try? i've by no means in my life tried to submit PaX upstream (for all the explanations discussed already). the CII mails were exploratory to see how serious that whole organization is about really securing core infrastructure. in a way i've bought my answers, there's nothing extra to the story.
as for your free recommendation, let me reciprocate: advanced problems do not remedy themselves. code fixing complicated problems doesn't write itself. individuals writing code fixing complex issues are few and far between that you will see that out in brief order. such people (domain experts) do not work free of charge with few exceptions like ourselves. biting the hand that feeds you'll only finish you up in hunger.
PS: since you're so certain 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-here' implementation and try to understand the explanation. or just look at all of 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 venture when i'm bored or just waiting for the next kernel to compile (i want LTO was extra environment friendly).
Posted Nov 8, 2015 2:28 UTC (Sun) by jejb (subscriber, #6654) [Link]
In different phrases, you tried to outline their course of for them ... I can not think why that would not work.
> "Lies, damned lies, and statistics".
The problem with advert hominem attacks is that they are singularly ineffective against a transparently factual argument. I posted a one line command anyone could run to get the number of patches you have authored in the kernel. Why don't you submit an equal that offers figures you like more?
> i've never in my life tried to submit PaX upstream (for all the explanations discussed already).
So the master plan is to demonstrate your expertise by the variety of patches you haven't submitted? great plan, world domination beckons, sorry that one got away from you, but I'm certain you will not let it occur once more.
Posted Nov 8, 2015 2:Fifty six UTC (Sun) by PaXTeam (visitor, #24616) [Link]
what? since when does asking a question outline anything? is not that how we find out what someone else thinks? is not that what *they* have that webform (never mind the mailing lists) for as nicely? in different words you admit that my query was not truly answered .
> The problem with ad hominem attacks is that they are singularly ineffective in opposition to a transparently factual argument.
you did not have an argument to begin with, that is what i defined in the half you carefully chose to not quote. i am not here to defend myself in opposition to your clearly idiotic makes an attempt at proving whatever you are attempting to prove, as they are saying even in kernel circles, code speaks, bullshit walks. you'll be able to look at mine and resolve what i can or can not do (not that you've the data to grasp most of it, mind you). that said, there're clearly other more capable people who've carried out so and decided that my/our work was price one thing else nobody would have been feeding off of it for the previous 15 years and nonetheless counting. and as unimaginable as it might appear to you, life doesn't revolve around 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 here (it is ironic the way you came to the defense of josh who specifically asked individuals to not convey that infamous lkml type here. nice job there James.). as for world domination, there're many ways to achieve it and one thing tells me that you're clearly out of your league 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 original request by you (this one, simply in case you've forgotten http://lwn.web/Articles/663591/):
> as for getting code upstream, how about you test the kernel git logs (minus the stuff that was not properly credited)?
I take it, by the way you've shifted floor in the previous threads, that you just want to withdraw that request?
Posted Nov 8, 2015 19:31 UTC (Solar) by PaXTeam (visitor, #24616) [Hyperlink]
Posted Nov 8, 2015 22:31 UTC (Sun) by pizza (subscriber, #46) [Hyperlink]
Please present one that is not mistaken, or much less incorrect. It should take much less time than you've got already wasted right here.
Posted Nov 8, 2015 22:Forty nine UTC (Solar) by PaXTeam (guest, #24616) [Hyperlink]
anyway, since it's you guys who have a bee in your bonnet, let's check your degree of intelligence too. first figure out my electronic mail tackle and undertaking name then attempt to search out the commits that say they arrive from there (it introduced back some reminiscences from 2004 already, how times flies! i am stunned i truly managed to accomplish this a lot with explicitly not making an attempt, think about if i did :). it's an extremely complicated job so by accomplishing it you'll prove yourself to be the highest canine right here on lwn, no matter that is value ;).
Posted Nov 8, 2015 23:25 UTC (Sun) by pizza (subscriber, #46) [Link]
*shrug* Or do not; you are only sullying your personal status.
Posted Nov 9, 2015 7:08 UTC (Mon) by jospoortvliet (visitor, #33164) [Hyperlink]
Posted Nov 9, 2015 11:38 UTC (Mon) by hkario (subscriber, #94864) [Link]
I wouldn't both
Posted Nov 12, 2015 2:09 UTC (Thu) by jschrod (subscriber, #1646) [Link]
Posted Nov 12, 2015 8:50 UTC (Thu) by nwmcsween (guest, #62367) [Hyperlink]
Posted Nov 8, 2015 3:38 UTC (Solar) by PaXTeam (visitor, #24616) [Link]
Posted Nov 12, 2015 13:47 UTC (Thu) by nix (subscriber, #2304) [Link]
Ah. I assumed my reminiscence wasn't failing me. Compare to PaXTeam's response to .
PaXTeam is not averse to outright mendacity if it means he gets to appear proper, I see. Possibly PaXTeam's memory is failing, and this obvious contradiction is just not a brazen lie, however given that the two posts were made within a day of one another I doubt it. (PaXTeam's total unwillingness to assume good faith in others deserves some reflection. Sure, Minecraft servers *do* think he's lying by implication here, and doing so when there's almost nothing at stake. God alone knows what he is keen to stoop to when one thing *is* at stake. Gosh I'm wondering why his fixes aren't going upstream very fast.)
Posted Nov 12, 2015 14:Eleven UTC (Thu) by PaXTeam (guest, #24616) [Link]
> and that one commit you found that went in regardless of mentioned ban
also somebody's ban doesn't mean it'll translate into someone else's execution of that ban as it is clear from the commit in query. it's considerably unhappy that it takes a security repair to expose the fallacy of this policy although. the remainder of your pithy advert hominem speaks for itself higher than i ever might ;).
Posted Nov 12, 2015 15:58 UTC (Thu) by andreashappe (subscriber, #4810) [Hyperlink]
Posted Nov 7, 2015 19:01 UTC (Sat) by cwillu (guest, #67268) [Link]
I do not see this message in my mailbox, so presumably it bought swallowed.
Posted Nov 7, 2015 22:33 UTC (Sat) by ssmith32 (subscriber, #72404) [Link]
You might be conscious that it's entirely attainable that everyone is improper right here , proper?
That the kernel maintainers need to focus more on security, that the article was biased, that you are irresponsible to decry the state of safety, and do nothing to help, and that your patchsets would not assist that much and are the fallacious direction for the kernel? That simply because the kernel maintainers aren't 100% proper it does not imply you are?
Posted Nov 9, 2015 9:50 UTC (Mon) by njd27 (guest, #5770) [Link]
I feel you could have him backwards there. Jon is comparing this to Mindcraft because he thinks that despite being unpalatable to numerous the group, the article might in reality comprise a number of reality.
Posted Nov 9, 2015 14:03 UTC (Mon) by corbet (editor, #1) [Hyperlink]
Posted Nov 9, 2015 15:13 UTC (Mon) by spender (visitor, #23067) [Link]
"There are rumors of darkish forces that drove the article in the hopes of taking Linux down a notch. All of this could well be true"
Just as you criticized the article for mentioning Ashley Madison although in the very first sentence of the following paragraph it mentions it didn't contain the Linux kernel, you can't give credence to conspiracy theories with out incurring the same criticism (in different words, you can't play the Glenn Beck "I'm just asking the questions here!" whose "questions" gasoline the conspiracy theories of others). Much like mentioning Ashley Madison for instance for non-technical readers concerning the prevalence of Linux on the planet, if you are criticizing the point out then mustn't likening a non-FUD article to a FUD article additionally deserve criticism, especially given the rosy, self-congratulatory picture you painted of upstream Linux security?
As the PaX Crew identified in the initial put up, the motivations aren't arduous to know -- you made no point out at all about it being the 5th in a long-working series following a reasonably predictable time trajectory.
No, we did not miss the overall analogy you were making an attempt to make, we simply do not suppose you possibly can have your cake and eat it too.
-Brad
Posted Nov 9, 2015 15:18 UTC (Mon) by karath (subscriber, #19025) [Hyperlink]
Posted Nov 9, 2015 17:06 UTC (Mon) by k3ninho (subscriber, #50375) [Link]
It's gracious of you not to blame your readers. I figure they're a fair goal: there's that line about those 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) [Link]
Unfortunately, I do not understand neither the "security" of us (PaXTeam/spender), nor the mainstream kernel people by way of their attitude. I confess I have totally no technical capabilities on any of these subjects, but if they all decided to work together, as a substitute of getting infinite and pointless flame wars and blame sport exchanges, a number of the stuff would have been performed already. And all the whereas everybody involved may have made one other massive pile of money on the stuff. They all seem to need to have a greater Linux kernel, so I've got no thought what the issue is. Evidently no person is keen to yield any of their positions even a little bit. As an alternative, both sides seem like bent on attempting to insult their means into forcing the other side to quit. Which, in fact, 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:Forty four 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 safety stuff turned off on it to achieve maximum efficiency, as a result of you'll be able to belief all users. Now take a number of billion cell phones that may be tough or gradual to patch. You'd most likely want to kill many of the exploit lessons there, if those devices can still run reasonably effectively with most security options turned on.
So, it isn't both/or. It is most likely "it depends". But, if the stuff isn't there for everyone to compile/use within the vanilla kernel, it will likely be tougher to make it part of everyday selections for distributors and customers.
Posted Nov 6, 2015 22:20 UTC (Fri) by artem (subscriber, #51262) [Hyperlink]
How sad. This Dijkstra quote comes to mind instantly:
Software program engineering, of course, presents itself as another worthy cause, but that is eyewash: if you carefully learn its literature and analyse what its devotees actually do, you will discover that software engineering has accepted as its charter "Find out how to program if you cannot."
Posted Nov 7, 2015 0:35 UTC (Sat) by roc (subscriber, #30627) [Hyperlink]
I assume that fact was too unpleasant to suit into Dijkstra's world view.
Posted Nov 7, 2015 10:Fifty two UTC (Sat) by ms (subscriber, #41272) [Link]
Indeed. And the interesting thing to me is that once I attain that point, checks are not adequate - mannequin checking at a minimal and actually proofs are the one method forwards. I am no security professional, my area is all distributed methods. I understand and have implemented Paxos and that i believe I can explain how and why it really works to anybody. However I am currently doing a little algorithms combining Paxos with a bunch of variations on VectorClocks and reasoning about causality and consensus. No test is enough because there are infinite interleavings of events and my head just couldn't cope with working on this either at the pc or on paper - I discovered I could not intuitively motive about this stuff at all. So I began defining the properties and wished and step-by-step proving why every of them holds. Without my notes and proofs I am unable to even explain to myself, not to mention anyone else, why this factor works. I discover this both utterly apparent that this could happen and completely terrifying - the upkeep price of these algorithms is now an order of magnitude increased.
Posted Nov 19, 2015 12:24 UTC (Thu) by Wol (subscriber, #4433) [Link]
> Indeed. And the attention-grabbing factor to me is that after I attain that point, tests usually are not ample - model checking at a minimum and really proofs are the only way forwards.
Or are you just utilizing the unsuitable maths? Hobbyhorse time once more :-) but to quote a fellow Decide developer ... "I often walk right into a SQL growth store and see that wall - you realize, the one with the huge SQL schema that no-one absolutely understands on it - and marvel how I can simply hold the entire schema for a Pick database of the same or higher complexity in my head".
However it is simple - by training I'm a Chemist, by curiosity a Bodily Chemist (and by profession an unemployed programmer :-). And when I am enthusiastic about chemistry, I can ask myself "what is an atom manufactured from" and suppose about issues like the robust nuclear drive. Next degree up, how do atoms stick together and make molecules, and assume in regards to the electroweak pressure and electron orbitals, and how do chemical reactions happen. Then I believe about molecules stick together to make supplies, and think about metals, and/or Van de Waals, and stuff.
Level is, it is advisable *layer* stuff, and take a look at issues, and say "how can I break up elements off into 'black bins' so at any one degree I can assume the opposite levels 'just work'". For example, with Pick a FILE (table to you) shops a category - a group of equivalent objects. One object per File (row). And, similar as relational, one attribute per Discipline (column). Can you map your relational tables to reality so easily? :-)
Going again THIRTY years, I remember a story about a guy who built little computer crabs, that could fairly fortunately scuttle around in the surf zone. Because he did not try to work out how to resolve all the issues directly - every of his (extremely puny by right this moment's standards - this is the 8080/Z80 era!) processors was set to only course of slightly little bit of the problem and there was no central "brain". But it labored ... Maybe it is best to simply write a bunch of small modules to unravel every individual downside, and let final reply "just 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 assemble schemas for the varied modifying ("delta") operations on the bottom schema, after which argue about preservation of formal invariants, properties of the end result, and transitivity of the operation when chained with itself, or the previous aggregate schema composed of schemas A through 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 result and outputs. Thus proving the formal design appropriate (w/ caveat lectors regarding scope, correspondence with its implementation [although that may be confirmed as well], and read-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 other fields too), you may probably discover that individuals "can't see the wood for the timber" more usually that not. They dive into the element and fully miss the big image.
(Medicine, and interest of mine, suffers from that too - I remember any person talking concerning the advisor desirous to amputate a gangrenous leg to save somebody's life - oblivious to the fact that the affected person was dying of cancer.)
Cheers,
Wol
Posted Nov 7, 2015 6:35 UTC (Sat) by dgc (subscriber, #6611) [Link]
https://www.youtube.com/watch?v=VpuVDfSXs-g
(LCA 2015 - "Programming Considered Harmful")
FWIW, I feel that this talk could be very relevant to why writing safe software is so arduous..
-Dave.
Posted Nov 7, 2015 5:49 UTC (Sat) by kunitz (subscriber, #3965) [Hyperlink]
While we're spending millions at a large number of security problems, kernel issues are usually not on our top-precedence list. Truthfully I remember solely once having discussing a kernel vulnerability. The result of the evaluation has been that every one our programs had been working kernels that had been older as the kernel that had the vulnerability.
However "patch management" is an actual concern for us. Software should continue to work if we set up security patches or update to new releases due to the tip-of-life coverage of a vendor. The income of the corporate is relying on the IT systems running. So "not breaking person house" is a safety function for us, because a breakage of 1 element of our several ten 1000's of Linux programs will cease the roll-out of the security replace.
One other drawback is embedded software program or firmware. Lately virtually all hardware methods embrace an working system, often some Linux model, providing a fill network stack embedded to help distant administration. Repeatedly these programs do not survive our obligatory security scan, because vendors nonetheless didn't replace the embedded openssl.
The true problem is to offer a software program stack that may be operated within the hostile surroundings of the Internet maintaining full system integrity for ten years and even longer without any customer maintenance. The current state of software engineering would require assist for an automatic replace course of, but vendors must understand that their enterprise model must be capable of finance the sources offering the updates.
General I am optimistic, networked software program just isn't the first expertise utilized by mankind inflicting issues that have been addressed later. Steam engine use could lead to boiler explosions however the "engineers" had been in a position to cut back this threat significantly over just a few a long time.
Posted Nov 7, 2015 10:29 UTC (Sat) by ms (subscriber, #41272) [Hyperlink]
The next is all guess work; I might be keen to know if others have proof both a method or one other on this: The people who learn to hack into these programs by kernel vulnerabilities know that they expertise they've learnt have a market. Thus they do not are inclined to hack as a way to wreak havoc - indeed on the entire the place knowledge has been stolen as a way to release and embarrass folks, it _appears_ as if those hacks are by a lot easier vectors. I.e. lesser expert hackers discover there is a whole load of low-hanging fruit which they can get at. They're not being paid forward of time for the information, in order that they turn to extortion instead. They don't cowl their tracks, and they'll often be discovered and charged with criminal offences.
So if your safety meets a certain basic stage of proficiency and/or your company isn't doing anything that places it close to the highest of "firms we'd like to embarrass" (I think the latter is much simpler at protecting techniques "safe" than the previous), then the hackers that get into your system are likely to be expert, paid, and possibly not going to do much damage - they're stealing information for a competitor / state. So that does not hassle your bottom line - at the least not in a manner which your shareholders will bear in mind of. So why fund security?
Posted Nov 7, 2015 17:02 UTC (Sat) by citypw (visitor, #82661) [Hyperlink]
On the other hand, some efficient mitigation in kernel stage could be very helpful to crush cybercriminal/skiddie's try. If one in all your buyer operating a future buying and selling platform exposes some open API to their purchasers, and if the server has some reminiscence corruption bugs may be exploited remotely. Then you realize there are known attack strategies( comparable to offset2lib) can help the attacker make the weaponized exploit a lot easier. Will you clarify the failosophy "A bug is bug" to your buyer and tell them it would be okay? Btw, offset2lib is useless to PaX/Grsecurity's ASLR imp.
To probably the most business makes use of, extra safety mitigation throughout the software will not price you more funds. You'll nonetheless need to do the regression check for every upgrade.
Posted Nov 12, 2015 16:14 UTC (Thu) by andreashappe (subscriber, #4810) [Hyperlink]
Needless to say I focus on external net-primarily based penetration-tests and that in-house tests (local LAN) will probably yield totally different outcomes.
Posted Nov 7, 2015 20:33 UTC (Sat) by mattdm (subscriber, #18) [Link]
I keep reading this headline as "a brand new Minecraft second", and thinking that possibly they've decided to follow up the .Internet thing by open-sourcing Minecraft. Oh nicely. I mean, security is good too, I guess.
Posted Nov 7, 2015 22:24 UTC (Sat) by ssmith32 (subscriber, #72404) [Hyperlink]
Posted Nov 12, 2015 17:29 UTC (Thu) by smitty_one_every (subscriber, #28989) [Hyperlink]
Posted Nov 8, 2015 10:34 UTC (Sun) by jcm (subscriber, #18262) [Link]
Posted Nov 9, 2015 7:15 UTC (Mon) by jospoortvliet (visitor, #33164) [Hyperlink]
Posted Nov 9, 2015 15:53 UTC (Mon) by neiljerram (subscriber, #12005) [Link]
(Oh, and I was also still 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 (visitor, #4654) [Hyperlink]
I'd similar to to add that in my view, there is a normal downside with the economics of laptop security, which is very seen at present. Two issues even maybe.
First, the cash spent on pc security is commonly diverted towards the so-referred to as safety "circus": quick, simple solutions which are primarily chosen just in an effort to "do something" and get higher press. It took me a very long time - possibly decades - to assert that no security mechanism at all is best than a nasty mechanism. But now I firmly consider on this attitude and would reasonably take the risk knowingly (provided that I can save money/resource for myself) than take a nasty approach at fixing it (and haven't any cash/resource left when i understand I should have performed something else). And that i discover there are various unhealthy or incomplete approaches at the moment available in the pc security area.
Those spilling our rare cash/resources on ready-made ineffective instruments ought to get the bad press they deserve. And, we certainly have to enlighten the press on that as a result of it's not really easy to understand the effectivity of protection mechanisms (which, by definition, ought to forestall issues from occurring).
Second, and which may be more moderen and extra worrying. The move of money/resource is oriented within the path of attack tools and vulnerabilities discovery a lot more than within the path of new protection mechanisms.
This is particularly worrying as cyber "protection" initiatives look more and more like the usual idustrial initiatives aimed at producing weapons or intelligence methods. Furthermore, unhealthy useless weapons, because they're solely working towards our very vulnerable current programs; and bad intelligence methods as even fundamental college-degree encryption scares them right down to useless.
Nevertheless, all of the ressources are for these grownup teenagers playing the white hat hackers with not-so-troublesome programming tricks or community monitoring or WWI-stage cryptanalysis. And now additionally for the cyberwarriors and cyberspies that have yet to prove their usefulness entirely (particularly for peace protection...).
Personnally, I would fortunately depart them all the hype; but I am going to forcefully claim that they haven't any right in anyway on any of the funds allocation choices. Only these working on protection ought to. And yep, it means we should always resolve where to place there resources. We now have to say the exclusive lock for ourselves this time. (and I guess the PaXteam could be amongst 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 more publicity than they deserve.
I crave for the day I will learn within the newspaper that: "One other of these unwell suggested debutant programmer hooligans that pretend to be cyber-pirates/warriors modified some well-known virus program code exploiting a programmer mistake and managed nonetheless to deliver a kind of unfinished and unhealthy high quality programs, X, that we are all obliged to use to its knees, annoying hundreds of thousands of standard users along with his unlucky cyber-vandalism. All the safety specialists unanimously recommend that, as soon as once more, the budget of the cyber-command be retargetted, or at least leveled-off, so as to carry extra security engineer positions in the tutorial domain 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. Though it doesn't apply properly to the battlefield-oriented variant.
Posted Nov 9, 2015 14:28 UTC (Mon) by drag (visitor, #31333) [Hyperlink]
The state of 'software program safety industry' is a f-ng catastrophe. Failure of the best order. There is massive amounts of cash that goes into 'cyber safety', but it's often spent on government compliance and audit efforts. This implies instead of truly placing effort into correcting issues and mitigating future issues, nearly all of the trouble goes into taking present applications and making them conform to committee-driven guidelines with the minimal quantity of effort and adjustments.
Some stage of regulation and standardization is absolutely needed, however lay people are clueless and are completely unable to discern the difference between someone who has worthwhile expertise versus some firm that has spent hundreds of thousands on slick advertising and 'native advertising' on large websites and computer magazines. The individuals with the money unfortunately only have their own judgment to depend on when shopping for into 'cyber security'.
> These spilling our rare cash/resources on ready-made useless tools ought to get the dangerous press they deserve.
There isn't any such thing as 'our rare money/sources'. You've your cash, I have mine. Cash being spent by some company like Redhat is their cash. Cash being spent by governments is the government's money. (you, actually, have far more control in how Walmart spends it's cash then over what your government does with their's)
> This is especially worrying as cyber "protection" initiatives look an increasing number of like the same old idustrial initiatives aimed at producing weapons or intelligence systems. Furthermore, bad ineffective weapons, because they are solely working towards our very susceptible present programs; and bad intelligence methods as even fundamental faculty-level encryption scares them all the way down to useless.
Having secure software program with strong encryption mechanisms within the palms of the general public runs counter to the pursuits of most major governments. Governments, like every other for-revenue group, are primarily involved in self-preservation. Cash spent on drone initiatives or banking auditing/oversight regulation compliance is Far more beneficial to them then attempting to help the public have a safe mechanism for making cellphone calls. Particularly when those secure mechanisms interfere with knowledge collection efforts.
Sadly you/I/us can't rely upon some magical benefactor with deep pockets to sweep in and make Linux better. It's just not going to occur.
Firms like Redhat have been massively helpful to spending assets to make Linux kernel more succesful.. nevertheless they're pushed by a the need to show a revenue, which means they need to cater directly to the the kind of requirements established by their customer base. Customers for EL are typically far more centered on lowering costs related to administration and software program improvement then safety on the low-stage OS.
Enterprise Linux customers tend to rely on bodily, human policy, and network security to protect their 'delicate' interiors from being exposed to external threats.. assuming (rightly) that there is little or no they can do to actually harden their systems. The truth is when the selection comes between security vs comfort I am sure that most customers will fortunately defeat or strip out any safety mechanisms introduced into Linux.
On high of that when most Enterprise software is extremely bad. So much in order that 10 hours spent on enhancing an internet front-finish will yield extra actual-world safety advantages then a 1000 hours spent on Linux kernel bugs for most companies.
Even for 'normal' Linux customers a safety bug of their Firefox's NAPI flash plugin is way more devastating and poses a massively greater danger then a obscure Linux kernel buffer over move problem. It is simply not really necessary for attackers to get 'root' to get entry to the vital information... generall