Originally posted by duby229
View Post
Announcement
Collapse
No announcement yet.
The State Of Linux Distributions Handling SecureBoot
Collapse
X
-
-
It does nothing for Linux. NOTHING. While linux does have its security issues... It doesnt need to worry about MS's security issues.
Well I take that back... It does do something.... It prevents it from booting if MS doesnt like it. THATS what it does..... How is that -NOT- anti-competitive?
It does --NOT-- I repeat -----NOT----- check for boot viruses. It checks for a signature that MS provides. It is ---------NOT-------- a method of preventing boot viruses. It doesnt even check for them. It ---------IS-------- a method of preventing unwanted OS's from booting.Last edited by duby229; 28 December 2012, 05:53 PM.
Comment
-
Originally posted by duby229 View PostIt does nothing for Linux. NOTHING. While linux does have its security issues... It doesnt need to worry about MS's security issues.
Well I take that back... It does do something.... It prevents it from booting if MS doesnt like it. THATS what it does..... How is that -NOT- anti-competitive?
Comment
-
Originally posted by mjg59 View PostSo, again, suggest a solution that solves the problem that Microsoft are trying to solve without preventing the booting of unsigned code.
Because nobody's forced to do it?
If it really was a mechanism to protect against boot viruses.... Shouldnt it look for boot viruses?
Comment
-
Originally posted by duby229 View PostIf you boot Windows 8, You must use secureboot. How is that not forced?
If it really was a mechanism to protect against boot viruses.... Shouldnt it look for boot viruses?
Comment
-
Originally posted by mjg59 View PostWhat? Windows 8 boots fine without Secure Boot. You're free to sell it installed on computers that don't even support it, you just don't get Microsoft certification.
So, in case OEM opts in microsoft way, the user will be required to mess with his system in order to switch secure boot off.
This is good cause to void warranty.
This also adds additional complicated step and as such makes it harder for newbies. As you mentioned earlier "security consists of many layers" - these are two such "complication" layers in "securing the customer".
One more reason to pay FSF to sue microsoft arse.
Or switch altogether to OPEN platform, taking "Personal Computing" along. Because it ain't personal, when you are forbidden to do personal customization.
Because SecureBoot is required permanently ON for ARM and windowsRT, which is future of windows.
You can be assured, microsoft itself nullified your argument above.
---
And in case OEM opts out and decides to disable SecureBoot - he looses right to get "Windows 8 Certified" label.
Which means:
1. You are not considered microsoft professional or microsoft partner anymore.
1.1. If you are large enough, you can counter this.
2. Windows deactivates and will deactivate functionality, if the system is not certified.
2.1. This means to OEM, that their system with windows is crippled, although they pay same price to microsoft.
3. windows 8 OEM certification is a complex procedure involving preinstallation, activation and labeling of the machine. If OEM does not use this, the prices for windows installation will be SIGNIFICANTLY HIGHER - thus his solutions will cost more without being any different, which will unavoidably result in OEM going bankrupt due to (current, still holding) monopoly of microsoft.
The options above indicate microsoft to use nazi tactics or be nazi themself.
Either with us or our enemy.
You may surrender to our rules, or you will get such prices, that you will be out of the market in no time. And because we posses monopoly in marketshare, this is our market.
Note, this is similar to microsoft hardware OEM agreements, now coming in software.
Bonus: remember why Gaben started adapting to Linux.
Originally posted by mjg59 View PostIt looks for anything that it knows isn't a trusted boot loader and prevents it from running. So, it does?
However, the definiton of "Trusted" in "Secure Boot" means "Owner of the signing key"
The owner of the key is ....microsoft.
Hereby the only "Trusted" member is "microsoft" or assigned by "microsoft".
Welcome to antitrust law violation.
If the owner of the key would be ... anyone, which is what we have with BIOS password... there would be no lock-in and it would be a viable security feature.
This way, the OWNER of the hardware would generate a key, sign components and save key in own system, the same way CMOS did that, but inside non-volatile TPM module.
This is the correct way - to put the ownership in hands of the hardware owner.
But the key is in hands of microsoft as a sole decision maker and hence consititutes either MONOPOLY (similar to OS monopoly) or unavoidably embedded MICROSOFT-ONLY feature (similar to IE).
Originally posted by duby229 View Postheh... i give up....
Originally posted by mjg59 View PostSo, again, suggest a solution that solves the problem that Microsoft are trying to solve without preventing the booting of unsigned code.
They are making people trust a black box. The only way to achieve this is to lie and spread FUD.Last edited by crazycheese; 28 December 2012, 07:21 PM.
Comment
-
Originally posted by duby229 View PostIt does nothing for Linux. NOTHING. While linux does have its security issues... It doesnt need to worry about MS's security issues.
The reality is that these viruses can target any operating system, Linux included. Secure boot protects Linux just as effectively as it does windows, the only problem that is getting seriously discussed is that it may be difficult to load custom keys into the trusted keys list. (Notice that I said 'may', there is no guarantee that it will be difficult on all or even the majority of systems)
Comment
-
Originally posted by ShadowBane View PostSo, please tell me how Linux is magically safe from viruses that install themselves to the bootloader...
The reality is that these viruses can target any operating system, Linux included. Secure boot protects Linux just as effectively as it does windows, the only problem that is getting seriously discussed is that it may be difficult to load custom keys into the trusted keys list. (Notice that I said 'may', there is no guarantee that it will be difficult on all or even the majority of systems)
Build all modules in kernel.
Disable dynamic module loading.
Make /boot and / RO.
CRC the /boot partition and make independent system check-verify it, before booting it.
Place /etc on write-once media.
Activate NX and Apparmor.
Secured.
Comment
-
The touch hardware needs to be certified, not the entire platform.
The definition of "Trusted" should be "Owner".
Comment
Comment