User: Password:
|
|
Subscribe / Log in / New account

Fedora reexamines "trusted boot"

Fedora reexamines "trusted boot"

Posted Jul 3, 2011 10:45 UTC (Sun) by brendan_wright (guest, #7376)
In reply to: Fedora reexamines "trusted boot" by gmaxwell
Parent article: Fedora reexamines "trusted boot"

> Though you seem to be suggesting that it's a useful system security feature. It is not. If your system is compromiseable without trusted boot it will be just as vulnerable with it.

It may not prevent compromise but the idea is it can reveal it through remote attestation - see: http://lwn.net/Articles/137306/

A successful compromise might still be a denial-of-service attack, but by immediately taking the compromised system offline you can have confidence that your computers aren't really "owned" by a bunch of hackers.

> Iff linux and much of the userspace were redesigned you _might_ be able to use it to detect rootkits, but even then its unlikely to help... Attackers already aren't rebooting your systems into new kernels for rootkit purposes: They usually use intentionally exposed features (or bugs) to add code to the kernel without rebooting. ... so TPM would attest to you that it booted your trusted kernel but it wouldn't matter.

The idea is that the signing process continues after boot and no code is run without first being checked. If you can extend that to all code in the system (which I agree is a lot of work) then you can detect code changes after boot. Presumably NX bits help here too.


(Log in to post comments)

Fedora reexamines "trusted boot"

Posted Jul 3, 2011 12:13 UTC (Sun) by alonz (subscriber, #815) [Link]

I'm afraid I have to disagree with you, at least partially…

For example, you write
> It may not prevent compromise but the idea is it can reveal it through remote attestation
Here you are assuming that the main purpose of the system is access to some (single!) remote service, which can perform the attestation often enough to matter. But this isn't the case for most modern uses, especially when even “connected” devices often use cellular (= intermittent) connections.

Likewise,
> The idea is that the signing process continues after boot and no code is run without first being checked
This assumes a completely closed software ecosystem—which, again, is far from the normal case in almost all modern use-cases.

The concepts of “trusted boot” looked OK on paper, in the context of early security research (which dealt with monolithic managed systems, when software distributions were small and organizations were large). But they don't fit most modern use cases.

Fedora reexamines "trusted boot"

Posted Jul 4, 2011 2:31 UTC (Mon) by brendan_wright (guest, #7376) [Link]

> Here you are assuming that the main purpose of the system is access to some (single!) remote service, which can perform the attestation often enough to matter. But this isn't the case for most modern uses, especially when even “connected” devices often use cellular (= intermittent) connections.

If a firewall is setup to check the security of severs or desktops siting behind it, it can take them offline as soon as they fail a trust check. A mobile device like an Android integrates with online systems such as the update system that could in theory perform such checks for you (alerting your by email perhaps). A lot is possible if the software can be sorted properly...

> > The idea is that the signing process continues after boot and no code is run without first being checked

> This assumes a completely closed software ecosystem—which, again, is far from the normal case in almost all modern use-cases.

Really? Don't many distros and Anrdoid already only download correctly signed code updates by default? Linux is already much more "closed" or at least "centralized" in one sense than Windows in that most software is installed via apt-get or whatever.

It's not hard to imagine extending this framework to include the TPM, so that your system can attest it is running the code as provided by the update servers, not some code compromised in transit or after it was installed on your machine.

Fedora reexamines "trusted boot"

Posted Jul 4, 2011 8:57 UTC (Mon) by etienne (guest, #25256) [Link]

> The idea is that the signing process continues after boot and no code is run without first being checked.

How do you check system-wide libraries? They can be loaded at different time and so different addresses on two successive boots (depending on timing issues or randomized loaded), and they are lasy loaded (http://en.wikipedia.org/wiki/Lazy_loading) so they are constantly being modified - if those memory pages are loaded in memory at all.

Fedora reexamines "trusted boot"

Posted Jul 4, 2011 23:12 UTC (Mon) by brendan_wright (guest, #7376) [Link]

> How do you check system-wide libraries?

You check the library loading code, and then the library code that is about to be loaded & relocated - if they haven't changed then the output can't have changed (except for addresses), so if they are "secure" then so should the output be.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds