On Thu, May 31, 2012 at 8:34 PM, Sam Varshavchik <mrsam@xxxxxxxxxxxxxxx> wrote: > Edward M writes: > >> On 05/31/2012 07:18 PM, Sam Varshavchik wrote: >> >>> positive and confident that this entire kit-and-kaboodle has no choice >>> but require a closed, hood-welded-shut OS, booted up with a signed chain, in >>> order for it to work. >> >> >> Oracle Solaris? > > > Yes, I think that would qualify. > > I would truly like for someone who is a lot more knowledgable than me, in > this area, to answer the following short list of simple questions for me. > Please, I'm desperate to know the answers to the following. Someone, please > have pity on me. I'm just feeling particularly stupid today, so someone > needs to patiently explain this to me: > > We're told that Fedora's bootloader is going to get signed – and by that, > that must mean "grub", right? > > And, grub can boot an arbitrary Linux kernel, right? > > So, a virus that wants to compromise a signed, secure bootload chain, can't > it simply install Fedora's signed grub, configured to boot a bare-bones > Linux kernel, nothing will prevent that, right? > > And, Fedora can load any kernel module, right? Hence, load the virus code > onto "bare metal", right? > > Then, can't the loaded virus code simply reboot back into the original, > Windows bootloader, that's now infected, and simply do what the virus > would've done originally, in the absence of a signed bootloader, right? > > If so, then what the FSCK did having an option for a signed bootloader > accomplish, here??? > > I don't have any answers to these questions (like I said, I'm feeling a bit > stupid today), but I do know one thing for sure. If everything that what's > been publicly said on this subject, so far, is true, then: > > Someone around here is a bloomin' idiot of the first degree. An absolute, > total, clueless moron. Complete, and total, brain damage. That could be > either myself – a possibility that I am perfectly willing to admit – or > Microsoft; or whoever's pushing this. > > The other possibility, of course, is that most of what's been publicly > stated about this subject, has either been a complete lie or a fabrication; > or certain crucial, fundamental details about this process, have been > omitted. It just /cannot/ work the way it's been publicly announced. > > Now, let me make a prediction of what I think is /really/ going to happen. > After thinking about this, oh, for maybe five minutes, tops, I think I have > up with the only answer that makes any logical sense, given everything > that's been publicly said. With apologies to Sir Arthur Conan Doyle, whose > literary masterpiece I'm about to butcher: when you exclude all > possibilities that are logically impossible, whatever's left, no matter how > highly improbable or bizarre, must be true. > > What I'm convinced that this is all about, is that Red Hat will simply get > Microsoft to sign a bootloader that will boot a kernel that's signed with > Red Hat's private key. The kernel will be configured to load only kernel > modules that are also signed by Red Hat's private key. OEMs that supply OEM > binary blobs, for stuff like RAID cards, etc, that are certified with RHEL, > will get Red Hat to sign their kernel modules for them, also for a token > certification key. That's the hood, welded shut, that's absolutely mandatory > for a secured bootloader to have any logical purpose, whatsoever. > > Based on publicly known information to me, this is the only situation that > makes any sense. Nothing else could possibly work, in any logical fashion. > > Fedora is not going to be a part of this. In order to boot Fedora, it will > be necessary to disable the secure bootload, on the hardware. > > I welcome anyone to explain what part of the above is logically false, and > why. > > This entire process makes no sense to me but please correct me if my limited knowledge and experience with Linux missed something. If the UEFI needs to be signed, then how would the kernel check the authenticity of the boot loader within UEFI? That would mean there should be either a local root certificate store or the kernel has to connect to the internet to verify. At which point, the smart virus/trojan/rootkit would insert it's own root certificate into the local store or replace the local store entirely. Furthermore, the smart virus/trojan/rootkit would replace the kernel with it's own kernel. Then there's a matter of constantly updating the local root certificate store. Even then how can we have any guaranteed of the boot sector and kernel not getting compromised? IMHO, I have a better proposal. Make it so that the boot sector and the /boot is located on a CD-R. Just burn a new CD-R when the kernel or /boot gets updated, or perhaps do a multi-sessions CD. You then have 0 chance of remote attacks compromising the boot sector and the kernel. That would leave just only 1 vulnerability that's a local (physically in front of the system) attack but that's no different than reset, popping in DVD and choose repair option. Regards, Tommy -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
