A crypto module loading vulnerability
A crypto module loading vulnerability
Posted Feb 1, 2015 21:04 UTC (Sun) by imitev (guest, #60045)In reply to: A crypto module loading vulnerability by cesarb
Parent article: A crypto module loading vulnerability
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...
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