A crypto module loading vulnerability
A crypto module loading vulnerability
Posted Jan 29, 2015 8:03 UTC (Thu) by josh (subscriber, #17465)In reply to: A crypto module loading vulnerability by Lionel_Debroux
Parent article: A crypto module loading vulnerability
(Also, the kernel does have at least one protection mechanism against executing userspace code in kernel mode now.)
Posted Jan 29, 2015 11:28 UTC (Thu)
by spender (guest, #23067)
[Link] (16 responses)
I was simply mentioning grsec in response to the article since it didn't mention it at all. If you're jealous of actual innovation and want to make excuses for upstream security, expect factual responses ;)
BTW "grsecurity" never submitted anything mainline. I myself have only ever to my knowledge sent two mails to LKML, one to report a DoS in execve, one to report a boot failure on a rare Itanium system. Both of those no more recent than four years ago. So if you think our goal is to upstream grsecurity, or feel that it is somehow our fault for not upstreaming it and therefore upstream Linux can be absolved of fault for its lack of security, I don't think you understand anything at all really ;)
-Brad
Posted Jan 29, 2015 12:11 UTC (Thu)
by BlueLightning (subscriber, #38978)
[Link] (14 responses)
1) Keep on pointing out how useless you think the Linux kernel is at handling these issues
2) Get stuck in and fix it in the kernel upstream.
Obviously, #2 is harder, but if you actually want things to improve for the benefit of everyone, it's the most effective way to ensure that.
Posted Jan 29, 2015 14:10 UTC (Thu)
by spender (guest, #23067)
[Link] (12 responses)
So, since I don't need the permission of you or anyone else to do what I feel like in my free time, I will continue pointing out how upstream Linux fails to be motivated at all really to create and properly maintain useful security features, as well as how their perspective of security being the fixing of individual bugs is detrimental to their users.
Does not upstream or Red Hat or any other distro selling a product have a responsibility to provide a secure kernel? Even Microsoft has understood that for some years now. It's not my fault that you and others get defensive when faced with the embarrassing fact that neither a huge team of upstream developers and the entire sum of *paid* distro security teams have been able to create anything to match that of three people working on security in their free time over the past 13 years.
So keep doing what you're doing, which doesn't seem to include directing your angst at the people creating the problem, and I'll keep doing what I've been doing: creating useful security for free that anyone who wishes to can use.
-Brad
Posted Jan 29, 2015 16:23 UTC (Thu)
by cesarb (subscriber, #6266)
[Link] (6 responses)
People get defensive when something is rubbed in their face all the time. So yeah, at least in part the defensiveness is your fault.
> that neither a huge team of upstream developers and the entire sum of *paid* distro security teams have been able to create anything to match that of three people working on security in their free time over the past 13 years.
You are standing in the shoulder of giants; the huge team of upstream developers has been working all this time to make the rest of the kernel. Hardening is just one of the many considerations they have; there's a cost-value tradeoff on everything added to the kernel, and hardening often has a large cost (the comment just below yours mentions one kind of hardening breaking many applications) for dubious value (hardening is a "backstop" against other bugs, which shouldn't exist in the first place).
They *could* have matched your output in these years, if they had put security above all other considerations. This seems to be a "blind spot" of many security professionals; they believe security to be the most important characteristic. But a highly secure system that nobody uses is worthless. The Linux kernel has grown in capability, while at the same time matching the hardware evolution; don't forget that the original system Linux ran in had a slow 32-bit single-core processor, no hotplug, no power management... Contrast with a recent LWN article mentioning optimizations so the kernel can deal with 100 Gb/s of network packets (https://lwn.net/Articles/629155/).
Posted Feb 1, 2015 21:04 UTC (Sun)
by imitev (guest, #60045)
[Link] (5 responses)
People shouldn't get defensive when better security practices thrown at their face could result in systems making it harder for government agencies to spy so easily, for home routers, IoT stuff, you-name-it to become part of botnets, or for whatever-latest-fancy-bug-in-the-news to be exploited.
>> ... for dubious value (hardening is a "backstop" against other bugs, which shouldn't exist in the first place).
Do you really mean that no security protections are needed at all since no bug should exist in the first place ? That's utopic at best.
>> But a highly secure system that nobody uses is worthless.
FWIW, I'm using a custom grsecurity kernel on my centos 7 servers for a few months now, and I had *0* problem, without any tweak needed for the kernel nor user-space. And for whatever reason (leaner or more recent kernel ?) I didn't witness any performance drop compared to the stock kernel. And that's with CONFIG_GRSECURITY_* stuff set to max security, not performance tradeoff.
Spender made it clear a few times that he doesn't consider pushing those patches to mainline, but I'm still wondering why no maintstream distro boasting security in their PR ads ever picked the patches, either as an alternate kernel, or with a way to enable some of the patches as opt-in.
Performance vs. security will always be a tradeoff, and it's a good thing that linux can deal with 100gb/s traffic, but the problem is that performance in linux is over-represented at the cost of security being a second class citizen.
Posted Feb 1, 2015 22:29 UTC (Sun)
by cesarb (subscriber, #6266)
[Link] (4 responses)
People aren't emotionless robots. While cold logic would dictate that one should ignore the "thrown at their face" part, normal people feel annoyed by it. Presentation matters.
> Do you really mean that no security protections are needed at all since no bug should exist in the first place ? That's utopic at best.
No, I mean that the value of hardening protections is reduced by the fact that they only have any value in the presence of other bugs. The more these other bugs are fixed or avoided, the smaller the value of hardening becomes, while its cost remains the same. And the cost is not only performance; things like breaking programs (remember that "don't break userspace" is an important rule in kernel development), or making programs harder to develop or debug, or even extra complexity in the kernel, are also a real cost.
> Spender made it clear a few times that he doesn't consider pushing those patches to mainline, but I'm still wondering why no mainstream distro boasting security in their PR ads ever picked the patches, either as an alternate kernel, or with a way to enable some of the patches as opt-in.
Maintaining out-of-tree patches has a cost. Alternate kernel or opt-in is even worse, since it blows up the testing matrix: every new independent option doubles the number of possible test scenarios. And I believe these mainstream distributions all learned the hard way to avoid diverging from mainline too much.
So the best way to get these patches into mainstream distributions would be to push them into mainline. Since their creator doesn't want to do it himself, they would need an advocate to do that process. I have no insight on why such an advocate is lacking, but it's possible that abrasive behavior has pushed potential advocates away (as I said above, presentation matters).
> Performance vs. security will always be a tradeoff, and it's a good thing that linux can deal with 100gb/s traffic, but the problem is that performance in linux is over-represented at the cost of security being a second class citizen.
It's not just performance, it's also features. Things like being able to use new hardware, for instance. So the tradeoff is not "performance vs security"; it's "performance vs power usage vs required memory vs new hardware vs security vs ..."
Performance is the most talked about because it's easily quantifiable; one can easily point that "this proposed security patch makes a CPU-bound program 2% slower", for instance, while quantifying "this proposed security patch makes the memory management code even more complicated" is harder. But performance is not the only consideration.
The most important consideration would be, I believe, developer and reviewer time. And that's where the tradeoff has the most influence; most developers don't have a "security mindset" (https://www.schneier.com/blog/archives/2008/03/the_securi...), which could be described as "looking at the world through the eyes of an attacker". Most developers are not interested in "making the most secure system ever"; they want to make it run in their hardware, or make it run faster in their hardware, or make it do more interesting and useful things in their hardware.
Which, in the end, is what really matters. "Being secure", by itself, is useless; when people talk about a secure system, they mean "do X but securely", with the "do X" part being what the system actually does, and the "but securely" being an addition. If the system doesn't do X, it will be replaced by a system which does X, even if it's "less secure". If a system's developers focus too much on being secure, to the exclusion of everything else, not many people will use it, and a highly secure system that nobody uses is worthless.
Posted Feb 2, 2015 0:38 UTC (Mon)
by spender (guest, #23067)
[Link] (3 responses)
You keep mentioning how hardening only has value in the existence of bugs -- let me know in what century that eradication becomes possible. It's funny that you make mention of bugs being avoided, as that itself (e.g seccomp) is an example of security hardening. Not to mention the cost of finding and fixing bugs of the same classes over and over again (while at the same time introducing more of the same type) versus implementing generic defenses against these bug classes. You advocate a strategy that is immensely inefficient as far as security goes.
You also make mention of "breaking programs" but I don't think you really know what you're talking about. In the majority of cases, this is a simple problem for distros to fix -- it's not the job of the kernel. For the same reason PT_GNU_STACK (an upstream "feature") can break apps or reduce security unnecessarily if configured improperly, some features of grsecurity and PaX need proper userland configuration. We even provide a daemon to fix these issues automatically without any specific distro support -- that's by no means "breaking programs".
The fact that grsecurity exists, that it operates on top of the Linux kernel and provides all the same features, supports all the same hardware, and benefits from the same performance improvements you claim can't possibly exist in conjunction with security -- it's a trivial proof by construction that renders your argument nonsensical.
Why bother defending something that's clearly lacking? You'd at least have some shred of credibility if you could admit simple truths.
-Brad
Posted Feb 2, 2015 12:47 UTC (Mon)
by cesarb (subscriber, #6266)
[Link] (2 responses)
I didn't say that; I said that security to the exclusion of everything else, or even an excessive focus on security, would get nothing useful done.
> You keep mentioning how hardening only has value in the existence of bugs -- let me know in what century that eradication becomes possible. It's funny that you make mention of bugs being avoided, as that itself (e.g seccomp) is an example of security hardening.
Seccomp is not a bug being avoided, it's merely security hardening. Avoiding bugs is using compiler features, static checkers, or even design patterns to prevent the bug from happening in the first place. A simple example is the "must check the return value" function attribute, which makes it harder to forget to check the return value of a function. Another example is the "printf format" function attribute, which warns the developer when the arguments don't match the format.
Yes, erradication is not possible, even with formal proofs (since the formal specification might be wrong). But it doesn't change the fact that fixing or avoiding bugs reduce the value of hardening, without reducing its cost.
> You also make mention of "breaking programs" but I don't think you really know what you're talking about.
Since I've never used grsecurity or PaX, I'm going by second-hand information; I had just read a comment on a nearby thread mentioning that one feature of one of them breaks several programs.
> In the majority of cases, this is a simple problem for distros to fix -- it's not the job of the kernel. For the same reason PT_GNU_STACK (an upstream "feature") can break apps or reduce security unnecessarily if configured improperly, some features of grsecurity and PaX need proper userland configuration.
So it's a case of "breaks programs unless configured not to", and doing that configuration has a cost. That's what I'm talking about - these hardening features have a cost and a value, and there's a tradeoff between them. And the cost and value functions are different for different people; you value security so highly that the cost becomes trivial, but for people with different value functions, the comparative cost is higher.
> The fact that grsecurity exists, that it operates on top of the Linux kernel and provides all the same features, supports all the same hardware, and benefits from the same performance improvements you claim can't possibly exist in conjunction with security -- it's a trivial proof by construction that renders your argument nonsensical.
But who wrote all these features, hardware support, and performance enhancements? As I mentioned in my initial comment, you are standing in the shoulder of giants. The developers who wrote all those things weren't focused on security; they were focused on writing the features, hardware support, and performance enhancements. Had they focused on security instead, would we have all these things? Or would we have a highly secure system that nobody would use?
Posted Feb 3, 2015 10:24 UTC (Tue)
by imitev (guest, #60045)
[Link] (1 responses)
Something like selinux in strict/mls mode would be a good example of getting nothing useful done for casual computer use. But grsecurity patches proved to be unintrusive and they are useful in protecting a system from a vast range of exploits.
>> But it doesn't change the fact that fixing or avoiding bugs reduce the value of hardening, without reducing its cost.
We may agree to disagree then. LWN articles and some maintainers often lament the lack of proper review of kernel patches, and with the current kernel development pace it's not like we're fixing more bugs that we're creating. And even if that trend was reversed, providing global safeguards (hardening) that would protect against a single but devastating exploit still has a huge value.
>> [...] you are standing in the shoulder of giants. The developers who wrote all those things weren't focused on security; they were focused on writing the features, hardware support, and performance enhancements
True. Hence the problem that you have to add security as an after-thought, and then people complain that it breaks stuff or hurts performance (which as stated before, wasn't even the case with grsecurity for my particular use cases). Compared for instance to managing a selinux system, fixing a few grsecurity flags for user space programs requiring lower security is dead easy. Mainstream distributions have much more invasive customizations so it's not like they couldn't fix this if they decided to ship grsecurity.
In a pre-Snowden world you could have said that paying more attention to security would slow kernel/linux development, but today people are finding out the hard way that there's indeed a need for better security. I have a feeling that the majority of kernel devs still focuses more on coding style issues than security, which is a pitty. The perceived abrasiveness of security people is not a reason to ignore their work altogether and throw out the baby with the water bath. In comparison Linus is pretty abrasive too, but nobody seems to have anything to say about it.
I'd recommend you give grsecurity a try, there's no need to be a security expert. For me the "cost" you often mention has been to figure out what the bazillion config options a vanilla kernel has nowadays were for, and setting a build environment. Save for reading the documentation of the various grsec config options, the cost of running grsecurity kernels has been 0 so far.
Posted Feb 4, 2015 1:21 UTC (Wed)
by flussence (guest, #85566)
[Link]
True, though on the other hand Linus doesn't make a habit out of gloating at other people's mistakes in the comments of articles here.
*Your* post is doing a much better job of promoting grsec, FWIW. I can read it without feeling attacked for using a mainline kernel...
Posted Jan 29, 2015 17:35 UTC (Thu)
by flussence (guest, #85566)
[Link] (4 responses)
Posted Jan 29, 2015 17:52 UTC (Thu)
by Limdi (guest, #100500)
[Link] (3 responses)
Posted Feb 5, 2015 15:09 UTC (Thu)
by Wol (subscriber, #4433)
[Link] (2 responses)
It's just because most people expect to switch their computer on and get a login prompt. They don't know anything about how it gets there, and are afraid to try, because they think any cock-up will need a complete re-install.
(And yes, when things go wrong, recovering can be a right pain - been there, done that!)
That's basically it - fear of the unknown. I don't like messing about REPLACING known-good stuff (which is why I don't like grub2-mkconfig that much!) but I build new kernels, I *add* them to my boot scenario, and it's pretty easy.
It's like driving a car - many of us oldies are much better at looking after our cars not because we can do any of the maintenance, but because we understand how cars work we look after them better such that maintenance is less necessary.
Too many people remember the old days of tvs when "if it doesn't work, hit it" was good advice. So, in good old cargo-cult science mode, when an lcd tv doesn't work they hit it and wonder why it breaks :-)
If you actually learn what goes on under the covers, custom kernels shouldn't be scary at all ... :-)
Cheers,
Posted Feb 5, 2015 16:17 UTC (Thu)
by cesarb (subscriber, #6266)
[Link] (1 responses)
When you use a distribution-provided kernel, it's updated through the package manager. You don't have to do anything other than keeping the distribution updated; it'll be kept up-to-date together with the rest of the system.
When you use a custom kernel, you're responsible for updating it. You have to follow the announcements for new kernel releases, download the patches and recompile every time a new version is released.
Posted Feb 5, 2015 16:23 UTC (Thu)
by dlang (guest, #313)
[Link]
Posted Jan 29, 2015 14:14 UTC (Thu)
by Lionel_Debroux (subscriber, #30014)
[Link]
The former consists mostly in analysis, development, coding and debugging work. It requires higher technical skills, and it is performed (mainly on their spare time) by persons who'd rather focus on good defensive measures (as opposed to half-measures of the "better than nothing, but still far short of good" variety, ala KASLR), coding, and some argumented finger pointing at ongoing insecurity policies.
The latter is a matter of security-minded programmers integrating existing code in working shape, dealing with politics (getting changes accepted in the first place, staying firm on not reducing the value of PaX / grsec protections as part of mainlining), following up on core and subsystem maintainers, etc.
Gentoo hardened, Arch and openSUSE, among others, have done some work in the area of integrating PaX / grsec at the kernel package and the packaging system levels. This is a double-edged sword, which raises the weight of PaX / grsec (historically, mainline has already shown some receptiveness to originally out-of-tree, but time-proven patches carried by distros), but also makes it easier to sidestep mainline integration.
Posted Feb 2, 2015 9:57 UTC (Mon)
by edeloget (subscriber, #88392)
[Link]
With all the genuine respect I have for you and for your work, if you don't do it, who will? I don't have your knowledge on these issues, and I suspect many other are in the same case, so placing this burden onto our shoulders is a recipe for disaster.
A crypto module loading vulnerability
A crypto module loading vulnerability
A crypto module loading vulnerability
A crypto module loading vulnerability
A crypto module loading vulnerability
A crypto module loading vulnerability
A crypto module loading vulnerability
A crypto module loading vulnerability
A crypto module loading vulnerability
The cost for users is ~0, and for kernel devs they'll have to adapt the work / PoC Spender has done. IMO the value/cost ratio is huge.
A crypto module loading vulnerability
A crypto module loading vulnerability
A crypto module loading vulnerability
A crypto module loading vulnerability
Wol
A crypto module loading vulnerability
A crypto module loading vulnerability
A crypto module loading vulnerability
I'm told that rebasing PaX / grsec changes onto mainline for each kernel version, every ~60-70 days nowadays, is not an insurmountable task.
IMO, the latter is a job for RedHat, Google and/or other large organizations with large Linux interests, who can afford the expense of men-months of skilled developers performing some kind of interface between the PaX / grsec code and top kernel devs.
Bystanders can help filtering the useful bits by taking care of the easier bits of the huge PaX and grsecurity patches, some of which are drive-by changes not too directly security-related.
Though it can be done outside the packaging system, with e.g. paxd, packaging system integration is probably more likable to distros for setting the appropriate xattrs on hundreds of insecure applications which die horribly in PaX enforcing mode.
Distro grsec packages nullify the protective value of struct layout randomization, but machines running distro grsec kernel remain far less convenient for attackers to exploit than machines running distro mainline kernel packages.
A crypto module loading vulnerability