Practical security for 2014 [LWN.net]

Practical security for 2014

Posted Jan 17, 2014 16:45 UTC (Fri) by raven667 (subscriber, #5198)
In reply to: Practical security for 2014 by paulj
Parent article: Practical security for 2014

> 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.

to post comments

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.