A New Mindcraft Second?
Posted Nov 6, 2015 20:50 UTC (Fri) by PaXTeam (guest, #24616) [Link]
1. this WP article was the 5th in a collection of articles following the security of the internet from its beginnings to relevant subjects of at this time. discussing the security of linux (or lack thereof) suits properly in there. it was additionally a properly-researched article with over two months of analysis and interviews, one thing you cannot quite declare your self on your current pieces on the topic. you don't like the info? then say so. or even better, do one thing constructive about them like Kees and others have been trying. however foolish comparisons to old crap like the Mindcraft studies and fueling conspiracies do not precisely help your case.
2. " Jho88.com do an affordable job of discovering and fixing bugs."
let's begin here. is this assertion primarily based on wishful thinking or cold onerous facts you're going to share in your response? in accordance with Kees, the lifetime of safety bugs is measured in years. that's more than the lifetime of many devices folks purchase and use and ditch in that interval.
3. "Issues, whether or not they are security-associated or not, are patched quickly,"
some are, some aren't: let's not forget the current NMI fixes that took over 2 months to trickle right down to stable kernels and we also have a user who has been ready for over 2 weeks now: http://thread.gmane.org/gmane.comp.file-programs.btrfs/49500 (FYI, the overflow plugin is the first one Kees is making an attempt to upstream, imagine the shitstorm if bugreports can be treated with this angle, let's hope btrfs guys are an exception, not the rule). anyway, two examples are not statistics, so as soon as once more, do you've gotten numbers or is it all wishful pondering? (it's partly a trick query because you may even have to elucidate how something gets to be decided to be security associated which as everyone knows is a messy enterprise in the linux world)
4. "and the stable-replace mechanism makes those patches out there to kernel users."
besides when it does not. and sure, i have numbers: grsec carries 200+ backported patches in our 3.14 stable tree.
5. "In particular, the few developers who're working in this area have by no means made a severe try to get that work built-in upstream."
you do not need to be shy about naming us, in any case you probably did so elsewhere already. and we also explained the explanation why we haven't 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'd like us to spend 1000's 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's 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 before somebody brings up the CII, go verify their mail archives, after some initial exploratory discussions i explicitly asked them about supporting this lengthy drawn out upstreaming work and obtained no solutions.
Posted Nov 6, 2015 21:39 UTC (Fri) by patrick_g (subscriber, #44470) [Link]
Cash (aha) quote :
> I propose you spend none of your free time on this. Zero. I propose you get paid to do this. And nicely.
Nobody anticipate you to serve your code on a silver platter without cost. The Linux basis and large firms using Linux (Google, Crimson Hat, Oracle, Samsung, and many others.) ought to pay safety specialists such as you to upstream your patchs.
Posted Nov 6, 2015 21:57 UTC (Fri) by nirbheek (subscriber, #54111) [Hyperlink]
I might simply like to level out that the way you phrased this makes your remark a tone argument[1][2]; you've got (in all probability unintentionally) dismissed all of the parent's arguments by pointing at its presentation. The tone of PAXTeam's comment displays the frustration built up over time with the way things work which I think should be taken at face worth, empathized with, and understood slightly than merely dismissed.
1. http://rationalwiki.org/wiki/Tone_argument
2. http://geekfeminism.wikia.com/wiki/Tone_argument
Cheers,
Posted Nov 7, 2015 0:Fifty five UTC (Sat) by josh (subscriber, #17465) [Link]
Posted Nov 7, 2015 1:21 UTC (Sat) by PaXTeam (guest, #24616) [Hyperlink]
why, is upstream recognized for its primary civility and decency? have you ever even read the WP post under discussion, never mind previous lkml traffic?
Posted Nov 7, 2015 5:37 UTC (Sat) by josh (subscriber, #17465) [Link]
Posted Nov 7, 2015 5:34 UTC (Sat) by gmatht (guest, #58961) [Hyperlink]
No Argument
Posted Nov 7, 2015 6:09 UTC (Sat) by josh (subscriber, #17465) [Link]
Please don't; it would not belong there either, and it especially would not want a cheering part because the tech press (LWN typically excepted) tends to offer.
Posted Nov 8, 2015 8:36 UTC (Sun) by gmatht (guest, #58961) [Link]
Ok, but I used to be thinking 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 (visitor, #24616) [Hyperlink]
Posted Nov 6, 2015 23:00 UTC (Fri) by pr1268 (subscriber, #24648) [Link]
Why must you assume solely money will repair this downside? Sure, I agree more sources must be spent on fixing Linux kernel security points, but don't assume someone giving a company (ahem, PAXTeam) money is the one resolution. (Not mean to impugn PAXTeam's security efforts.)
The Linux improvement neighborhood may have had the wool pulled over its collective eyes with respect to safety points (either real or perceived), however simply throwing money at the problem will not fix this.
And sure, I do realize the business Linux distros do tons (most?) of the kernel improvement nowadays, and that implies oblique financial transactions, but it's much more concerned than just that.
Posted Nov 7, 2015 0:36 UTC (Sat) by PaXTeam (guest, #24616) [Hyperlink]
Posted Nov 7, 2015 7:34 UTC (Sat) by nix (subscriber, #2304) [Link]
Posted Nov 7, 2015 9:49 UTC (Sat) by PaXTeam (visitor, #24616) [Link]
Posted Nov 6, 2015 23:Thirteen UTC (Fri) by dowdle (subscriber, #659) [Hyperlink]
I feel you positively agree with the gist of Jon's argument... not sufficient focus has been given to security within the Linux kernel... the article will get that half proper... cash hasn't been going in direction of safety... 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 facet of the coin is properly represented by us and others who had been interviewed. the identical means Linus is a good representative of, nicely, his own pet venture referred to as linux.
> And if Jon had solely talked to you, his would have been too.
given that i'm the creator of PaX (part of grsec) sure, talking to me about grsec matters makes it among the best methods to analysis it. but if you recognize of someone else, be my visitor and name them, i am pretty certain the just lately formed kernel self-safety people could be dying to engage them (or not, i do not think there's a sucker on the market with hundreds of hours of free time on their hand).
> [...]it also contained quite a few of groan-worthy statements.
nothing is perfect however considering the audience of the WP, that is one of the better journalistic pieces on the subject, no matter how you and others don't just like the sorry state of linux safety uncovered in there. if you would like to discuss extra technical particulars, nothing stops you from talking to us ;).
talking of your complaints about journalistic qualities, since a previous LWN article saw it fit to include a number of typical dismissive claims by Linus about the standard of unspecified grsec options with no proof of what experience he had with the code and how latest it was, how come we didn't see you or anyone else complaining about the quality of that article?
> Aren't you glad?
no, or not yet anyway. i've heard numerous empty phrases over time and nothing ever manifested or worse, all the money has gone to the pointless exercise of fixing individual bugs and related circus (that Linus rightfully despises FWIW).
Posted Nov 7, 2015 0:18 UTC (Sat) by bojan (subscriber, #14302) [Hyperlink]
Posted Nov 8, 2015 13:06 UTC (Solar) by k3ninho (subscriber, #50375) [Hyperlink]
Proper now we've received developers from large names saying that doing all that the Linux ecosystem does *safely* is an itch that they've. Sadly, the surrounding cultural angle of developers is to hit purposeful goals, and often efficiency targets. Safety goals are sometimes neglected. Ideally, the tradition would shift in order that we make it difficult to follow insecure habits, patterns or paradigms -- that is a process that may take a sustained effort, not merely the upstreaming of patches.
Regardless of the culture, these patches will go upstream ultimately anyway as a result of the ideas that they embody are actually timely. I can see a strategy to make it occur: Linus will accept them when an enormous finish-person (say, Intel, Google, Facebook or Amazon) delivers stuff with notes like 'here's a set of enhancements, we're already utilizing them to unravel this kind of drawback, this is how everything will stay working as a result of $proof, word fastidiously 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 may be gamed; I might choose that the community shepherds customers to follow the sample of declaring downside + answer + functional check proof + efficiency take a look at evidence + safety check proof.
K3n.
Posted Nov 9, 2015 6:Forty nine UTC (Mon) by jospoortvliet (guest, #33164) [Link]
And about that fork barrel: I would argue it is the other way around. Google forked and lost already.
Posted Nov 12, 2015 6:25 UTC (Thu) by Garak (guest, #99377) [Hyperlink]
Posted Nov 23, 2015 6:33 UTC (Mon) by jospoortvliet (visitor, #33164) [Link]
Posted Nov 7, 2015 3:20 UTC (Sat) by corbet (editor, #1) [Link]
So I need to confess to a specific amount of confusion. I could swear that the article I wrote said precisely that, however you've got put a good amount of effort into flaming it...?
Posted Nov 8, 2015 1:34 UTC (Sun) by PaXTeam (guest, #24616) [Hyperlink]
Posted Nov 6, 2015 22:Fifty two UTC (Fri) by flussence (subscriber, #85566) [Hyperlink]
I personally suppose you and Nick Krause share reverse sides of the identical coin. Programming capability and primary civility.
Posted Nov 6, 2015 22:59 UTC (Fri) by dowdle (subscriber, #659) [Hyperlink]
Posted Nov 7, 2015 0:16 UTC (Sat) by rahvin (guest, #16953) [Hyperlink]
I hope I am wrong, but a hostile angle is not going to assist anyone receives a commission. It is a time like this where something you seem to be an "knowledgeable" at and there is a demand for that experience the place you show cooperation and willingness to participate because it is a chance. I am comparatively shocked that someone would not get that, but I am older and have seen a few of those opportunities in my profession and exploited the hell out of them. You only get a few of those in the average career, and handful at the most.
Sometimes you need to invest in proving your abilities, and that is a type of moments. It appears the Kernel community could lastly take this safety lesson to heart and embrace it, as stated within the article as a "mindcraft second". This is an opportunity for builders that will need to work on Linux safety. Some will exploit the chance and others will thumb their noses at it. Ultimately these developers that exploit the chance will prosper from it.
I feel outdated even having to write that.
Posted Nov 7, 2015 1:00 UTC (Sat) by josh (subscriber, #17465) [Hyperlink]
Maybe there is a rooster and egg drawback here, but when in search of out and funding folks to get code upstream, it helps to pick out folks and groups with a history of being able to get code upstream.
It is perfectly affordable to want understanding of tree, offering the ability to develop spectacular and critical security advances unconstrained by upstream necessities. That's work someone may additionally want to fund, if that meets their wants.
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 analysis and Josh would not) after which fail to assist it by any cite. It would be rather more convincing in case you surrender on the Onus probandi rhetorical fallacy and actually cite information.
> working example, it was *them* who recommended that they wouldn't fund out-of-tree work but would consider funding upstreaming work, except when pressed for the details, all i obtained was silence.
For these following alongside at dwelling, that is the relevant set of threads:
http://lists.coreinfrastructure.org/pipermail/cii-focus on...
A fast precis is that they told you your venture was unhealthy because the code was by no means going upstream. You told them it was due to kernel developers perspective so they should fund you anyway. They informed you to submit a grant proposal, you whined more in regards to the kernel attitudes and eventually even your apologist informed you that submitting a proposal is perhaps the neatest thing to do. At that time you went silent, not vice versa as you indicate above.
> obviously i will not spend time to jot down up a begging proposal simply to be instructed that 'no sorry, we don't fund multi-year initiatives at all'. that is something that one ought to be told 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 people why you want the money and the way you may spend it, they're unlikely to disburse. Saying I am good and I do know the problem now hand over the cash does not even work for many Teachers who've a strong status in the sector; which is why most of them spend >30% of their time writing grant proposals.
> as for getting code upstream, how about you verify the kernel git logs (minus the stuff that was not correctly credited)?
jejb@jarvis> git log|grep -i 'Creator: pax.*staff'|wc -l
1
Stellar, I have to say. And before you gentle off on those who have misappropriated your credit, please keep in mind that getting code upstream on behalf of reluctant or incapable actors is a hugely helpful and time consuming ability and certainly one of the reasons groups like Linaro exist and are nicely funded. If more of your stuff does go upstream, it is going to be because of the not inconsiderable efforts of different folks on this space.
You now have a enterprise mannequin promoting non-upstream security patches to clients. There's nothing wrong with that, it is a reasonably usual first stage enterprise model, but it does slightly depend 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 businesses in open source: The promoting out of tree patch route is all the time an eventual failure, notably with the kernel, as a result of if the functionality is that useful, it gets upstreamed or reinvented in your despite, leaving you with nothing to promote. In case your business plan B is promoting expertise, you've gotten to keep in mind that it should be a hard promote when you have no out of tree differentiator left and git historical past denies that you had something to do with the in-tree patches. In reality "crazy security person" will turn into a self fulfilling prophecy. The advice? it was obvious to everybody else who learn this, but for you, it's do the upstreaming yourself earlier than it gets done for you. That approach you will have a professional historic declare to Plan B and you would possibly also have a Plan A selling a rollup of upstream monitor patches built-in and delivered earlier than the distributions get around to it. Even your application to the CII could not be dismissed as a result of your work wasn't going anyplace. Your various is to proceed enjoying the role of Cassandra and doubtless undergo her eventual fate.
Posted Nov 7, 2015 23:20 UTC (Sat) by PaXTeam (guest, #24616) [Link]
> Second, for the potentially viable pieces this would be a multi-12 months
> full time job. Is the CII willing to fund projects at that stage? If not
> all of us would end up with plenty of unfinished and partially broken options.
please show me the reply to that question. without a definitive 'yes' there isn't any level in submitting a proposal because that is the timeframe that in my view 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 easy primary requirements should be public info.
> Stellar, I have to say.
"Lies, damned lies, and statistics". you notice there's multiple method to get code into the kernel? how about you utilize your git-fu to search out all the bugreports/instructed fixes that went in attributable to us? as for specifically me, Greg explicitly banned me from future contributions by way of af45f32d25cc1 so it is no wonder i do not ship patches instantly in (and that one commit you discovered that went in despite said ban is definitely a very unhealthy example because it is also the one which Linus censored for no good motive and made me resolve to never send security fixes upstream till that follow modifications).
> You now have a enterprise model selling non-upstream safety patches to prospects.
now? we have had paid sponsorship for our varied stable kernel series for 7 years. i would not call it a business model although as it hasn't paid anyone's bills.
> [...]calling into query the earnestness of your attempt to place them there.
i should be lacking something right here however what try? i've never in my life tried to submit PaX upstream (for all the explanations discussed already). the CII mails were exploratory to see how serious that complete group is about actually securing core infrastructure. in a way i've acquired my answers, there's nothing extra to the story.
as to your free advice, let me reciprocate: advanced problems do not clear up themselves. code solving advanced issues would not write itself. people writing code solving complicated problems are few and much between that one can find out in brief order. such people (area consultants) do not work free of charge with few exceptions like ourselves. biting the hand that feeds you will only finish you up in starvation.
PS: since you are so certain about kernel builders' ability to reimplement our code, maybe look at what parallel options i nonetheless maintain in PaX regardless of vanilla having a 'completely-not-reinvented-right here' implementation and check out to know the explanation. or simply look at all the CVEs that affected say vanilla's ASLR but did not affect mine.
PPS: Cassandra never wrote code, i do. criticizing the sorry state of kernel security is a side challenge when i'm bored or just waiting for the subsequent kernel to compile (i want LTO was more efficient).
Posted Nov 8, 2015 2:28 UTC (Solar) by jejb (subscriber, #6654) [Link]
In other phrases, you tried to define their course of for them ... I am unable to assume why that wouldn't work.
> "Lies, damned lies, and statistics".
The problem with ad hominem attacks is that they're singularly ineffective towards a transparently factual argument. I posted a one line command anybody may run to get the number of patches you've got authored within the kernel. Why do not you put up an equal that offers figures you like extra?
> i've by no means in my life tried to submit PaX upstream (for all the explanations mentioned already).
So the grasp plan is to exhibit your experience by the number of patches you haven't submitted? great plan, world domination beckons, sorry that one acquired away from you, however I am sure you will not let it happen once more.
Posted Nov 8, 2015 2:56 UTC (Solar) by PaXTeam (visitor, #24616) [Link]
what? since when does asking a question outline anything? is not that how we discover out what another person thinks? isn't that what *they* have that webform (never mind the mailing lists) for as effectively? in different phrases you admit that my question was not truly answered .
> The problem with ad hominem attacks is that they are singularly ineffective towards a transparently factual argument.
you did not have an argument to start with, that is what i explained in the half you fastidiously selected to not quote. i'm not right here to defend myself against your clearly idiotic attempts at proving whatever you are attempting to prove, as they are saying even in kernel circles, code speaks, bullshit walks. you can look at mine and determine what i can or can not do (not that you've the information to understand most of it, thoughts you). that mentioned, there're clearly different more succesful people who've accomplished so and determined that my/our work was worth something else nobody would have been feeding off of it for the previous 15 years and still counting. and as unimaginable as it might appear to you, life 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 just now additionally demonstrated here (it is ironic the way you came to the defense of josh who specifically asked individuals not to deliver that infamous lkml style here. good job there James.). as for world domination, there're many ways to attain it and something tells me that you are clearly out of your league right here since PaX has already achieved that. you are operating such code that implements PaX features as we converse.
Posted Nov 8, 2015 16:Fifty two UTC (Solar) 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 verify the kernel git logs (minus the stuff that was not properly credited)?
I take it, by the way you've shifted ground in the previous threads, that you want to withdraw that request?
Posted Nov 8, 2015 19:31 UTC (Solar) by PaXTeam (guest, #24616) [Link]
Posted Nov 8, 2015 22:31 UTC (Solar) by pizza (subscriber, #46) [Link]
Please provide one that's not flawed, or much less unsuitable. It would take less time than you've got already wasted here.
Posted Nov 8, 2015 22:49 UTC (Solar) by PaXTeam (visitor, #24616) [Link]
anyway, since it is you guys who have a bee in your bonnet, let's take a look at your degree of intelligence too. first figure out my e mail deal with and undertaking title then strive to find the commits that say they come from there (it introduced back some recollections from 2004 already, how times flies! i'm surprised i really managed to perform this much with explicitly not attempting, imagine if i did :). it's an extremely advanced task so by accomplishing it you may show yourself to be the top canine right here on lwn, no matter that's value ;).
Posted Nov 8, 2015 23:25 UTC (Solar) by pizza (subscriber, #46) [Hyperlink]
*shrug* Or do not; you are only sullying your personal status.
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) [Hyperlink]
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 (guest, #62367) [Hyperlink]
Posted Nov 8, 2015 3:38 UTC (Sun) by PaXTeam (visitor, #24616) [Hyperlink]
Posted Nov 12, 2015 13:Forty seven UTC (Thu) by nix (subscriber, #2304) [Hyperlink]
Ah. I believed my reminiscence wasn't failing me. Compare to PaXTeam's response to .
PaXTeam is not averse to outright lying if it means he will get to appear right, I see. Maybe PaXTeam's memory is failing, and this apparent contradiction just isn't a brazen lie, but given that the 2 posts have been made inside a day of one another I doubt it. (PaXTeam's complete unwillingness to assume good faith in others deserves some reflection. Yes, I *do* think he is mendacity by implication right here, and doing so when there's virtually nothing at stake. God alone knows what he is prepared 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 discovered that went in regardless of mentioned ban
additionally somebody's ban doesn't suggest 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 security fix to expose the fallacy of this coverage though. the remainder of your pithy ad hominem speaks for itself higher than i ever could ;).
Posted Nov 12, 2015 15:58 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 got swallowed.
Posted Nov 7, 2015 22:33 UTC (Sat) by ssmith32 (subscriber, #72404) [Link]
You are conscious that it is completely possible that everyone seems to be mistaken 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 security, and do nothing to assist, and that your patchsets would not help that a lot and are the unsuitable course for the kernel? That simply because the kernel maintainers aren't 100% proper it doesn't mean you are?
Posted Nov 9, 2015 9:50 UTC (Mon) by njd27 (guest, #5770) [Link]
I think you might have him backwards there. Jon is comparing this to Mindcraft as a result of he thinks that despite being unpalatable to a lot of the community, the article may actually include a lot of fact.
Posted Nov 9, 2015 14:03 UTC (Mon) by corbet (editor, #1) [Link]
Posted Nov 9, 2015 15:Thirteen UTC (Mon) by spender (guest, #23067) [Link]
"There are rumors of darkish forces that drove the article within the hopes of taking Linux down a notch. All of this might well be true"
Just as you criticized the article for mentioning Ashley Madison despite the fact that in the very first sentence of the following paragraph it mentions it did not contain the Linux kernel, you cannot give credence to conspiracy theories with out incurring the same criticism (in different phrases, you cannot play the Glenn Beck "I'm just asking the questions right here!" whose "questions" fuel the conspiracy theories of others). Much like mentioning Ashley Madison for instance for non-technical readers about the prevalence of Linux on the earth, if you are criticizing the point out then shouldn't likening a non-FUD article to a FUD article additionally deserve criticism, particularly given the rosy, self-congratulatory picture you painted of upstream Linux safety?
As the PaX Crew pointed out within the preliminary post, the motivations aren't arduous to know -- you made no mention at all about it being the fifth in a protracted-working collection following a reasonably predictable time trajectory.
No, we didn't miss the general analogy you have been trying 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) [Link]
It is gracious of you not to 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 "safety" of us (PaXTeam/spender), nor the mainstream kernel folks in terms of their attitude. I confess I have totally no technical capabilities on any of these subjects, but if they all determined to work collectively, instead of having countless and pointless flame wars and blame recreation exchanges, a variety of the stuff would have been executed already. And all of the whereas everyone concerned might have made another large pile of cash on the stuff. They all seem to wish to have a better Linux kernel, so I've received no thought what the issue is. It seems that nobody is keen to yield any of their positions even slightly bit. As an alternative, each sides seem like bent on trying to insult their approach into forcing the opposite aspect to quit. Which, after all, never works - it simply 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) [Link]
Take a scientific computational cluster with an "air gap", for example. You'd most likely need most of the safety stuff turned off on it to achieve maximum efficiency, because you'll be able to trust all users. Now take just a few billion mobile phones which may be difficult or slow to patch. You'd probably need to kill lots of the exploit classes there, if those units can nonetheless run moderately nicely with most security features turned on.
So, it's not both/or. It's in all probability "it relies upon". But, if the stuff is not there for everyone to compile/use in the vanilla kernel, it will likely be tougher 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 unhappy. This Dijkstra quote comes to thoughts immediately:
Software program engineering, after all, presents itself as another worthy trigger, however that's eyewash: in the event you carefully learn its literature and analyse what its devotees really do, you'll 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) [Link]
I suppose that truth 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 attention-grabbing factor to me is that when I attain that time, assessments are not enough - model checking at a minimal and really proofs are the one approach forwards. I'm no security professional, my area is all distributed techniques. I understand and have implemented Paxos and that i imagine I can explain how and why it really works to anyone. However I'm currently doing a little algorithms combining Paxos with a bunch of variations on VectorClocks and reasoning about causality and consensus. No take a look at is enough because there are infinite interleavings of events and my head just could not cope with working on this either at the pc or on paper - I found I could not intuitively cause about these items at all. So I started defining the properties and wanted and step by step proving why every of them holds. With out my notes and proofs I can not even clarify to myself, let alone anyone else, why this factor works. I find this each fully obvious that this can occur and completely terrifying - the maintenance cost of those algorithms is now an order of magnitude larger.
Posted Nov 19, 2015 12:24 UTC (Thu) by Wol (subscriber, #4433) [Hyperlink]
> Indeed. And the interesting factor to me is that once I attain that time, checks should not sufficient - model checking at a minimal and really proofs are the only way forwards.
Or are you simply utilizing the flawed maths? Hobbyhorse time once more :-) however to quote a fellow Pick developer ... "I typically stroll into a SQL improvement shop and see that wall - you realize, the one with the massive SQL schema that no-one totally understands on it - and surprise how I can easily hold your entire schema for a Decide database of the same or larger complexity in my head".
But it is simple - by schooling I'm a Chemist, by interest a Bodily Chemist (and by profession an unemployed programmer :-). And when I'm thinking about chemistry, I can ask myself "what is an atom made from" and assume about issues like the sturdy nuclear force. Next stage up, how do atoms stick together and make molecules, and think about the electroweak power and electron orbitals, and how do chemical reactions happen. Then I think about molecules stick collectively to make supplies, and think about metals, and/or Van de Waals, and stuff.
Point is, you have to *layer* stuff, and take a look at things, and say "how can I cut up components off into 'black containers' so at anyone level I can assume the other ranges 'just work'". For instance, with Pick a FILE (table to you) shops a category - a collection of identical objects. One object per Record (row). And, identical as relational, one attribute per Subject (column). Are you able to map your relational tables to actuality so simply? :-)
Going again THIRTY years, I remember a story about a guy who constructed little laptop crabs, that could fairly happily scuttle around in the surf zone. Because he did not attempt to work out how to resolve all the issues without delay - every of his (incredibly puny by right now's requirements - that is the 8080/Z80 era!) processors was set to only process just a little bit of the issue and there was no central "brain". But it worked ... Maybe you need to just write a bunch of small modules to resolve every individual drawback, and let ultimate reply "simply occur".
Cheers,
Wol
Posted Nov 19, 2015 19:28 UTC (Thu) by ksandstr (guest, #60862) [Link]
To my understanding, this is strictly what a mathematical abstraction does. For instance in Z notation we'd construct schemas for the varied modifying ("delta") operations on the bottom schema, and then 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 means 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 end result and outputs. Thus proving the formal design correct (w/ caveat lectors concerning scope, correspondence with its implementation [though that may be proven as nicely], and skim-only ["xi"] operations).
Posted Nov 20, 2015 11:23 UTC (Fri) by Wol (subscriber, #4433) [Hyperlink]
Wanting by means of the history of computing (and possibly loads of other fields too), you will in all probability find that individuals "can't see the wood for the bushes" extra usually that not. They dive into the element and utterly miss the large picture.
(Drugs, and interest of mine, suffers from that too - I remember anyone talking about the marketing consultant wanting to amputate a gangrenous leg to save lots of somebody's life - oblivious to the truth that the patient was dying of cancer.)
Cheers,
Wol
Posted Nov 7, 2015 6:35 UTC (Sat) by dgc (subscriber, #6611) [Hyperlink]
https://www.youtube.com/watch?v=VpuVDfSXs-g
(LCA 2015 - "Programming Thought of Harmful")
FWIW, I think that this speak could be very relevant to why writing secure software program is so laborious..
-Dave.
Posted Nov 7, 2015 5:49 UTC (Sat) by kunitz (subscriber, #3965) [Hyperlink]
While we are spending millions at a multitude of safety problems, kernel points should not on our top-precedence record. Truthfully I remember solely as soon as having discussing a kernel vulnerability. The result of the analysis has been that every one our techniques have been running kernels that have been older because the kernel that had the vulnerability.
But "patch management" is a real challenge for us. Software should continue to work if we install safety patches or update to new releases because of the tip-of-life coverage of a vendor. The revenue of the corporate is depending on the IT programs working. So "not breaking person area" 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 safety update.
Another downside is embedded software program or firmware. These days almost all hardware systems embrace an working system, usually some Linux model, providing a fill network stack embedded to help distant management. Regularly these systems don't survive our obligatory safety scan, because vendors still didn't replace the embedded openssl.
The real challenge is to offer a software program stack that may be operated within the hostile atmosphere of the Web sustaining full system integrity for ten years and even longer with none customer upkeep. The current state of software program engineering will require help for an automatic update course of, but distributors must understand that their business model should be capable of finance the assets offering the updates.
General I'm optimistic, networked software isn't the first expertise utilized by mankind inflicting problems that had been addressed later. Steam engine use could result in boiler explosions but the "engineers" were ready to cut back this danger significantly over a number of 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 evidence either a technique or another on this: The individuals who learn to hack into these programs by means of kernel vulnerabilities know that they skills they've learnt have a market. Thus they do not are likely to hack as a way to wreak havoc - certainly on the whole where knowledge has been stolen so as to release and embarrass individuals, it _seems_ as though these hacks are by means of a lot less complicated vectors. I.e. lesser expert hackers find there is a whole load of low-hanging fruit which they will get at. They don't seem to be being paid forward of time for the data, in order that they flip to extortion instead. They do not cowl their tracks, and they will often be discovered and charged with criminal offences.
So in case your safety meets a certain primary level of proficiency and/or your organization is not doing something that places it close to the top of "corporations we would wish to embarrass" (I think the latter is way more effective at holding systems "safe" than the former), then the hackers that get into your system are prone to be expert, paid, and possibly not going to do much injury - they're stealing information for a competitor / state. So that doesn't bother your backside line - no less than not in a manner which your shareholders will remember of. So why fund safety?
Posted Nov 7, 2015 17:02 UTC (Sat) by citypw (guest, #82661) [Link]
Alternatively, some effective mitigation in kernel level could be very useful to crush cybercriminal/skiddie's attempt. If certainly one of your buyer running a future buying and selling platform exposes some open API to their purchasers, and if the server has some memory corruption bugs may be exploited remotely. Then you know there are recognized attack strategies( such as offset2lib) will help the attacker make the weaponized exploit a lot easier. Will you explain the failosophy "A bug is bug" to your buyer and tell them it would be ok? Btw, offset2lib is useless to PaX/Grsecurity's ASLR imp.
To probably the most business makes use of, more security mitigation inside the software won't cost you extra budget. You will still should do the regression take a look at for every improve.
Posted Nov 12, 2015 16:14 UTC (Thu) by andreashappe (subscriber, #4810) [Link]
Understand that I concentrate on external internet-based mostly penetration-assessments and that in-house exams (native LAN) will possible yield completely different outcomes.
Posted Nov 7, 2015 20:33 UTC (Sat) by mattdm (subscriber, #18) [Hyperlink]
I keep reading this headline as "a brand new Minecraft second", and thinking that perhaps they've determined to observe up the .Net thing by open-sourcing Minecraft. Oh properly. I mean, safety is good too, I suppose.
Posted Nov 7, 2015 22:24 UTC (Sat) by ssmith32 (subscriber, #72404) [Hyperlink]
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 (guest, #33164) [Hyperlink]
Posted Nov 9, 2015 15:Fifty three UTC (Mon) by neiljerram (subscriber, #12005) [Hyperlink]
(Oh, and I used to be also nonetheless wondering how Minecraft had taught us about Linux efficiency - so due to the other comment thread that identified the 'd', not 'e'.)
Posted Nov 9, 2015 11:31 UTC (Mon) by ortalo (guest, #4654) [Link]
I might identical to to add that in my opinion, there's a normal downside with the economics of pc security, which is especially seen at the moment. Two issues even possibly.
First, the money spent on computer safety is usually diverted towards the so-known as safety "circus": fast, easy solutions which are primarily selected just with the intention to "do something" and get higher press. It took me a long time - perhaps many years - to assert that no safety mechanism in any respect is better than a bad mechanism. However now I firmly believe in this perspective and would rather take the danger knowingly (supplied that I can save cash/resource for myself) than take a bad method at solving it (and haven't any money/resource left when i notice I should have executed something else). And that i discover there are numerous unhealthy or incomplete approaches presently obtainable in the computer security area.
These spilling our rare money/sources on prepared-made ineffective tools ought to get the bad press they deserve. And, we definitely need to enlighten the press on that because it is not really easy to appreciate the effectivity of safety mechanisms (which, by definition, ought to stop issues from occurring).
Second, and that could be more moderen and more worrying. The circulate of cash/resource is oriented within the path of assault tools and vulnerabilities discovery much greater than in the direction of latest protection mechanisms.
This is particularly worrying as cyber "defense" initiatives look increasingly more like the same old idustrial initiatives aimed at producing weapons or intelligence programs. Moreover, bad ineffective weapons, because they are only working towards our very vulnerable present programs; and dangerous intelligence techniques as even basic faculty-degree encryption scares them all the way down to useless.
However, all of 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-degree cryptanalysis. And now also for the cyberwarriors and cyberspies which have but to prove their usefulness entirely (especially for peace safety...).
Personnally, I'd fortunately go away them all the hype; but I'll forcefully claim that they have no right by any means on any of the budget allocation selections. Only these engaged on safety ought to. And yep, it means we should always resolve where to put there resources. Now we have to claim the exclusive lock for ourselves this time. (and I assume the PaXteam could possibly be amongst the primary to learn from such a change).
Whereas fascinated with it, I would not even go away white-hat or cyber-guys any hype ultimately. That's more publicity than they deserve.
I crave for the day I'll learn within the newspaper that: "One other of those ill advised 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 bring a kind of unfinished and bad quality applications, X, that we are all obliged to use to its knees, annoying hundreds of thousands of standard customers with his unfortunate cyber-vandalism. All of the protection consultants unanimously advocate that, as soon as again, the funds of the cyber-command be retargetted, or not less than leveled-off, with a view to convey 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 in this affair."
Hmmm - cyber-hooligans - I just like the label. Although it doesn't apply well to the battlefield-oriented variant.
Posted Nov 9, 2015 14:28 UTC (Mon) by drag (visitor, #31333) [Link]
The state of 'software program security industry' is a f-ng catastrophe. Failure of the highest order. There is massive quantities of money that goes into 'cyber security', however it's usually spent on authorities compliance and audit efforts. This implies as a substitute of really placing effort into correcting points and mitigating future problems, the majority of the trouble goes into taking present applications and making them conform to committee-driven pointers with the minimal amount of effort and changes.
Some level of regulation and standardization is completely wanted, however lay persons are clueless and are completely unable to discern the difference between any individual who has valuable expertise versus some company that has spent thousands and thousands on slick advertising and 'native promoting' on massive websites and laptop magazines. The people with the cash unfortunately solely have their own judgment to depend on when buying into 'cyber safety'.
> These spilling our uncommon money/sources on ready-made ineffective tools ought to get the dangerous press they deserve.
There is no such thing as 'our uncommon cash/assets'. You have got your cash, I've mine. Cash being spent by some company like Redhat is their cash. Cash being spent by governments is the federal government's money. (you, literally, have far more management in how Walmart spends it's 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 standard idustrial initiatives geared toward producing weapons or intelligence systems. Furthermore, unhealthy ineffective weapons, because they are solely working against our very vulnerable present programs; and bad intelligence systems as even basic school-stage encryption scares them right down to useless.
Having secure software program with robust encryption mechanisms in the fingers of the general public runs counter to the pursuits of most major governments. Governments, like every other for-profit organization, are primarily keen on self-preservation. Cash spent on drone initiatives or banking auditing/oversight regulation compliance is Way more invaluable to them then trying to assist the general public have a safe mechanism for making cellphone calls. Especially when those secure mechanisms interfere with knowledge assortment efforts.
Sadly you/I/us can't rely upon some magical benefactor with deep pockets to sweep in and make Linux higher. It is simply not going to happen.
Firms like Redhat have been massively useful to spending assets to make Linux kernel extra succesful.. nevertheless they're pushed by a the need to show a revenue, which suggests they need to cater on to the the kind of necessities established by their customer base. Clients for EL are typically much more targeted on decreasing costs related to administration and software growth then safety on the low-level OS.
Enterprise Linux customers are inclined to depend on physical, human policy, and network safety to protect their 'tender' interiors from being uncovered to exterior threats.. assuming (rightly) that there's little or no they can do to really harden their programs. In reality when the selection comes between safety vs comfort I am certain that the majority clients will happily defeat or strip out any security mechanisms introduced into Linux.
On high of that when most Enterprise software is extraordinarily unhealthy. So much so that 10 hours spent on bettering a web front-finish will yield extra real-world security benefits then a 1000 hours spent on Linux kernel bugs for many companies.
Even for 'normal' Linux customers a security bug of their Firefox's NAPI flash plugin is far more devastating and poses a massively larger risk then a obscure Linux kernel buffer over movement downside. It's just probably not important for attackers to get 'roo