31–40 of 80 posts
It costs $99 to sign the software. I'm sure most of the distros can afford that (unless they take a die-hard stand, in which case, just don't buy a Windows pre-loaded PC from the OEM that disables the option to run Linux with).
The reason this is absolutely outrageous is that Microsoft gets to say what OS's you're allowed to install, because they control what they sign.
Earlier quoted context omitted.
I would assume that these UEFI machines have a built-in settings screen the same as BIOS-based machines do (and that screen would be where the setting we're discussing is found). If the only way to add keys is thru that screen, then you'd need physical access and malware adding keys wouldn't be an issue.
If there's a way to add keys there's a way to add keys. I don't think I'd rely on a screen being the only way to pull it off.
Earlier quoted context omitted.
Serious question: how does Secure Boot make you more secure? How many times has a virus latched onto your computer by executing before your system booted up? I've never heard of this happening to anyone I've ever known. The only scenario I can imagine is having a PC set to auto-boot from peripherals, and a USB key having something bad execute before invoking your hard disk's boot loader. And that is obviously possibl…
http://www.chmag.in/article/sep2011/rootkits-are-back-boot-i... http://www.theregister.co.uk/2010/11/16/tdl_rootkit_does_64_... http://www.computerworld.com/s/article/9217953/Rootkit_infec... A snippet: TDL4 is the most recent high tech and widely spread member of the TDSS family rootkit, targeting x64 operating systems too such as Windows Vista and Windows 7. One of the most striking features of TDL4 is that it is a…
So the concern is that the virus is installed like any others on Windows; but then it keeps itself installed through the boot process reloading it. Thus it must intentionally damage any internal Windows protections that would try and check for it during its own startup. Which of course would be a cat and mouse game.
Okay then, what stops a theoretical TDL5 from using a Linux distro's signed kernel/bootloader to boot a little mini OS that then does the same thing TDL4 does now? (even if the Secure Boot Linux kernel locks out kernel driver access; maybe it uses a privilege escalation exploit to regain that access)
It would seem like the only way Windows could be absolutely certain that only its own code executed up to the completion of boot would be if Microsoft were the only company that could sign working boot code for a hardware device. The gains in security wouldn't be worth the loss of freedom.
Earlier quoted context omitted.
Serious question: how does Secure Boot make you more secure? How many times has a virus latched onto your computer by executing before your system booted up? I've never heard of this happening to anyone I've ever known. The only scenario I can imagine is having a PC set to auto-boot from peripherals, and a USB key having something bad execute before invoking your hard disk's boot loader. And that is obviously possibl…
I read an article a couple of months back (like October-Novemberish 2014) about the NSA putting a virus into the firmware of a RAID controller on some Dell servers that would patch Windows Server 2003 (R2?) during startup. So it is not entirely without precedent. Then again, this did not touch the OS bootloader itself, strictly speaking and might not have been prevented by "Secure Boot". Also, once you're diddling wi…
From http://www.linuxjournal.com/content/growing-role-uefi-secure...
>Malware developers have increased their attempts to attack the pre-boot environment because operating system and antivirus software vendors have hardened their code. Malware hidden in the firmware is virtually untraceable by the operating system, unless a search specifically targets malware within the firmware. UEFI Secure Boot assists with system firmware, driver and software validation
>Without UEFI Secure Boot, malware developers can more easily take advantage of several pre-boot attack points, including the system-embedded firmware itself, as well as the interval between the firmware initiation and the loading of the operating system
>Nevertheless, in a variety of implementations that have already reached the market, UEFI Secure Boot has proven to be a practical and useful tool for improving platform integrity and successfully defending the point of attack for a dangerous class of pre-operating system malware.
Ubuntu, Redhat, and other distros are compatible with secure boot. I understand the concern, but the flip side is that if secure boot makes my future Ubuntu laptops more secure that could be a good thing. Linux is here to stay. Relax.
This is true today, but it ignores the realities of many secure boot implementations. Specifically, many UEFI firmware vendors don't include the ability for the hardware owner to update the public key used to verify a bootloader signature. This means that someone wanting to use a new bootloader on one of these platforms has to beg for permission from whoever owns the existing keys (Microsoft seems to be popular right…
Although I am a fan, for my own projects, of GPL and AGPL licenses, I do like the availability of commercial apps on Linux. I like Linux because it is a great development platform but I am less of a purist than I used to be concerning an occasional commercial app.
Earlier quoted context omitted.
The problem was IIRC that you need something signed with MS key to be able to boot whatever. If you are able to set your own keys - then there is almost no problem (still usb flashes and so on will be harder to boot)
> If you are able to set your own keys - then there is almost no problem Doesn't this make the feature useless from a security standpoint? If you're able to create your own keys then malware could create its own keys. Maybe if manufacturers could do it that would be handy.
The first time you log in to a server with ssh, it asks you if you should accept the particular fingerprint it just got. You either say yes or no.
Thereafter, if it changes, you get a big fat warning about potentially being hacked.
From a security standpoint, this is no different.
Earlier quoted context omitted.
Serious question: how does Secure Boot make you more secure? How many times has a virus latched onto your computer by executing before your system booted up? I've never heard of this happening to anyone I've ever known. The only scenario I can imagine is having a PC set to auto-boot from peripherals, and a USB key having something bad execute before invoking your hard disk's boot loader. And that is obviously possibl…
I read an article a couple of months back (like October-Novemberish 2014) about the NSA putting a virus into the firmware of a RAID controller on some Dell servers that would patch Windows Server 2003 (R2?) during startup. So it is not entirely without precedent. Then again, this did not touch the OS bootloader itself, strictly speaking and might not have been prevented by "Secure Boot". Also, once you're diddling wi…
I'd say that there's a better than even chance that the NSA already has Microsoft's secure boot private key.
It costs $99 to sign the software. I'm sure most of the distros can afford that (unless they take a die-hard stand, in which case, just don't buy a Windows pre-loaded PC from the OEM that disables the option to run Linux with).
The cost alone is one thing, that'd only ruin the ability of hobbyists to create new OSes. Something exceedingly rare anymore, sadly.
But the restrictions stating what your kernel is allowed to let you do is quite another. I want the ability to write my own kernel space drivers on my own hardware, if I so choose (and I have done so in the past.)
Ubuntu, Redhat, and other distros are compatible with secure boot. I understand the concern, but the flip side is that if secure boot makes my future Ubuntu laptops more secure that could be a good thing. Linux is here to stay. Relax.
What if I prefer Debian over Ubuntu? Can I be upset then? I'm sure this will be possible to hack around, but we shouldn't have to hack our own computers to use them. A simple option to disable secure boot would solve all the problems. The vendors know this, so I'm curious why they would chose to not provide the option. Is there some belief that by even having the option, the system would be inherently more insecure?…
Come on. I prefer BSD based OSX and Linux myself, but to think that a large enough number of buyers care about Linux support to "spike" sellers is just silly. It's done well on servers, but it's a very small market for consumers. Not to mention Ubuntu and RedHat are compatible, so it isn't even an issue for some of the biggest distributions.