Practical security for 2014 [LWN.net]

Practical security for 2014

Posted Jan 14, 2014 16:46 UTC (Tue) by paulj (subscriber, #341)
In reply to: Practical security for 2014 by mjg59
Parent article: Practical security for 2014

Wow, this SecureBooting gets more and more complicated! How do I SecureBoot the DHCP server btw?

to post comments

Practical security for 2014

Posted Jan 14, 2014 16:49 UTC (Tue) by mjg59 (subscriber, #23239) [Link] (3 responses)

Your counterargument now involves an attacker being able to compromise your DHCP server in addition to your system, and you *don't* think there's any additional security there?

Practical security for 2014

Posted Jan 14, 2014 17:04 UTC (Tue) by paulj (subscriber, #341) [Link] (2 responses)

There is additional security, if you assume the security of the DHCP server is independent of the security of the subverted DHCP client. This is not always the case, particularly when they're both the same OS - in that case, the subversion of the client may mean the DHCP server is prone to the exact same subversion!

The boot from known-good, known-fixed media has far less complexity and is far more reliable.

Practical security for 2014

Posted Jan 14, 2014 17:12 UTC (Tue) by mjg59 (subscriber, #23239) [Link] (1 responses)

"if you assume the security of the DHCP server is independent of the security of the subverted DHCP client"

Which ought to be a pretty safe assumption - the only network-facing code they should have in common is the kernel, and if your DHCP server has remotely-exploitable kernel vulnerabilities then you're already having a bad time.

"The boot from known-good, known-fixed media has far less complexity and is far more reliable."

And involves physical intervention every time you want to perform a security update. Good luck selling that idea.

Practical security for 2014

Posted Jan 14, 2014 17:44 UTC (Tue) by paulj (subscriber, #341) [Link]

And involves physical intervention every time you want to perform a security update. Good luck selling that idea.

Not every time. Only for updates that are known to require it. And your answers on the benefits of SecureBoot all have assumed that the impact of the exploit is known. We're talking about a small subset of all updates.

I've worked in or with a number of different corporate setups over the years, from small, to medium, to global, with various mixes of proficiencies. Even with the one corporate that was extremely technically proficient and who defaulted to remote boot & management of computers, they still required on site tech for interventions, and they still couldn't always get remote boot & management to provide required flexibility or always work correctly. It turns out to require ongoing expertise - especially if you want Internet booting. This isn't cheap.

For quite a few small to medium corporates I've seen, having local hands to intervene is *cheaper* than hiring in people sufficiently expert to make remote boot work well. Those local hands will already be there! Indeed, in an era of cut-backs, it may be the lesser-skilled "hands on" IT people who are less likely to be chopped than the network/server experts. The former will *always* be required, while the functions of the latter can increasingly be outsourced (Google Apps, etc).

Setting up & maintaining complex remote boot and update systems that may require knowing how to generate & sign SSL certs, versus inserting a USB stick in each computer, on the rare occasion. The former is not automatically cheaper in terms of labour than the latter, from what I have observed in business. The opposite in fact, by far the opposite.