Practical security for 2014 [LWN.net]

Practical security for 2014

Posted Jan 16, 2014 22:08 UTC (Thu) by paulj (subscriber, #341)
In reply to: Practical security for 2014 by raven667
Parent article: Practical security for 2014

No, I don't believe there is "secure" technology out there at the moment. In a much earlier comment I said we need a lot more research on how to build secure systems. Possibly there's room for more hardware-checked abstractions, as I think helloworld pointed out earlier, which I'd agree with. Certainly, I think we need more to build more tools, e.g. parser generators / serialisers for low-level binary streams (file formats, network protocols, etc), to at least automate some of the tedious, syntactic stuff.

I completely agree with you there's a sliding scale of risk.

I just don't believe there's any prospect for the Linux kernel and/or early-boot code, to ever be sufficiently "free" of bugs, where that means that at any point of time, the probability that any competent hacker will know of or be able to find within O(days / low # of weeks) an exploitable bug will be sufficiently below 1 to be of value¹. I just don't think there's any prospect of this happening without radical changes in how this code gets developed - my sense of security history strongly strongly suggests.

I'm not saying don't fix the bugs when they're found. However, I don't see the point in removing the *useful* functionality and flexibility (inc ease of install), and *adding* significant complexity, in order to gain the assurance that the code *was* the code we intended to run, when the problem is how easy that code is to subvert at runtime.

The weak link is that we're writing software using practices known to give rise to *high* numbers of defects. We don't know how to write 0 defect code, but there are known ways to reduce the defect rate. I think those would be far more effective than SecureBoot, and they needn't cost flexibility.

Going back to the sliding scale of risk - Secure Boot just doesn't do much to budge it. The problem is the practice of software engineering, which SecureBoot does nothing for. The exploitable system remains so, despite SecureBoot (and potentially persistently so even to fixed exploits, until this network boot check thing is rolled out, and even then nothing can be done about the unknown, unfixed exploits - not in scope for SecureBoot).

Now, mjg59 and I guess you have a different view on how achievable that probabilistic "free" of bugs condition is. I accept that you, mjg59 and others take a more optimistic view. However, I and yet others do not believe history justifies that optimism. On my assumption, I think SecureBoot gives you the knowledge that you booted the right buggy and easily compromised software, while taking useful functionality away,m and adding complexity with further bugs. I don't think that trade-off is worth much to me.

I am though more optimistic about the scope for improving security through better engineering of the software, perhaps with some hardware assistance. I think there's room there to make a significant impact on security over the next decade or two. Further, work in that area does *NOT* have to require giving the keys to what users may boot to large corporations, which makes it more valuable again to me.

I'm trying to be fairly clear about separating out my assumptions from my logic. It's fairly clear to me that where the likes of mjg59 and yourself and I disagree is on the assumptions about rates of exploitable defects, and on the relative value of flexibility and end-user freedom. I think I understand your positions, I just disagree. It's just that a shame that, apparently, I'm not able to communicate my side clearly enough to make you feel the same way (i.e. understand but disagree). ;)

1. Exactly how far that'd have to be is debatable, and we've no way to measure this AFAIK, so let's not go there. ;) We do know that I think it will never be usefully below 1, while you, mjg59, etc., think it will be.

to post comments

Practical security for 2014

Posted Jan 17, 2014 16:45 UTC (Fri) by raven667 (subscriber, #5198) [Link] (2 responses)

> taking useful functionality away,m and adding complexity with further bugs. I don't think that trade-off is worth much to me.

I disagree on this point, I don't see how functionality is being taken away when you have control of the keys and whether the feature is enabled at all.

I also don't see how adding some basic signature or hash value checks, something that we do in plenty of other security sensitive software like OpenSSL or OpenSSH or GPG or NSS, is adding a significant amount of complexity to actually be a negative.

> I am though more optimistic about the scope for improving security through better engineering of the software, perhaps with some hardware assistance. I think there's room there to make a significant impact on security over the next decade or two.

You are _way_ more optimistic on that front than I think any of us are, which is why are are more interested in simple integrity checking technologies that deal with running in an imperfect universe than pinning our hopes on complex software being any more secure in the future. You keep accusing us of optimism and presuming the kernel is unexploitable but it would seem that this is in fact _your_ assumption and not ours.

You can probably make a small body of software tough, but not impossible, to exploit, the integrity checking in uEFI and the bootloader is not a ton of code. Getting that small bit of code to be tough is far more practical than expecting software engineering to make the entire stack impossible to exploit.

Practical security for 2014

Posted Jan 17, 2014 17:09 UTC (Fri) by paulj (subscriber, #341) [Link] (1 responses)

Features being removed: Kexec. Also, I'm somewhat worried about hypervisor functionality beyond the mid-term, based on the precedent of kexec.

Re optimism. I'm not assuming an unexploitable kernel at all. Indeed, I've been clear that I'm very much of the opinion that the current scheme of things is close to unsalvageable. :) I do think it is possible to build much more secure systems, even if they still run on a kernel with many defects, but I thought I made it clear I think it will take *decades* of research and re-engineering to get there. :) Oh, and I forgot, also a fairly significant shift in priorities in industry, that puts security a lot higher than it does now.

I'm optimistic on what is *possible* for the long-term. However, utterly pessimistic about what we have now, and I continue to think it's mostly pointless to know you started from the right state, when the problems lie in the states there-after (and history predicts that won't change, for the current systems and how they're engineered).

Practical security for 2014

Posted Jan 17, 2014 17:11 UTC (Fri) by mjg59 (subscriber, #23239) [Link]

Features removed: kexec until a secure implementation is added, which is a work in progress. Since kexec allows you to trivially circumvent Secure Boot, there's no point in using Secure Boot if you want kexec. So just disable Secure Boot and kexec miraculously reappears.