Installing Linux on Windows 8 PCs: No easy answers
|
|
|
Comments (13)
Use open hardware with open source software
http://news.idg.no/cw/art.cfm?id=4DCE37F8-BFD8-ADDA-EFE06EB7...
Adam Williamson says in a comment to this article that Microsoft's requirements (for PCs, not ARM) now state that it must be possible for the user to disable secure boot. Unless he's mistaken, that's a great relief!
It's a relief, but Cathy has a point. Disabling a security feature strikes people as a negative thing, ... Even if that security feature is unnecessary.
The only thing "secured" is Microsoft's shackles on consumers.
This needs a graphic, tout-suite.
This needs a graphic, tout-suite.
An image of a person shackled hand and foot, with their mouth forced open and Windows 8 Metro being forced down their throat. The shackles should be clearly labeled UEFI.
I have to admit I really liked the graphic they came up with
The photo of the Windows sticker being pared off of the case that way.
It definitely made me smile -- I guess I'm officially a fan-boy, now.
It definitely made me smile -- I guess I'm officially a fan-boy, now.
Microsoft Secure Boot Could Ban Windows From PCs
Robert McMillan wrote:When Windows 8 computers start shipping later this year, they will come with a brand-new firmware feature called Secure Boot. A year ago, Linux lovers were worrying that Secure Boot was going to somehow give Linux the boot, but now it looks like there’s a brand-new twist to the story. It could be used to keep Microsoft’s software from running on a computer.http://www.wired.com/wiredenterprise/2012/08/secure-boot/
I can see the malware attacks going after the secure boot keys now:
"Your computer has been infected and is now a useless paperweight, pay us $50 with your credit card to restore it to operation."
And people will do it. :(
"Your computer has been infected and is now a useless paperweight, pay us $50 with your credit card to restore it to operation."
And people will do it. :(
In the article linked above
And in the article published by Matthew Garrett
The paragraph/statement below describes the best solution for the problem created by MS created
It provides a complete range of options. Starting with complete removal of UEFI to complete security by preventing all other applications that are not selected by the user.
It might be a little burdensome, but might be worth it. The nice thing about this is, intrusions by any foreign application will be detected when it is checked at the gate when asking permission to execute.
The issue of attacks on the UEFI itself can be solved by making a good utility to backup and restore UEFi itself and a good version of its database from an external storage. Password ot other means can be used to secure this process.
And in the article published by Matthew Garrett
The paragraph/statement below describes the best solution for the problem created by MS created
Quoting: Linux users could use this technique to cryptographically sign every piece of software that runs on the machine’s firmware — giving them control over the boot-loader, Linux kernel, and even the applications running on the machine, says Mark Doran a senior engineer with Intel who has led the Unified EFI firmware standards effort that’s given birth to Secure Boot. “That would give you the ultimate in end-user owner machine control,” he says.
It provides a complete range of options. Starting with complete removal of UEFI to complete security by preventing all other applications that are not selected by the user.
It might be a little burdensome, but might be worth it. The nice thing about this is, intrusions by any foreign application will be detected when it is checked at the gate when asking permission to execute.
The issue of attacks on the UEFI itself can be solved by making a good utility to backup and restore UEFi itself and a good version of its database from an external storage. Password ot other means can be used to secure this process.
@ Fettoosh:
The only way you're going to prevent an infection vector from being exploited is to close that vector... That means for UEFI secure boot, make it only be able to receive upgrade of firmware by local user action (no remote flashing), and lock the machine in a secure location only accessible by the system admin...
The only way you're going to prevent an infection vector from being exploited is to close that vector... That means for UEFI secure boot, make it only be able to receive upgrade of firmware by local user action (no remote flashing), and lock the machine in a secure location only accessible by the system admin...
> ...make it only be able to receive upgrade of firmware by local user action (no remote flashing)...
With the number of remote exploits Windows experiences, even that won't be enough for a Windows server.
With the number of remote exploits Windows experiences, even that won't be enough for a Windows server.
@JaseP, @jdixon,
Granted, we all know there is no such thing as totally secure system, but what I described above would be pretty close. Total security is a moving and illusive target
For a Trojan/virus application to execute on a system, it has to be already authorized in the UEFI database. To accomplish that, a Trojan/virus needs to be sophisticated enough to connect remotely, or trick the user into running an application, or simply be attached to a document, then it has to execute to infect the UEFI and its database. At this point, it can't because it is not authorized.
Assume it was able to succeeded in bypassing this stage, it is going to need a password to authorize itself in the UEFI database to run a second time after a reboot. So it is obvious it is not a matter of simple infection and it is in any more. It is not totally secure, but it does make it pretty difficult to break in.
Granted, we all know there is no such thing as totally secure system, but what I described above would be pretty close. Total security is a moving and illusive target
For a Trojan/virus application to execute on a system, it has to be already authorized in the UEFI database. To accomplish that, a Trojan/virus needs to be sophisticated enough to connect remotely, or trick the user into running an application, or simply be attached to a document, then it has to execute to infect the UEFI and its database. At this point, it can't because it is not authorized.
Assume it was able to succeeded in bypassing this stage, it is going to need a password to authorize itself in the UEFI database to run a second time after a reboot. So it is obvious it is not a matter of simple infection and it is in any more. It is not totally secure, but it does make it pretty difficult to break in.
Post a comment
A free account is needed to post. Write your comment here first: your text is kept in this browser while you sign up or log in, and is waiting for you when you come back.
Your message:Markdown: **bold**, *italic*, [text](https://link), - lists, > quotes, $x^2$ for math. Formatting help
Sign up and post (it is free) or Log in and post
