| |||||||||||||
Garrett: Secure Boot and Restricted BootGarrett: Secure Boot and Restricted BootPosted Mar 28, 2013 14:24 UTC (Thu) by raven667 (subscriber, #5198)In reply to: Garrett: Secure Boot and Restricted Boot by paulj Parent article: Garrett: Secure Boot and Restricted Boot
Who can guarantee anything, I could get hit by a bus tomorrow, in any event shouldn't we take action only on Restricted Boot technologies rather than pre-emmptively attack freedom-preserving Secure Boot out of fear or loathing of the company most responsible for it. It doesn't put us in any different or worse position to use Secure Boot technology that preserves freedom now and fight against Restricted Boot technology anywhere you find it, which seemed to be the point of mjg59's post.
Worst case is that the market for general purpose consumer computing segments into vendor silos (Apple, MS, Google) which might happen regardless of what we do but there will always be freedom-preserving hardware available in markets where Linux is dominant because there are enough customers who demand it to make it worthwhile. I don't expect that to happen right now though because its not in the best interest of hardware vendors to fight for the software OS vendors against their own customers, there'd have to be a lot of money on the line to make them mercenaries in that fight which otherwise doesn't involve them. It could happen though, look at the tiny entertainment industry bossing around the tech industry.
(Log in to post comments)
Garrett: Secure Boot and Restricted Boot Posted Mar 28, 2013 14:43 UTC (Thu) by paulj (subscriber, #341) [Link]
Show me a market that is dominated by freedom-loving Linux users?
I'm not against Secure Boot per se. However Secure Boot doesn't really provide much in the way of security. It secures the boot, so you end up booting only the binaries you (or someone else) wanted, but it doesn't mean you are secure. For Secure Boot to meaningful, you need to have something Secure to boot into, but we are a long away from that in the field of software generally (and Linux, as is, will never be secure - will always be riddled with security sensitive bugs). The proponents of Secure Boot hand-wave this away, saying runtime security is out-of-scope. The raison d'etre of Secure Boot is security, but the non-deliverance of security by Secure Boot should not be held against it.
I'm not against Secure Boot of itself, the problem is that the API standardisation, code deployment, and infrastructure that is required for Secure Boot is exactly the same as that as for Restricted Boot.
As mjg59 frequently will point out, Secure Boot is required to be Secure Boot (on PCs) because the board vendors are (for now) required to keep the "allow the key DB to be modified" 'bit' enabled. However, clearly this means there is very *LITTLE* difference between Secure Boot and Restricted Boot.
The hard work has now been done. The large Linux vendors have acquiesced to signing their distros with 3rd party keys - not those of users either! There is literally nothing now, technologically, to stop the 'bit' from being flipped in the future. It will no longer affect Linux vendors.
I also, along with the rest of us, hope it will not be. However, I can't say I feel good that we're now in that position. I guess I'll just have to be glad that my utterly insecure Linux kernel has been Secure Booted.
Garrett: Secure Boot and Restricted Boot Posted Mar 28, 2013 16:38 UTC (Thu) by raven667 (subscriber, #5198) [Link]
> Linux, as is, will never be secure - will always be riddled with security sensitive bugs). The proponents of Secure Boot hand-wave this away, saying runtime security is out-of-scope. The raison d'etre of Secure Boot is security, but the non-deliverance of security by Secure Boot should not be held against it.
I think the main misunderstanding here is that security is a continuum of risk and mitigation expense, not an absolute binary, on-off, square-wave. It's not hand-waving dismissal, it's acknowledgement of a fundamental truth.
> As mjg59 frequently will point out, Secure Boot is required to be Secure Boot (on PCs) because the board vendors are (for now) required to keep the "allow the key DB to be modified" 'bit' enabled. However, clearly this means there is very *LITTLE* difference between Secure Boot and Restricted Boot.
That is a fundamental difference though, even if a technically small one.
> The large Linux vendors have acquiesced to signing their distros with 3rd party keys
To be fair the only thing which is signed by a third party is the shim, everything after that including the full bootloader, the kernel, modules, etc. are signed by authorities which don't depend on Secure Boot, Secure Boot only affects the first thing the EFI loads, what policy you enforce after that, if any, is up to you.
The linux vendors have no interest in supporting locked down hardware as far as I can tell.
Garrett: Secure Boot and Restricted Boot Posted Apr 4, 2013 8:50 UTC (Thu) by paulj (subscriber, #341) [Link]
Yes, security is a continuum, and there is no such thing as perfect security. There are many security people (or people working on security technologies) who often forget that, typically because they overly focused on some specific threat and ignore the bigger picture (or, it is not their job to consider the bigger picture), or alternatively because they will not bear the costs of what they are proposing/implementing.
There are many security steps you might take which, while not offering perfect security, are still worthwhile. E.g. it is worth locking my door, even though this would not stop someone who is prepared to bash the door in. However, fitting a lock to my front door would *not* be the best prioritisation of my resources if the windows and other external entrances still hadn't had window frames & glass, & doors fitted.
I.e. security measures have to be seen in context. Any given security measure can not be said to be worthwhile of itself. It must be assessed in context with the threat - realistic threats - AND in context with the rest of the system the security measure will be put in place with.
General purpose OSes, and the software they run today are ridiculously insecure. Secure Boot can NOT secure a Linux system from at-boot infection from the class of attackers who can write rootkits or firmware exploits. Because it is equally possible to write an exploit for early, privileged userspace, and use a general runtime exploit to install it. "Secure Boot" buys you *nothing* in this context. Similarly, I don't believe "Secure Boot" will do anything to make Windows 8 more resistant to viruses and malware.
However, "Secure Boot" CAN prevent the average *OWNER* of the machine from using the machine - once the "restricted boot" bit is set by some other party (e.g. the hardware vendor). In this context, the "Secure Boot" technology does indeed generally work. It makes "Restricted Boot" work.
"Secure Boot" will not help security on general purpose Linux machines, from capable attackers. The main class of people who could possibly be stymied by "Secure Boot" are the users. All the other instances of this technology, from Tivo to game-consoles, to phones, are being used to prevent *OWNERS* from having full access to their hardware.
To think "Secure Boot" is about helping owners secure their own machines against others seems very very naïve to me.
Garrett: Secure Boot and Restricted Boot Posted Apr 7, 2013 9:41 UTC (Sun) by kleptog (subscriber, #1183) [Link]
I think you're being very pessimistic. Yes, it's possible to malware to simply stick something in the early boot sequence and it will get run. That's because nobody has ever bothered to build any verification in because there's no point unless you know the kernel you're running is trusted and until recently that was essentially impossible. A classic chicken and egg problem.
With secure boot you finally have a method to trust the kernel and early userspace which means it becomes feasible to start enforcing useful policy, such as "users may only run programs that come from signed packages".
Besides, you don't need to secure an entire Windows system, you only need to secure it far enough to be able to start your virus scanner without loading any malware first so the malware can't hide itself from the scanner.
Garrett: Secure Boot and Restricted Boot Posted Apr 7, 2013 12:13 UTC (Sun) by hummassa (subscriber, #307) [Link]
My sistematic opposition to "secure" boot is based on the following argument:
1. yes, it *is* a (small) beachhead; BUT
Garrett: Secure Boot and Restricted Boot Posted Apr 7, 2013 16:10 UTC (Sun) by raven667 (subscriber, #5198) [Link]
> strategic and hijack-able beachhead
How is that supposed to work?
Garrett: Secure Boot and Restricted Boot Posted Apr 7, 2013 17:34 UTC (Sun) by hummassa (subscriber, #307) [Link]
By flipping the theoretical bit that separates "secure" boot from "restricted" boot. Then the only bootable things will be those that are approved by the third party (the original hw's OS vendor, in casu, Microsoft).
Garrett: Secure Boot and Restricted Boot Posted Apr 7, 2013 12:29 UTC (Sun) by paulj (subscriber, #341) [Link]
So go "fix" the system so that all privileged code, kernel or userspace, that is guaranteed to run (i.e. cause it is involved in starting the system) is secure. And *then* implement Secure Boot.
Because, until you have something secure to actually boot, all that Secure Boot infrastructure will do is give vendors/media companies a very tempting switch to flip over to "Restricted Boot". This technology tends to only be "Secure" against normal computer users - i.e. the end-user, the owner of the device.
Do that, and *then* come back about Secure Boot. Until then, you're only handing the vendor/media companies a tool that is effective mostly for DRM. And some of the vendors are ALSO media companies.
I'm not being pessimistic. Making software secure is hard. Very very hard. Vendors have tried to get "Restricted Boot" on other platforms, and mostly they fail, despite having much more control over the code that will be run, and (often) that code being much reduced and having less scope for attack than on a Linux or Windows system.
Garrett: Secure Boot and Restricted Boot Posted Apr 7, 2013 13:16 UTC (Sun) by kleptog (subscriber, #1183) [Link]
Things are being fixed. When going for an end goal it's usually a good idea to tackle all the remaining problems in parallel, rather than doing them serially. You correctly point out that solving each problem (boot, kernel, userspace) individually is useless, so they are being tackled all at the same time.
I don't understand your argument about DRM, since a system cannot determine whether it was booted securely or not. That makes it kinda pointless for DRM. All secure boot can do is refuse to boot if it finds something wrong.
You're right that securing software is hard, but the only goal here is to secure the boot process, not the entire system. This makes the problem much more tractable. Even if all we achieve is the extinction of boot malware then I think it all worthwhile.
Anyway, it seems to me that doing nothing is the worst option, since hardware with this enabled is shipping right now and doing nothing means Linux won't boot on those machines without extra steps.
Garrett: Secure Boot and Restricted Boot Posted Apr 7, 2013 13:31 UTC (Sun) by hummassa (subscriber, #307) [Link]
> I don't understand your argument about DRM, since a system cannot determine whether it was booted securely or not. That makes it kinda pointless for DRM. All secure boot can do is refuse to boot if it finds something wrong.
Your argument is inconsistent. At the point where you restrict the boot, the system can determine that it was booted securely by the simple fact that it is running.
Garrett: Secure Boot and Restricted Boot Posted Apr 7, 2013 15:42 UTC (Sun) by raven667 (subscriber, #5198) [Link]
No, I don't think it works that way because the verification is done in the previous layer of code and there is no reliable signalling to the next layer signifying whether it did any checks at all.
Anything that can be booted in Secure Boot mode can also be booted without Secure Boot enabled and it won't know the difference. Your Secure Boot capable bootloader/kernel can't refuse to start on a non-Secure Boot enabled system, or one that is faking Secure Boot checking. For example a VM.
Garrett: Secure Boot and Restricted Boot Posted Apr 7, 2013 13:42 UTC (Sun) by paulj (subscriber, #341) [Link]
Yes, it may be better to do things in parallel, to achieve a task. However, you miss the point entirely.
The task - "Secure Boot" - is likely not achievable. At least it is not achievable against the class of attacker against whom Secure Boot is aimed at, those sophisticated enough to be able to subvert the system at runtime, so as to be able to subvert which software is booted. If they can do this, they can subvert the system at runtime *again* and *again*.
If the task is not achievable, then implementing the "Secure Boot" technology doesn't help get you there. However, it does get you toward "Restricted Boot", which *does* work - most computer users are not sophisticated enough to get around it on their own without help. Even if that help exists in the form of a ready to run unlock, it often has bricking-risks that not all users want to take.
As for DRM, DRM does NOT require a "determine whether it was booted securely flag". I've heard someone claim this was a requirement before, and it's simply a non-sense. It is *only* required IFF the system is designed to be allowed to booted unrestricted. IF the system ONLY allows "Restricted Boot", then there is NO NEED for a flag - the platform is *assumed* secure.
E.g., assume Windows "8+X" (X>=1) will specify boot MUST be restricted. Then any programme designed so it can only run on "8+X" has NO NEED for a flag in order to be able to assume it has been booted on a "Restricted Boot" platform.
Garrett: Secure Boot and Restricted Boot Posted Apr 7, 2013 15:52 UTC (Sun) by raven667 (subscriber, #5198) [Link]
Even in your Win9+ case the running system still doesn't know whether integrity checking existed when it booted, it could be booted on a system without integrity checking and wouldn't know the difference. A system can't refuse to boot if Secure Boot isn't enabled as far as I know, so can be booted on non-Secure Boot enabled hardware (or VM) and have any "DRM" restrictions trivially bypassed. It wouldn't be useful for protecting anything valuable.
Wouldn't it be better to agitate against boot locking where it exists (in the ARM world) rather than where it explicitly isn't?
Garrett: Secure Boot and Restricted Boot Posted Apr 7, 2013 16:51 UTC (Sun) by paulj (subscriber, #341) [Link]
It doesn't matter, if you simply can't buy a platform that doesn't have integrity checking. Further, the lack of a flag in Secure Boot does not preclude that flag being added. If/when it is added, it will not affect software that doesn't know about it.
The hard part to getting Restricted Boot deployed was always going to be the non-MS OSes and allowing them to still boot. The major non-MS PC OS has happily gone along with implementing the required interface. The lack of a flag today, or addition of any future one, will now not prevent those OSes booting in Restricted Boot mode, should the bit ever get flipped.
If that happens, the Linux vendors will no longer have any meaningful dog in the fight, with which to raise a stink about.
Garrett: Secure Boot and Restricted Boot Posted Apr 7, 2013 17:15 UTC (Sun) by mjg59 (subscriber, #23239) [Link]
"the lack of a flag in Secure Boot does not preclude that flag being added"
Correct - it's the fact that it's impossible to add such a flag that precludes that flag being added.
Garrett: Secure Boot and Restricted Boot Posted Apr 7, 2013 18:10 UTC (Sun) by paulj (subscriber, #341) [Link]
Why would it be impossible?
I think it'd be impossible for it to be impossible tbh.
Garrett: Secure Boot and Restricted Boot Posted Apr 7, 2013 18:15 UTC (Sun) by mjg59 (subscriber, #23239) [Link]
If you can trust the firmware, there's no point in the firmware setting a flag to indicate that it's trusted. If you can't trust the firmware, you can't trust the state of any flag it's providing.
Garrett: Secure Boot and Restricted Boot Posted Apr 7, 2013 18:46 UTC (Sun) by hummassa (subscriber, #307) [Link]
Garrett, you keep ignoring the point here; and that is: "secure" boot does not help securing the boot process, but it DOES help the bad guys to push restricted boot down the line.
Garrett: Secure Boot and Restricted Boot Posted Apr 7, 2013 18:56 UTC (Sun) by mjg59 (subscriber, #23239) [Link]
>"secure" boot does not help securing the boot process
By that argument selinux doesn't improve security because there exist kernel exploits that allow you to disable it. Having a separate root account doesn't improve security because there exist userspace exploits that allow elevation of privileges. Passwords don't improve security because there are flaws in web browsers that allow attackers to run keyloggers.
Security isn't binary. Secure Boot on its own doesn't make the boot process entirely secure, but it does make it more secure. It's also a prerequisite for any real security implementation.
Garrett: Secure Boot and Restricted Boot Posted Apr 7, 2013 20:35 UTC (Sun) by paulj (subscriber, #341) [Link]
raven667 also gave the "security isn't binary" argument before, my response to that is at: http://lwn.net/Articles/545877/
The problem with your example is that you have the pre-requisites the wrong way around. A more secure/controlled user-space, which technologies like SELinux try to give, is the *pre-requisite for Secure Boot*. Further, Secure Boot *also* requires a secure kernel, at least one a lot more secure than we have today. We are a *long* way from having this.
Now, once you have secured kernel and user-space to the point you can have some confidence that all software that is guaranteed to run (e.g. start-up) is unlikely to be subverted by the class of attacker you're worried about, then here's the funny thing: You don't need Secure Boot anymore!
The amazing thing about Secure Boot is that for it to worth anything to the owner, it requires the very thing that would render it moot.
However, Secure Boot is still worth something to others - it gets "Restricted Boot \ 1 flag" implemented, deployed and supported by Windows and all the major PC OSes. When that is done, then if someone flips that bit, there will be no Linux vendor left who can say "that breaks our boot".
Garrett: Secure Boot and Restricted Boot Posted Apr 7, 2013 20:45 UTC (Sun) by mjg59 (subscriber, #23239) [Link]
And selinux would be unnecessary if userspace were already secure, so it's also pointless?
Garrett: Secure Boot and Restricted Boot Posted Apr 7, 2013 22:33 UTC (Sun) by hummassa (subscriber, #307) [Link]
The problem here is that our argument is: deep "secure" boot support collaborates with future restriction of boot. SElinux, OTOH, does no such thing.
You can see another difference in nomenclature: one pretends to be "secure", the other explicitly states that it is "security-enhanced". Who is blatantly lying to the consumer? :-D
Garrett: Secure Boot and Restricted Boot Posted Apr 7, 2013 22:40 UTC (Sun) by mjg59 (subscriber, #23239) [Link]
So it adds security, you just worry that it can be used for evil? That's not what you said earlier.
Garrett: Secure Boot and Restricted Boot Posted Apr 8, 2013 5:08 UTC (Mon) by paulj (subscriber, #341) [Link]
SELinux allows the admin to control how running software interacts, including software not critical to startup, and software that interacts with the outside world, and software that dumb/malicious users might run (inc. software they load into the box). It can restrict what compromised software can do. It brings tangible benefits to securing user-space, particularly for network facing software, despite its complexity.
Security in context: What does Secure Boot add against the type of attackers sophisticated enough to subvert the kernel and modify boot? Why _aren't_ these attackers also capable of just subverting the boot, again and again?
There's a whole class of software, and methods of attacking it, that have traditionally been viewed as "not security-sensitive", which suddenly become *front-line* once you have Secure Boot, from /etc config files, to state in /var, to kernel modules, to on-disk fs data structures (h/t Al). If those fail, then there'll still be a wealth of data read by non-privileged programmes from which to get started up and then run a kernel exploit.
The Google Chrome security bounties have demonstrated that we over-estimate the benefits of just adding additional hoops, and that the X-hats are incredibly capable at stringing together exploits of long chains of bugs into attacks.
Garrett: Secure Boot and Restricted Boot Posted Apr 7, 2013 21:51 UTC (Sun) by kleptog (subscriber, #1183) [Link]
Secure Boot doesn't require a secure kernel. Let's assume the kernel is insecure, a reasonably valid assumption as you point out.
Case 1: Malware uses a vulnerability in the kernel to join a botnet and hide itself from userspace. This is out of scope for secure boot so not relevant.
Case 2: Malware uses a vulnerability in the kernel to modify the boot sector so it gets run the next time the computer starts up. The next boot the firmware checks the boot sector and complains to the user that there's an unverified boot sector and that the user should use a boot CD to clean it. Secure Boot achieves it's goal because it's impossible for the malware to install a boot sector that passes the test.
Now you can say that the malware will just install itself into /etc/rc.d/ instead and you'd be right. That's just because no-one has written the code to do any verification on that directory, not because it's not possible. Those tests would be effective at preventing the malware running on boot *even if the kernel was insecure*.
The only thing Microsoft (really Verisign) requires before signing a bootloader is that it can't be used by malware to subvert the windows boot process so it can pass the boot sector test. But this is a social problem which can't be solved by technical means. That's why a bootloader which says "Hi! You're booting MyBootLoader. If this is not what you're expecting contact technical support. Press any key to continue." would probably get signed since it won't allow malware to hide itself.
Garrett: Secure Boot and Restricted Boot Posted Apr 7, 2013 22:44 UTC (Sun) by viro (subscriber, #7872) [Link]
Bullshit. Suppose the kernel hole in question is in e.g. parsing on-disk metadata. You are going to mount root fs, right? And all the "let's make sure /etc/rc.d/ isn't modified" crap in the world is not going to do anything about that, since no visible files need to be modified.
And before you go into "oh, but that reduces attack surface" - not really. Consider a combination of (1) hole in some piece of shit desktop software that goes through luser's homedir and cross-references his pr0n stash^W^Wphoto collection with (2) kernel exploit of any kind used by the code hidden in said collection and executed by (1). Sure, it'll wait until the luser logs in. BFD.
Once a box had been had, it's been had, period.
Garrett: Secure Boot and Restricted Boot Posted Apr 8, 2013 2:10 UTC (Mon) by raven667 (subscriber, #5198) [Link]
That sounds like a nasty scenario but I don't think any general security technology can fix that but even in this case you could safely download an updated kernel and the most your fully owned system could do is block the update, it couldn't modify it.
Garrett: Secure Boot and Restricted Boot Posted Apr 8, 2013 18:09 UTC (Mon) by kleptog (subscriber, #1183) [Link] Sure, it'll wait until the luser logs in. BFD.Actually, I find this a BFD. It means the virus scanner started at boot has a chance to download new signatures and scan for the malware before it has a chance to run. That's a significant improvement over the current situation.
Garrett: Secure Boot and Restricted Boot Posted Apr 8, 2013 20:26 UTC (Mon) by viro (subscriber, #7872) [Link]
In which respect? That Scamantec and their ilk get money from more suckers? I had a front-seat view of some of their games and I'd trust a politician sooner than those shits. If you rely on their products, you deserve everything you get - stupidity must be punished, after all...
Garrett: Secure Boot and Restricted Boot Posted Apr 8, 2013 22:37 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
So when is Linux going to be completely exploit-free with rigidly defined security sandboxes isolating applications' data?
What? You say "never"?
Garrett: Secure Boot and Restricted Boot Posted Apr 7, 2013 20:36 UTC (Sun) by paulj (subscriber, #341) [Link]
Then this flag argument is generally specious, and there is no Restricted Boot that needs it.
Garrett: Secure Boot and Restricted Boot Posted Apr 7, 2013 20:50 UTC (Sun) by mjg59 (subscriber, #23239) [Link]
Right. So Secure Boot is completely worthless as a DRM-enforcement mechanism. Restricted Boot is not.
Garrett: Secure Boot and Restricted Boot Posted Apr 8, 2013 5:16 UTC (Mon) by paulj (subscriber, #341) [Link]
Restricted Boot doesn't need a flag either. There are systems which big media companies assume to be secure and have working DRM, simply by dint of platform information. No other flags needed. It might not be true, but it seems to be good enough for the likes of the BBC.
Garrett: Secure Boot and Restricted Boot Posted Apr 8, 2013 6:32 UTC (Mon) by mjg59 (subscriber, #23239) [Link]
I have no idea what you're trying to say here, so I'm just going to reiterate that there's no way to use Secure Boot as a DRM mechanism and if you disagree then you can describe exactly how it's supposed to work.
Garrett: Secure Boot and Restricted Boot Posted Apr 8, 2013 6:41 UTC (Mon) by paulj (subscriber, #341) [Link]
You recognise Restricted Boot is useful for building a DRM system (2 comments above this). You say a flag is pointless for Secure Boot, it is then equally pointless for Restricted Boot, by the very same argument. I don't even know why this flag issue was brought up (I didn't).
The fact still remains that "Secure Boot" differs from "Restricted Boot" by 1 bit of information, which is at the whim of a number of hardware vendors.
Garrett: Secure Boot and Restricted Boot Posted Apr 8, 2013 6:55 UTC (Mon) by mjg59 (subscriber, #23239) [Link]
So… you're agreeing that Secure Boot isn't useful as a DRM mechanism? Like I said, I have no idea what you're trying to say here.
Garrett: Secure Boot and Restricted Boot Posted Apr 8, 2013 7:23 UTC (Mon) by paulj (subscriber, #341) [Link]
You have said Restricted Boot is useful for a DRM system. You don't seem to quibble that Secure Boot and Restricted Boot differ by anything more significant than a bit of information controlled by the maker. I'm sure you're more than intelligent to understand what the implication is, should you be motivated to understand.
Garrett: Secure Boot and Restricted Boot Posted Apr 8, 2013 14:34 UTC (Mon) by mjg59 (subscriber, #23239) [Link]
No, I think you're going to have to be explicit about what you're saying.
Garrett: Secure Boot and Restricted Boot Posted Apr 8, 2013 18:21 UTC (Mon) by kleptog (subscriber, #1183) [Link]
Actually, I'd like clarification how Restricted Boot helps a DRM system. AFAICS it will merely lull media companies into a false sense of security because they might think it actually secures the system while it only secures the boot process.
Take any software that implements DRM, run it in a VM and you can bypass anything. You will need to arrange to run the exploit every boot though.
I find most interesting the contrast:
Securing a PC against malware - good
While these two situations are technically indistinguishable.
Garrett: Secure Boot and Restricted Boot Posted Apr 8, 2013 18:50 UTC (Mon) by raven667 (subscriber, #5198) [Link]
> However, fitting a lock to my front door would *not* be the best prioritisation of my resources if the windows and other external entrances still hadn't had window frames & glass, & doors fitted
I have two points here, 1) The development labor happens in parallel and independently so there is no prioritization implied, work on Secure Boot doesn't take away work from other security technologies, multiple things can be worked on at once. 2) There is already quite a depth of available security technologies from permissions to SELinux to various sandboxing and namespace technologies to whole VMs so it is not fair to say that other avenues of attack aren't covered in some way. Secure Boot is a fall back position to help recover a system when those other technologies have failed but those other technologies are on the front line of defense and are being worked on all the time.
> Because it is equally possible to write an exploit for early, privileged userspace, and use a general runtime exploit to install it. "Secure Boot" buys you *nothing* in this context.
This really depends on how far you can extend your prevention of unauthorized remote modification. At some point you have to allow arbitrary code to run but the farther you can push that out the more base OS tools you can fall back on to reliably clean out the later layers, including anti-malware software.
> However, "Secure Boot" CAN prevent the average *OWNER* of the machine from using the machine - once the "restricted boot" bit is set by some other party (e.g. the hardware vendor). In this context, the "Secure Boot" technology does indeed generally work. It makes "Restricted Boot" work.
Secure Boot _can't_ be used to prevent the owner of the machine from doing what they like because that's not how the policy works, so that's not how the technology works. Fighting against a policy change to enable boot locking, which is what the article is about and where you share common ground, doesn't require one to be against boot time signature verification in any form just because it uses the same technology.
You can join on the common ground of being generally against boot locking if you are willing to accept that some people do actually like the idea of user-controlled boot time signature verification.
I see this whole debate, of being generally anti-SecureBoot, as being the same arguments as being anti-encryption. The anti-encryption stance is that "bad guys" might use unbreakable encryption to "bad things" so therefore no one should be allowed to have encryption without allowing that the "good guys" use of encryption outweighs the potential for bad use.
Garrett: Secure Boot and Restricted Boot Posted Apr 8, 2013 20:19 UTC (Mon) by paulj (subscriber, #341) [Link]
On the labour point: this only makes sense if:
a) The overall goal is achievable
OR
b) The sub-task delivers some benefit of its own, regardless of whether or not the overall goal is achievable.
It is highly doubtful that the overall goal is achievable, at least not with the way the software that compromises a Linux system is developed today. Indeed, it's highly uncertain the overall goal is achievable at all.
So then the question is about b, what does "Secure Boot" achieve, if it is booting software that is swiss cheese to any half-decent exploit writer (but not to ordinary users, necessarily)? If nothing, then it is (at best) labour wasted. At worst, it is deploying a system that will only secure systems against normal users, but not capable crackers (or those with access to the tools of such).
What exactly will "Secure Boot" achieve, in the context of a full system? What threats will it guard against?
Garrett: Secure Boot and Restricted Boot Posted Apr 8, 2013 21:15 UTC (Mon) by raven667 (subscriber, #5198) [Link]
> What exactly will "Secure Boot" achieve, in the context of a full system? What threats will it guard against?
It gives you the benefits of booting off read-only media but with the ability to update software without changing physical media. It provides a small limit on the ways an attacker can hide their activity by modifying your system and gives you some control over the software that you run, how much control you have is up to how much control you implement.
>At worst, it is deploying a system that will only secure systems against normal users, but not capable crackers (or those with access to the tools of such).
Agreed there is no point in wasting a lot of time on fancy control schemes when malware writers have clearly demonstrated the ability to just bury their malware in deeper layers of the systems if they have to. That's one reason why there hasn't been a lot of work on anti-malware tools on Linux although there has been a lot of work on sandboxing and containment technologies.
|
|||||||||||||