Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers
On Wednesday 06 Jun 2012 20:50:38 Michael Mol wrote: On Wed, Jun 6, 2012 at 3:40 PM, Mick michaelkintz...@gmail.com wrote: [snip] This is my CPU, a first generation i7: cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 30 model name : Intel(R) Core(TM) i7 CPU Q 720 @ 1.60GHz stepping: 5 microcode : 0x4 cpu MHz : 933.000 cache size : 6144 KB physical id : 0 siblings: 8 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dts tpr_shadow vnmi flexpriority ept vpid bogomips: 3192.11 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: You note that power management: above is empty. grep-ping the /proc tree for remoteaccess does not bring up anything. According to Intel's site, your processor has the vPro feature in it. http://ark.intel.com/products/43122/Intel-Core-i7-720QM-Processor-(6M-Cache -1_60-GHz) Can you find the device you noticed under /sys? No, nothing when I search for remote or remoteaccess or access ... If this Intel AMT, or vPRO thingy is outside the MoBo chipset then it may not get probed or be accessible by the kernel? But then, how does lshw see it? *-remoteaccess UNCLAIMED vendor: Intel physical id: 2 capabilities: outbound --what does this mean? O_O -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers
On 7 June 2012, at 00:50, William Kenworthy wrote: ... I dont mean cpu power management, I meant under the kernel config option which you may not have enabled. As for the Dell iDREC, google it. This stuff is old in enterprise equipment, and I suspect not widely used but it is out there. Did you mean Dell DRAC? This is not obsolete at all, although in current models it is branded iDRAC. I don't believe DRAC remote access is really related to IPMI, however. I'm pretty sure that IPMI will work with a PowerEdge even lacking the DRAC module. OP is taking about having a laptop, anyway, so that seems like a clupea rubra. Stroller.
Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers
On Wednesday 06 Jun 2012 02:14:45 Bill Kenworthy wrote: On Tue, 2012-06-05 at 10:21 -0400, Michael Mol wrote: On Tue, Jun 5, 2012 at 8:52 AM, Mick michaelkintz...@gmail.com wrote: On Monday 04 Jun 2012 13:57:11 Michael Mol wrote: On Mon, Jun 4, 2012 at 8:48 AM, Mick michaelkintz...@gmail.com wrote: On Saturday 02 Jun 2012 23:50:58 pk wrote: [snip] I'm putting on my tinfoil hat now and I'm going to pretend it's raining... :-/ Can I please join you if you have a spare hat? On a 3 year old Dell laptop manufactured by the famous and well known Winbond Electronics /sarcasm I see this under lshw: *-remoteaccess UNCLAIMED vendor: Intel physical id: 2 capabilities: outbound but have not found a way of interrogating it or in anyway accessing it to understand what it is or does ... Note, this is not a UEFI machine: capabilities: smbios-2.6 dmi-2.6 vsyscall32 What proc? If you mean what /proc is this remoteaccess thing in, I don't really know. How can I find it? Sorry...what CPU do you have? cat /proc/cpuinfo Maybe this? - https://en.wikipedia.org/wiki/Intelligent_Platform_Management_Interface There is a kernel interface (under power management I think) and I seem to remember some of my recent motherboards come with it. If you have a dell, look up iDRECV which does something similar. Its not only the cpu, but the motherboard you need to worry about. BillK This is my CPU, a first generation i7: cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 30 model name : Intel(R) Core(TM) i7 CPU Q 720 @ 1.60GHz stepping: 5 microcode : 0x4 cpu MHz : 933.000 cache size : 6144 KB physical id : 0 siblings: 8 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dts tpr_shadow vnmi flexpriority ept vpid bogomips: 3192.11 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: You note that power management: above is empty. grep-ping the /proc tree for remoteaccess does not bring up anything. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers
On Wed, Jun 6, 2012 at 3:40 PM, Mick michaelkintz...@gmail.com wrote: [snip] This is my CPU, a first generation i7: cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 30 model name : Intel(R) Core(TM) i7 CPU Q 720 @ 1.60GHz stepping : 5 microcode : 0x4 cpu MHz : 933.000 cache size : 6144 KB physical id : 0 siblings : 8 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dts tpr_shadow vnmi flexpriority ept vpid bogomips : 3192.11 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: You note that power management: above is empty. grep-ping the /proc tree for remoteaccess does not bring up anything. According to Intel's site, your processor has the vPro feature in it. http://ark.intel.com/products/43122/Intel-Core-i7-720QM-Processor-(6M-Cache-1_60-GHz) Can you find the device you noticed under /sys? -- :wq
Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers
power management: You note that power management: above is empty. grep-ping the /proc tree for remoteaccess does not bring up anything. I dont mean cpu power management, I meant under the kernel config option which you may not have enabled. As for the Dell iDREC, google it. This stuff is old in enterprise equipment, and I suspect not widely used but it is out there. BillK
Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers
On Mon, Jun 04, 2012 at 10:34:58AM -0400, Michael Mol wrote On Mon, Jun 4, 2012 at 9:33 AM, BRM bm_witn...@yahoo.com wrote: We'll see if SecureBoot actually even makes it to market; if it does, expect some Class Action lawsuits to occur. We'll see. Don't forget _you can turn the thing off_. I expect the lawsuits will come around when the ability to turn the thing off or reconfigure it is removed. The reason there is so much hate for TPM/Palladium/etc is that they're tied into failed legislation proposed by former South Carolina Senator Fritz Hollings. He was jokingly referred to as the Democrat from Disney, because he seemed to spend more energy representing big media than the people of his state. Fire up Google and look up the terms... SSSCA CBDTPA Fritz chip This was intended to be draconian mandatory DRM on every PC. Importing or building one without it would result in five to twenty years in prison, and fines between $50,000 and $1 million. It would've effectively outlawed linux. MS is trying to use its corporate muscle to do via market manipulation what legislators couldn't. -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers
On Monday 04 Jun 2012 13:57:11 Michael Mol wrote: On Mon, Jun 4, 2012 at 8:48 AM, Mick michaelkintz...@gmail.com wrote: On Saturday 02 Jun 2012 23:50:58 pk wrote: [snip] I'm putting on my tinfoil hat now and I'm going to pretend it's raining... :-/ Can I please join you if you have a spare hat? On a 3 year old Dell laptop manufactured by the famous and well known Winbond Electronics /sarcasm I see this under lshw: *-remoteaccess UNCLAIMED vendor: Intel physical id: 2 capabilities: outbound but have not found a way of interrogating it or in anyway accessing it to understand what it is or does ... Note, this is not a UEFI machine: capabilities: smbios-2.6 dmi-2.6 vsyscall32 What proc? If you mean what /proc is this remoteaccess thing in, I don't really know. How can I find it? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers
On Tue, Jun 5, 2012 at 8:52 AM, Mick michaelkintz...@gmail.com wrote: On Monday 04 Jun 2012 13:57:11 Michael Mol wrote: On Mon, Jun 4, 2012 at 8:48 AM, Mick michaelkintz...@gmail.com wrote: On Saturday 02 Jun 2012 23:50:58 pk wrote: [snip] I'm putting on my tinfoil hat now and I'm going to pretend it's raining... :-/ Can I please join you if you have a spare hat? On a 3 year old Dell laptop manufactured by the famous and well known Winbond Electronics /sarcasm I see this under lshw: *-remoteaccess UNCLAIMED vendor: Intel physical id: 2 capabilities: outbound but have not found a way of interrogating it or in anyway accessing it to understand what it is or does ... Note, this is not a UEFI machine: capabilities: smbios-2.6 dmi-2.6 vsyscall32 What proc? If you mean what /proc is this remoteaccess thing in, I don't really know. How can I find it? Sorry...what CPU do you have? cat /proc/cpuinfo -- :wq
Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers
On Tue, 2012-06-05 at 10:21 -0400, Michael Mol wrote: On Tue, Jun 5, 2012 at 8:52 AM, Mick michaelkintz...@gmail.com wrote: On Monday 04 Jun 2012 13:57:11 Michael Mol wrote: On Mon, Jun 4, 2012 at 8:48 AM, Mick michaelkintz...@gmail.com wrote: On Saturday 02 Jun 2012 23:50:58 pk wrote: [snip] I'm putting on my tinfoil hat now and I'm going to pretend it's raining... :-/ Can I please join you if you have a spare hat? On a 3 year old Dell laptop manufactured by the famous and well known Winbond Electronics /sarcasm I see this under lshw: *-remoteaccess UNCLAIMED vendor: Intel physical id: 2 capabilities: outbound but have not found a way of interrogating it or in anyway accessing it to understand what it is or does ... Note, this is not a UEFI machine: capabilities: smbios-2.6 dmi-2.6 vsyscall32 What proc? If you mean what /proc is this remoteaccess thing in, I don't really know. How can I find it? Sorry...what CPU do you have? cat /proc/cpuinfo Maybe this? - https://en.wikipedia.org/wiki/Intelligent_Platform_Management_Interface There is a kernel interface (under power management I think) and I seem to remember some of my recent motherboards come with it. If you have a dell, look up iDRECV which does something similar. Its not only the cpu, but the motherboard you need to worry about. BillK
Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers
On Saturday 02 Jun 2012 23:50:58 pk wrote: On 2012-06-02 22:10, Michael Mol wrote: I expect the chief mechanism is at the manufacturer's end; blacklisted keys get included on shipment. Makes sense. It's also probable that the OS kernel can tell the UEFI BIOS about new keys to blacklist. I expect that'll be a recurring thing in the Monthly batch of security updates Microsoft puts out. (Makes sense, really; if malware is using a key, blacklist that key.) Yes, would expect something like this. Secure boot supposedly prevents unauthorized firmware, operating systems or UEFI drivers at boot time. So if I interpret this correctly it would mean that if I have, say, an old graphics card with an old firmware (vga bios) I can't use it with secure boot. More interestingly, how is an operating system defined? Does it mean only the kernel itself or does it mean a full-blown OS with init and other supporting software? What does that mean to a source based distro? Also, I would assume a legitimate key would be able to sign pretty much any binary so a key that Fedora uses could be used to sign malware for Windows, which then would be blacklisted by Microsoft... and how is malware defined? Anything that would be detrimental to Microsoft? Someone linked to some absolutely terrible stuff being built into Intel's Ivy Bridge...it's plausible it will be possible to deploy You mean: https://en.wikipedia.org/wiki/Intel_insider#Intel_Insider_and_remote-contro l ? blacklist key updates over the network within a couple years. Well, UEFI already implements remote management: http://www.uefi.org/news/UEFI_Overview.pdf (page 13) ... so implementing an automatic update over the network, preferably via SMM/SMI so that the operating system cannot intervene would be possible already today... and you've lost control of your computer. I'm putting on my tinfoil hat now and I'm going to pretend it's raining... :-/ Best regards Peter K Can I please join you if you have a spare hat? On a 3 year old Dell laptop manufactured by the famous and well known Winbond Electronics /sarcasm I see this under lshw: *-remoteaccess UNCLAIMED vendor: Intel physical id: 2 capabilities: outbound but have not found a way of interrogating it or in anyway accessing it to understand what it is or does ... Note, this is not a UEFI machine: capabilities: smbios-2.6 dmi-2.6 vsyscall32 -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers
On Mon, Jun 4, 2012 at 8:48 AM, Mick michaelkintz...@gmail.com wrote: On Saturday 02 Jun 2012 23:50:58 pk wrote: [snip] I'm putting on my tinfoil hat now and I'm going to pretend it's raining... :-/ Can I please join you if you have a spare hat? On a 3 year old Dell laptop manufactured by the famous and well known Winbond Electronics /sarcasm I see this under lshw: *-remoteaccess UNCLAIMED vendor: Intel physical id: 2 capabilities: outbound but have not found a way of interrogating it or in anyway accessing it to understand what it is or does ... Note, this is not a UEFI machine: capabilities: smbios-2.6 dmi-2.6 vsyscall32 What proc? -- :wq
Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers
From: Michael Mol mike...@gmail.com On Sat, Jun 2, 2012 at 10:04 PM, BRM bm_witn...@yahoo.com wrote: From: Michael Mol mike...@gmail.com [snip] In theory that's how key signing systems are suppose to work. In practice, they rarely implement the blacklists as they are (i) hard to maintain, and (ii) hard to distribute in an effective manner. Indeed. While Firefox, Chromium, et al check certificate revocation lists, Microsoft doesn't; they distribute them as part of Windows Update. Which can then be intercepted by IT in any IT department that stages Windows Update using their own servers. Honestly, I don't expect SecureBoot to last very long. Either MS and the OEMs will be forced to always allow users to disable it, or they'll be simply drop it - kind of like they did with TPM requirements that were talked about 10 years back and never came to fruition. TPM is still around for organizations which can use them. And, honestly, I've been annoyed that they haven't been widespread, nor easy to pick up in the aftermarket. (They come with a random number generator...just about any HRNG is going to be better than none.) Yes TPM (originally named Palladium) is still around. However its use is almost non-existent. When it was proposed, it was to include SecureBoot and enable secure Internet transactions, etc. None of that came to fruition. Now, after over a decade of ignoring it, they are trying it one step at a time, first with SecureBoot. I see something like SecureBoot as being useful in corporate and military security contexts. I don't see it lasting in SOHO environments. Certain environments as you say may find it useful; but then those environments already have very stringent controls over the computers in those environments, often to the inability of people to do their job. [snip] What kind of signature is the bootloader checking, anyway? Regardless of the check, it'll never be sufficient. Sure; ultimately, all DRM solutions get cracked. TPM and SecureBoot will by design fail. We'll see if SecureBoot actually even makes it to market; if it does, expect some Class Action lawsuits to occur. Ben
Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers
On Mon, Jun 4, 2012 at 9:33 AM, BRM bm_witn...@yahoo.com wrote: From: Michael Mol mike...@gmail.com On Sat, Jun 2, 2012 at 10:04 PM, BRM bm_witn...@yahoo.com wrote: From: Michael Mol mike...@gmail.com [snip] In theory that's how key signing systems are suppose to work. In practice, they rarely implement the blacklists as they are (i) hard to maintain, and (ii) hard to distribute in an effective manner. Indeed. While Firefox, Chromium, et al check certificate revocation lists, Microsoft doesn't; they distribute them as part of Windows Update. Which can then be intercepted by IT in any IT department that stages Windows Update using their own servers. Only if the workstation is so configured. (i.e. it's joined to the domain, or has otherwise had configuration placed on it.) It's not just a matter of setting up a caching proxy server and modifying the files before they're delivered. And if you think that's a risk, then consider that your local domain administrator has the ability to push out the organization CA into your system cert store as a trusted CA, and can then go on to create global certs your browser won't complain about. If you don't own the network, don't expect to be able to do things on it that the network administrator doesn't want you to do. At the same time, he can't force (much...see DHCP) configuration onto your machine without your being aware, at least if you're at least somewhat responsible in knowing how configuring your machine works. Honestly, I don't expect SecureBoot to last very long. Either MS and the OEMs will be forced to always allow users to disable it, or they'll be simply drop it - kind of like they did with TPM requirements that were talked about 10 years back and never came to fruition. TPM is still around for organizations which can use them. And, honestly, I've been annoyed that they haven't been widespread, nor easy to pick up in the aftermarket. (They come with a random number generator...just about any HRNG is going to be better than none.) Yes TPM (originally named Palladium) is still around. However its use is almost non-existent. No, TPM wasn't originally named Palladium. TPM was the keystore hardware component of a broader system named Palladium. The TPM is just a keystore and a crypto accelerator, both of which are two things valuable to _everybody_. The massive backlash against Palladium is at least part of why even a generally useful hardware component like the TPM never got distributed. Imagine if the floating-point coprocessor was ditched in x86 because people thought it was a conspiracy to induce difficult-to-resolve math precision errors from careless use of floating point arithmetic. The part you're worried about is the curtained memory and hardware lockout, which it sounds like Intel is distributing with vPro. When it was proposed, it was to include SecureBoot and enable secure Internet transactions, etc. None of that came to fruition. Now, after over a decade of ignoring it, they are trying it one step at a time, first with SecureBoot. I see something like SecureBoot as being useful in corporate and military security contexts. I don't see it lasting in SOHO environments. Certain environments as you say may find it useful; but then those environments already have very stringent controls over the computers in those environments, often to the inability of people to do their job. The nature of those controls stems at least in part from the ability to use other means to maintain an overall security policy. With more tools comes the ability to be more flexible, allowing people to do more convenient convenient things (such as insert a flash drive or CD into a computer) at lower risk (it'll be more difficult to accidentally boot from that flash drive or CD). It's for similar reasons the Linux kernel has support for fine-grained access controls; you can grant additional privileges where needed, and reduce the base set of privileges required. And here's a use case that might seem worthwhile...Say you've got hardware with SecureBoot. Now, you don't run Windows, so you don't care about the UEFI BIOS having Microsoft's key. Instead, you're a Linux guy, and you're very privacy conscious; perhaps you're a security consultant or contractor. Or perhaps you're worried about corporate espionage. Or perhaps you're simply afraid of governments. You can flush Microsoft's key from BIOS and insert your own. Sign your bootloader, kernel and initramfs. Set up your / filesystem to be fully encrypted. And configure things such that if BIOS isn't operating in SecureBoot mode with your key, it won't even mount and decrypt your / filesystem. You've just denied access to any existing forensic tool which would either examine your hard disk or operate as a rootkit. The only thing that's going to get your data is a live inspection of your RAM (tricky! but doable.) or a rubber hose. What kind of signature is the bootloader checking,
Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers
On 2012-06-04 14:48, Mick wrote: Can I please join you if you have a spare hat? Sure, got lots of (virtual) hats... here's one: ^ (may be a bit small) ;-) On a 3 year old Dell laptop manufactured by the famous and well known Winbond Electronics /sarcasm I see this under lshw: *-remoteaccess UNCLAIMED vendor: Intel physical id: 2 capabilities: outbound but have not found a way of interrogating it or in anyway accessing it to understand what it is or does ... Note, this is not a UEFI machine: capabilities: smbios-2.6 dmi-2.6 vsyscall32 https://en.wikipedia.org/wiki/System_Management_BIOS https://en.wikipedia.org/wiki/Desktop_Management_Interface SMBIOS does support out-of-band management, which may or may not be scary, depending on who's in control of it... https://en.wikipedia.org/wiki/Out-of-band_management If you have an Intel processor in that laptop that supports vPro, I would assume it's a professional laptop, and as such it might make sense (assuming the IT department in your company is in control). Here's an interesting link that describes some of the problems with modern computers (it's an approx 1 hour long video from Google Tech talks, regarding coreboot): https://www.youtube.com/watch?v=X72LgcMpM9k Best regards Peter K
Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers
From: Michael Mol mike...@gmail.com On Mon, Jun 4, 2012 at 9:33 AM, BRM bm_witn...@yahoo.com wrote: From: Michael Mol mike...@gmail.com On Sat, Jun 2, 2012 at 10:04 PM, BRM bm_witn...@yahoo.com wrote: From: Michael Mol mike...@gmail.com [snip] In theory that's how key signing systems are suppose to work. In practice, they rarely implement the blacklists as they are (i) hard to maintain, and (ii) hard to distribute in an effective manner. Indeed. While Firefox, Chromium, et al check certificate revocation lists, Microsoft doesn't; they distribute them as part of Windows Update. Which can then be intercepted by IT in any IT department that stages Windows Update using their own servers. Only if the workstation is so configured. (i.e. it's joined to the domain, or has otherwise had configuration placed on it.) It's not just a matter of setting up a caching proxy server and modifying the files before they're delivered. And if you think that's a risk, then consider that your local domain administrator has the ability to push out the organization CA into your system cert store as a trusted CA, and can then go on to create global certs your browser won't complain about. If you don't own the network, don't expect to be able to do things on it that the network administrator doesn't want you to do. At the same time, he can't force (much...see DHCP) configuration onto your machine without your being aware, at least if you're at least somewhat responsible in knowing how configuring your machine works. True. My point was that since Microsoft is using Windows Update to update the CRLs, that the corporate IT departments could decide not to allow the update to go through. Of course, it's their risk if they don't allow it through. Further, they can push out CRLs even if Microsoft doesn't send them. But that's not the concern unless you want your device free of the IT department, and that's a wholly different issue. And of course, they can't change the CA on a WinRT device for SecureBoot. Honestly, I don't expect SecureBoot to last very long. Either MS and the OEMs will be forced to always allow users to disable it, or they'll be simply drop it - kind of like they did with TPM requirements that were talked about 10 years back and never came to fruition. TPM is still around for organizations which can use them. And, honestly, I've been annoyed that they haven't been widespread, nor easy to pick up in the aftermarket. (They come with a random number generator...just about any HRNG is going to be better than none.) Yes TPM (originally named Palladium) is still around. However its use is almost non-existent. No, TPM wasn't originally named Palladium. TPM was the keystore hardware component of a broader system named Palladium. The TPM is just a keystore and a crypto accelerator, both of which are two things valuable to _everybody_. The massive backlash against Palladium is at least part of why even a generally useful hardware component like the TPM never got distributed. Imagine if the floating-point coprocessor was ditched in x86 because people thought it was a conspiracy to induce difficult-to-resolve math precision errors from careless use of floating point arithmetic. The part you're worried about is the curtained memory and hardware lockout, which it sounds like Intel is distributing with vPro. TPM, SecureBoot, and Palladium are both beasts which need to be removed. When it was proposed, it was to include SecureBoot and enable secure Internet transactions, etc. None of that came to fruition. Now, after over a decade of ignoring it, they are trying it one step at a time, first with SecureBoot. I see something like SecureBoot as being useful in corporate and military security contexts. I don't see it lasting in SOHO environments. Certain environments as you say may find it useful; but then those environments already have very stringent controls over the computers in those environments, often to the inability of people to do their job. The nature of those controls stems at least in part from the ability to use other means to maintain an overall security policy. With more tools comes the ability to be more flexible, allowing people to do more convenient convenient things (such as insert a flash drive or CD into a computer) at lower risk (it'll be more difficult to accidentally boot from that flash drive or CD). How often do people accidentally boot from the wrong device? It's probably more of an issue for USB devices than floppy/CDs any more, but still. And why destroy people's ability to boot from USB/CD/Floppy? Let's not forget this makes it harder for Gentoo (and numerous other distros and OSes) to go on devices. The user should own and control the device, not a corporate entity (except where said corporate entity purchased the device in the first place). It's for similar reasons the Linux kernel has support for fine-grained access controls; you can grant
Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers
On Mon, Jun 4, 2012 at 5:13 PM, BRM bm_witn...@yahoo.com wrote: From: Michael Mol mike...@gmail.com On Mon, Jun 4, 2012 at 9:33 AM, BRM bm_witn...@yahoo.com wrote: From: Michael Mol mike...@gmail.com On Sat, Jun 2, 2012 at 10:04 PM, BRM bm_witn...@yahoo.com wrote: From: Michael Mol mike...@gmail.com [snip] Honestly, I don't expect SecureBoot to last very long. Either MS and the OEMs will be forced to always allow users to disable it, or they'll be simply drop it - kind of like they did with TPM requirements that were talked about 10 years back and never came to fruition. TPM is still around for organizations which can use them. And, honestly, I've been annoyed that they haven't been widespread, nor easy to pick up in the aftermarket. (They come with a random number generator...just about any HRNG is going to be better than none.) Yes TPM (originally named Palladium) is still around. However its use is almost non-existent. No, TPM wasn't originally named Palladium. TPM was the keystore hardware component of a broader system named Palladium. The TPM is just a keystore and a crypto accelerator, both of which are two things valuable to _everybody_. The massive backlash against Palladium is at least part of why even a generally useful hardware component like the TPM never got distributed. Imagine if the floating-point coprocessor was ditched in x86 because people thought it was a conspiracy to induce difficult-to-resolve math precision errors from careless use of floating point arithmetic. The part you're worried about is the curtained memory and hardware lockout, which it sounds like Intel is distributing with vPro. TPM, SecureBoot, and Palladium are both beasts which need to be removed. I'm still confused by your malice toward the TPM. What part of 'crypto coprocessor' or 'crypto accelerator' doesn't get you thinking about faster SSH and SSL connection setup and data transfers? [snip] The nature of those controls stems at least in part from the ability to use other means to maintain an overall security policy. With more tools comes the ability to be more flexible, allowing people to do more convenient convenient things (such as insert a flash drive or CD into a computer) at lower risk (it'll be more difficult to accidentally boot from that flash drive or CD). How often do people accidentally boot from the wrong device? You know how many Linux install flash drives are floating around? What about OS install CDs? A curious artifact of both is that they're left in systems so _frequently_, they're often designed to proceed back to a disk-based boot after a timeout. It's probably more of an issue for USB devices than floppy/CDs any more, but still. The Gentoo 12.1 LiveDVD also has the timeout-and-boot. And it's quite common for people to leave flash drives plugged into systems over boot cycles; it's like a portable 'My Documents' folder. And why destroy people's ability to boot from USB/CD/Floppy? You're not; you can turn off SecureBoot in BIOS, and then boot from USB or CD as normal. Though why you'd boot from a floppy on a system that has SecureBoot, I have no idea. (It's questionable whether systems shipping SecureBoot will even have floppy controllers...) Being able to disable SecureBoot is going to be _critical_ for application of diagnostics, forensics and system repair. And if it comes down to it, you'll likely be able to get those tools signed, too. Let's not forget this makes it harder for Gentoo (and numerous other distros and OSes) to go on devices. Nobody's forgotten that. Now let's not forget how easy it will be to turn SecureBoot off. You're likely to have a harder time getting latest-grade RAM functioning in a brand-new new system, what with timings and gang modes to contend with. The user should own and control the device, not a corporate entity (except where said corporate entity purchased the device in the first place). Fully concur...and I'm moderately impressed; most people I've seen argue things like this can't make that distinction. It's for similar reasons the Linux kernel has support for fine-grained access controls; you can grant additional privileges where needed, and reduce the base set of privileges required. Linux has fine grain control because that's what's required for Common Criteria, and what the NSA implemented for SELinux. SELinux required it because it was necessary. Linux included SELinux because it's legitimately useful. Anything legitimately useful for someone else to keep you out of their stuff is legitimately useful for you to keep them out of yours. And here's a use case that might seem worthwhile...Say you've got hardware with SecureBoot. Now, you don't run Windows, so you don't care about the UEFI BIOS having Microsoft's key. Instead, you're a Linux guy, and you're very privacy conscious; perhaps you're a security consultant or contractor. Or perhaps you're worried about corporate espionage. Or perhaps you're
Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers
On Mon, 2012-06-04 at 10:34 -0400, Michael Mol wrote: On Mon, Jun 4, 2012 at 9:33 AM, BRM bm_witn...@yahoo.com wrote: From: Michael Mol mike...@gmail.com On Sat, Jun 2, 2012 at 10:04 PM, BRM bm_witn...@yahoo.com wrote: From: Michael Mol mike...@gmail.com [snip] In theory that's how key signing systems are suppose to work. ... I see something like SecureBoot as being useful in corporate and military security contexts. I don't see it lasting in SOHO environments. ... And here's a use case that might seem worthwhile...Say you've got hardware with SecureBoot. Now, you don't run Windows, so you don't care about the UEFI BIOS having Microsoft's key. Instead, you're a Linux guy, and you're very privacy conscious; perhaps you're a security consultant or contractor. Or perhaps you're worried about corporate espionage. Or perhaps you're simply afraid of governments. You can flush Microsoft's key from BIOS and insert your own. Sign your bootloader, kernel and initramfs. Set up your / filesystem to be fully encrypted. And configure things such that if BIOS isn't operating in SecureBoot mode with your key, it won't even mount and decrypt your / filesystem. You've just denied access to any existing forensic tool which would either examine your hard disk or operate as a rootkit. The only thing that's going to get your data is a live inspection of your RAM (tricky! but doable.) or a rubber hose. ... We have a security researcher at work who specialises in the forensics side - expert witness in court and does data retrieval etc ... I dont think he has had anyone seriously try to hide anything yet, but if the above becomes common in the non-law abiding set, the govt will have it back doored or dissappeared (banned from sale or heavily controlled). Think of the children ... which is overused here in Oz comes to mind. Providing tools to strip cell phone data and PC hard disks seems to be a popular/profitable business to be in at the moment :) BillK
Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers
On Sat, Jun 02, 2012 at 07:36:51PM -0400, Michael Mol wrote The BIOS will only load a signed bootloader. The signed bootloader will only load a signed kernel. OK, so I sign LILO. What code is in there that prevents LILO from loading whatever kernel I've compiled? The signed kernel will...do whatever you tell it to do. Define kernel... no... seriously. 1) Could it actually be a hypervisor? 2) Or maybe another copy of LILO which proceeds to load the actual kernel? -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers
Am 03.06.2012 08:57, schrieb Walter Dnes: On Sat, Jun 02, 2012 at 07:36:51PM -0400, Michael Mol wrote The BIOS will only load a signed bootloader. The signed bootloader will only load a signed kernel. OK, so I sign LILO. What code is in there that prevents LILO from loading whatever kernel I've compiled? Nothing. The point is, if you sign software that is used (or can be used) for malware, your key will be blacklisted. That's why Fedora takes the measures I've listed: They don't want to have their key revoked. The signed kernel will...do whatever you tell it to do. Define kernel... no... seriously. 1) Could it actually be a hypervisor? 2) Or maybe another copy of LILO which proceeds to load the actual kernel? Sure, whatever floats your boat. UEFI only checks the boot loader directly. After that, it is the boot loader's responsibility to keep the next stage secure. But if you allow unchecked access to the hardware through whatever signed code you have, your key will be blacklisted. To quote Matthew again: Secure boot is built on the idea that all code that can touch the hardware directly is trusted, and any untrusted code must go through the trusted code. This can be circumvented if users can execute arbitrary code in the kernel. So, we'll be moving to requiring signed kernel modules and locking down certain aspects of kernel functionality. The most obvious example is that it won't be possible to access PCI regions directly from userspace, which means all graphics cards will need kernel drivers. Userspace modesetting will be a thing of the past. Again, disabling secure boot will disable these restrictions. Regards, Florian Philipp signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers
Am 02.06.2012 04:26, schrieb William Kenworthy: http://boingboing.net/2012/05/31/lockdown-freeopen-os-maker-p.html and something I had not considered with the whole idea was even bootable cd's and usb keys for rescue will need the same privileges ... BillK I find this article lacking in substance. You get a much more reasonable view reading the original blog post by Matthew Garrett [1]. A few points: meaning that unless Microsoft has blessed your favorite flavor of GNU/Linux or BSD, you won't be able to just install it on your machine, or boot to it from a USB stick or CD to try it out. You don't have to be blessed. You could call your distribution BallmerSucks and still get a certificate. You just have to register, authenticate and pay the fee. Anything else would earn them an antitrust law suite they wouldn't forget. There is a work-around for some systems involving a finicky and highly technical override process, but all that means is that installing proprietary software is easy and installing free/open software is hard. They mean finicky as in go to the BIOS and switch it off and some systems as in all x86 hardware but not ARM? Yeah, the situation is not nice but it is not as bad as it could be. Microsoft requires that it can be switched off for x86. It forbids it for ARM, though. The article gets that bit right. Regarding the 99$ ransom: It is a one-off payment. The article should have made that clear. Okay, enough bashing the article. Some technical question: As I understand it, if I want to make a live CD or a distribution, all I'd need to do is to use Fedora's kernel and boot loader? That's not so bad. [1] http://mjg59.dreamwidth.org/12368.html Regards, Florian Philipp signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers
On 2012-06-02 09:43, Florian Philipp wrote: You don't have to be blessed. You could call your distribution BallmerSucks and still get a certificate. You just have to register, authenticate and pay the fee. Anything else would earn them an antitrust law suite they wouldn't forget. ... or one could simply replace the bios/UEFI with coreboot[1] and get on with life... albeit, (at least currently) it will severely limit your choice of motherboards (AMD is supporting coreboot, which is why I've chosen AMD ones but it also requires the support of the motherboard makers). [1]: www.coreboot.org Best regards Peter K
Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers
On Sat, Jun 2, 2012 at 3:43 AM, Florian Philipp li...@binarywings.net wrote: Am 02.06.2012 04:26, schrieb William Kenworthy: http://boingboing.net/2012/05/31/lockdown-freeopen-os-maker-p.html and something I had not considered with the whole idea was even bootable cd's and usb keys for rescue will need the same privileges ... [snip] Okay, enough bashing the article. Some technical question: As I understand it, if I want to make a live CD or a distribution, all I'd need to do is to use Fedora's kernel and boot loader? That's not so bad. Or turn off 'secure boot' in the BIOS configuration menu. For Windows 8 certification, a device must _default_ to 'secure boot' being turned on. You're allowed to turn it off, you just can't have programmatic access to turn it off; it has to be done manually. I expect that'll be available in things like motherboards sold directly to end-users. I expect it *won't* be available in whatever the current iteration of Compaq/HP/Packard Hell all-in-one devices is; manufacturers of those devices will still have keys installed to allow debugging and maintenance tools to operate, but their signed tools would only be available to their certified technicians. Does anyone know what crypto hash they're using to sign these things? I imagine it won't be too long (3-4 years, tops) before either the signing key leaks or collision attacks are figured out. -- :wq
Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers
Am 02.06.2012 15:00, schrieb Michael Mol: On Sat, Jun 2, 2012 at 3:43 AM, Florian Philipp li...@binarywings.net wrote: Am 02.06.2012 04:26, schrieb William Kenworthy: http://boingboing.net/2012/05/31/lockdown-freeopen-os-maker-p.html and something I had not considered with the whole idea was even bootable cd's and usb keys for rescue will need the same privileges ... [snip] Okay, enough bashing the article. Some technical question: As I understand it, if I want to make a live CD or a distribution, all I'd need to do is to use Fedora's kernel and boot loader? That's not so bad. Or turn off 'secure boot' in the BIOS configuration menu. For Windows 8 certification, a device must _default_ to 'secure boot' being turned on. You're allowed to turn it off, you just can't have programmatic access to turn it off; it has to be done manually. Yes, that was my point (or part of it). The main issue is usability for the technically not so inclined. For the typical Gentoo user secure boot is not an issue is no more trouble than changing the boot order to boot from CD-ROM. For mainstream distros like Ubuntu or Fedora, it is an issue. But they can afford to spend 99$ *once* to just get a valid key. I expect that'll be available in things like motherboards sold directly to end-users. I expect it *won't* be available in whatever the current iteration of Compaq/HP/Packard Hell all-in-one devices is; manufacturers of those devices will still have keys installed to allow debugging and maintenance tools to operate, but their signed tools would only be available to their certified technicians. As I understand it, having the chance to deactivate it is now mandatory for Windows certification but I could be wrong. Does anyone know what crypto hash they're using to sign these things? I imagine it won't be too long (3-4 years, tops) before either the signing key leaks or collision attacks are figured out. According to [1] it is SHA-256 and RSA-2048. If I understand it correctly, there are means to blacklist compromised keys. That's why Fedora cannot simply share their key but they will share their infrastructure and tools. [1] http://www.uefi.org/learning_center/UEFI_Plugfest_2011Q4_P5_Insyde.pdf Regards, Florian Philipp signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers
On 2012-06-02 15:12, Florian Philipp wrote: According to [1] it is SHA-256 and RSA-2048. If I understand it correctly, there are means to blacklist compromised keys. That's why Just curious, how is a compromised key supposed to be blacklisted? Does the bios contact Microsoft, or is it through some other mean (via OS which means it needs to have some sort of service to check for this blacklist)? Smells like trouble to me... :-/ Best regards Peter K
Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers
On Sat, Jun 2, 2012 at 3:51 PM, pk pete...@coolmail.se wrote: On 2012-06-02 15:12, Florian Philipp wrote: According to [1] it is SHA-256 and RSA-2048. If I understand it correctly, there are means to blacklist compromised keys. That's why Just curious, how is a compromised key supposed to be blacklisted? Does the bios contact Microsoft, or is it through some other mean (via OS which means it needs to have some sort of service to check for this blacklist)? Smells like trouble to me... :-/ I expect the chief mechanism is at the manufacturer's end; blacklisted keys get included on shipment. It's also probable that the OS kernel can tell the UEFI BIOS about new keys to blacklist. I expect that'll be a recurring thing in the Monthly batch of security updates Microsoft puts out. (Makes sense, really; if malware is using a key, blacklist that key.) Someone linked to some absolutely terrible stuff being built into Intel's Ivy Bridge...it's plausible it will be possible to deploy blacklist key updates over the network within a couple years. -- :wq
Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers
On 2012-06-02 22:10, Michael Mol wrote: I expect the chief mechanism is at the manufacturer's end; blacklisted keys get included on shipment. Makes sense. It's also probable that the OS kernel can tell the UEFI BIOS about new keys to blacklist. I expect that'll be a recurring thing in the Monthly batch of security updates Microsoft puts out. (Makes sense, really; if malware is using a key, blacklist that key.) Yes, would expect something like this. Secure boot supposedly prevents unauthorized firmware, operating systems or UEFI drivers at boot time. So if I interpret this correctly it would mean that if I have, say, an old graphics card with an old firmware (vga bios) I can't use it with secure boot. More interestingly, how is an operating system defined? Does it mean only the kernel itself or does it mean a full-blown OS with init and other supporting software? What does that mean to a source based distro? Also, I would assume a legitimate key would be able to sign pretty much any binary so a key that Fedora uses could be used to sign malware for Windows, which then would be blacklisted by Microsoft... and how is malware defined? Anything that would be detrimental to Microsoft? Someone linked to some absolutely terrible stuff being built into Intel's Ivy Bridge...it's plausible it will be possible to deploy You mean: https://en.wikipedia.org/wiki/Intel_insider#Intel_Insider_and_remote-control ? blacklist key updates over the network within a couple years. Well, UEFI already implements remote management: http://www.uefi.org/news/UEFI_Overview.pdf (page 13) ... so implementing an automatic update over the network, preferably via SMM/SMI so that the operating system cannot intervene would be possible already today... and you've lost control of your computer. I'm putting on my tinfoil hat now and I'm going to pretend it's raining... :-/ Best regards Peter K
Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers
On Sat, Jun 2, 2012 at 6:50 PM, pk pete...@coolmail.se wrote: On 2012-06-02 22:10, Michael Mol wrote: [snip] It's also probable that the OS kernel can tell the UEFI BIOS about new keys to blacklist. I expect that'll be a recurring thing in the Monthly batch of security updates Microsoft puts out. (Makes sense, really; if malware is using a key, blacklist that key.) Yes, would expect something like this. Secure boot supposedly prevents unauthorized firmware, operating systems or UEFI drivers at boot time. So if I interpret this correctly it would mean that if I have, say, an old graphics card with an old firmware (vga bios) I can't use it with secure boot. It's probable that a system using an IOMMU and virtualization tech could emulate the real-mode requirements needed to execute that VGA BIOS safely. Gets more interesting...my understanding of things like Firewire is that it's almost trivially easy to crack a system on the bus, because of the way DMA is implemented. More interestingly, how is an operating system defined? Does it mean only the kernel itself or does it mean a full-blown OS with init and other supporting software? The BIOS will only load a signed bootloader. The signed bootloader will only load a signed kernel. The signed kernel will...do whatever you tell it to do. What does that mean to a source based distro? It's going to make building and installing grub and the kernel trickier; you'll have to get them signed. And that's going to be a PITA for anyone who does developers. What it *really* means is that someone who wants to run Linux as a hobbyist or developer is going to disable SecureBoot, and then fall back to business as usual. Also, I would assume a legitimate key would be able to sign pretty much any binary so a key that Fedora uses could be used to sign malware for Windows, which then would be blacklisted by Microsoft... If Fedora allows their key to sign crap, then their key will get revoked. What I hope (I don't know) is whether or not the signing system involved allows chaining. i.e., with SSL, I can generate my own key, get it signed by a CA, and then bundle the CA's public key and my public key when I go on to sign _another_ key. So, could I generate a key, have Fedora sign it, and then use my key to sign my binaries? If my key is used to do malicious things, Fedora's off the hook, and it's only my key which gets revoked. and how is malware defined? Anything that would be detrimental to Microsoft? Dunno. I imagine it comes down to whatever the chief key's owner doesn't want running on the same hardware while SecureBoot is enabled. Rootkits come to mind. Someone linked to some absolutely terrible stuff being built into Intel's Ivy Bridge...it's plausible it will be possible to deploy You mean: https://en.wikipedia.org/wiki/Intel_insider#Intel_Insider_and_remote-control ? The vPro stuff relates, yeah. blacklist key updates over the network within a couple years. Well, UEFI already implements remote management: http://www.uefi.org/news/UEFI_Overview.pdf (page 13) ... so implementing an automatic update over the network, preferably via SMM/SMI so that the operating system cannot intervene would be possible already today... and you've lost control of your computer. You still own your network, so you have at least some control over it. These features are intended to be managed by the system network administrator. This is going to be a matter of caveat emptor. Don't buy a Tivo or Kindle and expect to be able to repurpose it. (And don't buy hardware from Oracle, I expect. Though I suspect you may eventually not get a choice is you want to run their software.) If you don't know whether or not you can expect to reformat a device before you buy it, then you haven't been paying attention to mobile tech over the last five years, and you didn't do your homework. Apologies for the lack of sympathy. :( -- :wq
Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers
Am 03.06.2012 01:36, schrieb Michael Mol: On Sat, Jun 2, 2012 at 6:50 PM, pk pete...@coolmail.se wrote: On 2012-06-02 22:10, Michael Mol wrote: [snip] [...] The BIOS will only load a signed bootloader. The signed bootloader will only load a signed kernel. The signed kernel will...do whatever you tell it to do. According to Matthew's blog post, Fedora patched Grub2 and the kernel to avoid loading custom code into them: - Deactivate grub2 plugins - Sign all kernel modules and disallow unsigned ones - Prevent access to PCI through userland - Sanitize the kernel command line What does that mean to a source based distro? It's going to make building and installing grub and the kernel trickier; you'll have to get them signed. And that's going to be a PITA for anyone who does developers. What it *really* means is that someone who wants to run Linux as a hobbyist or developer is going to disable SecureBoot, and then fall back to business as usual. Yeah, the only way for Gentoo to have secure boot is a) let each user register with Microsoft, b) provide a binary kernel and boot loader. Also, I would assume a legitimate key would be able to sign pretty much any binary so a key that Fedora uses could be used to sign malware for Windows, which then would be blacklisted by Microsoft... If Fedora allows their key to sign crap, then their key will get revoked. What I hope (I don't know) is whether or not the signing system involved allows chaining. i.e., with SSL, I can generate my own key, get it signed by a CA, and then bundle the CA's public key and my public key when I go on to sign _another_ key. So, could I generate a key, have Fedora sign it, and then use my key to sign my binaries? If my key is used to do malicious things, Fedora's off the hook, and it's only my key which gets revoked. Consider the exact approach Fedora takes: They've only made a certified stage-1 boot loader. This boot loader then loads grub2 (signed with a custom Fedora key, nothing chained back to MS) which then loads a custom-signed kernel. This allows them to avoid authenticating against MS every time they update grub or the kernel. This means if you want to certify with Fedora, you don't need to chain up to MS as long as you use their stage-1 boot loader. However, if I was part of Fedora, I wouldn't risk my key by signing other people's stuff. Mainboard makers won't look twice when they see rootkits with Fedora boot loaders. and how is malware defined? Anything that would be detrimental to Microsoft? Dunno. I imagine it comes down to whatever the chief key's owner doesn't want running on the same hardware while SecureBoot is enabled. Rootkits come to mind. To quote Matthew: If I take a signed Linux bootloader and then use it to boot something that looks like an unsigned Linux kernel, I've instead potentially just booted a piece of malware. And if that malware can attack Windows then the signed Linux bootloader is no longer just a signed Linux bootloader, it's a signed Windows malware launcher and that's the kind of thing that results in that bootloader being added to the list of blacklisted binaries and suddenly your signed Linux bootloader isn't even a signed Linux bootloader. Regards, Florian Philipp signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers
On Sat, Jun 2, 2012 at 8:35 PM, Florian Philipp li...@binarywings.net wrote: Am 03.06.2012 01:36, schrieb Michael Mol: On Sat, Jun 2, 2012 at 6:50 PM, pk pete...@coolmail.se wrote: On 2012-06-02 22:10, Michael Mol wrote: [snip] [...] The BIOS will only load a signed bootloader. The signed bootloader will only load a signed kernel. The signed kernel will...do whatever you tell it to do. According to Matthew's blog post, Fedora patched Grub2 and the kernel to avoid loading custom code into them: - Deactivate grub2 plugins - Sign all kernel modules and disallow unsigned ones - Prevent access to PCI through userland - Sanitize the kernel command line Yeah, I read his blog post via lwn.net. I forgot some of the details. What does that mean to a source based distro? It's going to make building and installing grub and the kernel trickier; you'll have to get them signed. And that's going to be a PITA for anyone who does developers. What it *really* means is that someone who wants to run Linux as a hobbyist or developer is going to disable SecureBoot, and then fall back to business as usual. Yeah, the only way for Gentoo to have secure boot is a) let each user register with Microsoft, b) provide a binary kernel and boot loader. If you have a need to get a secure Gentoo boot, and you don't need to boot Windows 8, then (as I understand it) you can also purge the UEFI BIOS of Microsoft's key and install your own. Also, I would assume a legitimate key would be able to sign pretty much any binary so a key that Fedora uses could be used to sign malware for Windows, which then would be blacklisted by Microsoft... If Fedora allows their key to sign crap, then their key will get revoked. What I hope (I don't know) is whether or not the signing system involved allows chaining. i.e., with SSL, I can generate my own key, get it signed by a CA, and then bundle the CA's public key and my public key when I go on to sign _another_ key. So, could I generate a key, have Fedora sign it, and then use my key to sign my binaries? If my key is used to do malicious things, Fedora's off the hook, and it's only my key which gets revoked. Consider the exact approach Fedora takes: They've only made a certified stage-1 boot loader. This boot loader then loads grub2 (signed with a custom Fedora key, nothing chained back to MS) which then loads a custom-signed kernel. This allows them to avoid authenticating against MS every time they update grub or the kernel. This means if you want to certify with Fedora, you don't need to chain up to MS as long as you use their stage-1 boot loader. However, if I was part of Fedora, I wouldn't risk my key by signing other people's stuff. Mainboard makers won't look twice when they see rootkits with Fedora boot loaders. Yeah, that's not the kind of thing I was thinking about. With SSL's PKI, someone like StartSSL has a CA cert. I generate my own key, have StartSSL sign my key. My brother generates a key, and I sign his. Now my brother takes his key and sends you a signed email. Now, you've never heard of me, and the crypto signature attached to that email doesn't mean anything. However, if he bundles my public key along with his public key in that email, then you can see that my public key was signed by someone you _do_ know. Now you have a chain of signatures showing the relationship between that email and the root CA. Now here's the interesting part, and what I was alluding to wrt signed binaries and key revocation. Let's say _my_ key is leaked. My brother send you an email signed with his key. You look at that key, you see that key hasn't been revoked. You look at the key that signed that key, and you see that _that_ key _has_ been revoked. You can then choose to not trust keys signed by that key. Now let's say my _brother's_ key is leaked, and so he revokes it. Any new emails signed with that key can be seen to be invalid. However, _my_ key is still considered valid; I can still sign things with it. That's the kind of thing I was thinking about. If you allow key chains to be deep, rather than forcing them to be wide, you can wield blacklists like a scalpel, rather than a bludgeon. and how is malware defined? Anything that would be detrimental to Microsoft? Dunno. I imagine it comes down to whatever the chief key's owner doesn't want running on the same hardware while SecureBoot is enabled. Rootkits come to mind. To quote Matthew: If I take a signed Linux bootloader and then use it to boot something that looks like an unsigned Linux kernel, I've instead potentially just booted a piece of malware. And if that malware can attack Windows then the signed Linux bootloader is no longer just a signed Linux bootloader, it's a signed Windows malware launcher and that's the kind of thing that results in that bootloader being added to the list of blacklisted binaries and suddenly your signed Linux bootloader isn't even a
Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers
From: Michael Mol mike...@gmail.com On Sat, Jun 2, 2012 at 8:35 PM, Florian Philipp li...@binarywings.net wrote: Am 03.06.2012 01:36, schrieb Michael Mol: On Sat, Jun 2, 2012 at 6:50 PM, pk pete...@coolmail.se wrote: On 2012-06-02 22:10, Michael Mol wrote: [snip] [...] The BIOS will only load a signed bootloader. The signed bootloader will only load a signed kernel. The signed kernel will...do whatever you tell it to do. According to Matthew's blog post, Fedora patched Grub2 and the kernel to avoid loading custom code into them: - Deactivate grub2 plugins - Sign all kernel modules and disallow unsigned ones - Prevent access to PCI through userland - Sanitize the kernel command line Yeah, I read his blog post via lwn.net. I forgot some of the details. What does that mean to a source based distro? It's going to make building and installing grub and the kernel trickier; you'll have to get them signed. And that's going to be a PITA for anyone who does developers. What it *really* means is that someone who wants to run Linux as a hobbyist or developer is going to disable SecureBoot, and then fall back to business as usual. Yeah, the only way for Gentoo to have secure boot is a) let each user register with Microsoft, b) provide a binary kernel and boot loader. If you have a need to get a secure Gentoo boot, and you don't need to boot Windows 8, then (as I understand it) you can also purge the UEFI BIOS of Microsoft's key and install your own. well, on x86 for now... Also, I would assume a legitimate key would be able to sign pretty much any binary so a key that Fedora uses could be used to sign malware for Windows, which then would be blacklisted by Microsoft... If Fedora allows their key to sign crap, then their key will get revoked. What I hope (I don't know) is whether or not the signing system involved allows chaining. i.e., with SSL, I can generate my own key, get it signed by a CA, and then bundle the CA's public key and my public key when I go on to sign _another_ key. So, could I generate a key, have Fedora sign it, and then use my key to sign my binaries? If my key is used to do malicious things, Fedora's off the hook, and it's only my key which gets revoked. Consider the exact approach Fedora takes: They've only made a certified stage-1 boot loader. This boot loader then loads grub2 (signed with a custom Fedora key, nothing chained back to MS) which then loads a custom-signed kernel. This allows them to avoid authenticating against MS every time they update grub or the kernel. This means if you want to certify with Fedora, you don't need to chain up to MS as long as you use their stage-1 boot loader. However, if I was part of Fedora, I wouldn't risk my key by signing other people's stuff. Mainboard makers won't look twice when they see rootkits with Fedora boot loaders. Yeah, that's not the kind of thing I was thinking about. With SSL's PKI, someone like StartSSL has a CA cert. I generate my own key, have StartSSL sign my key. My brother generates a key, and I sign his. Now my brother takes his key and sends you a signed email. Now, you've never heard of me, and the crypto signature attached to that email doesn't mean anything. However, if he bundles my public key along with his public key in that email, then you can see that my public key was signed by someone you _do_ know. Now you have a chain of signatures showing the relationship between that email and the root CA. Now here's the interesting part, and what I was alluding to wrt signed binaries and key revocation. Let's say _my_ key is leaked. My brother send you an email signed with his key. You look at that key, you see that key hasn't been revoked. You look at the key that signed that key, and you see that _that_ key _has_ been revoked. You can then choose to not trust keys signed by that key. Now let's say my _brother's_ key is leaked, and so he revokes it. Any new emails signed with that key can be seen to be invalid. However, _my_ key is still considered valid; I can still sign things with it. That's the kind of thing I was thinking about. If you allow key chains to be deep, rather than forcing them to be wide, you can wield blacklists like a scalpel, rather than a bludgeon. In theory that's how key signing systems are suppose to work. In practice, they rarely implement the blacklists as they are (i) hard to maintain, and (ii) hard to distribute in an effective manner. Honestly, I don't expect SecureBoot to last very long. Either MS and the OEMs will be forced to always allow users to disable it, or they'll be simply drop it - kind of like they did with TPM requirements that were talked about 10 years back and never came to fruition. and how is malware defined? Anything that would be detrimental to Microsoft? Dunno. I imagine it
Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers
On Sat, Jun 2, 2012 at 10:04 PM, BRM bm_witn...@yahoo.com wrote: From: Michael Mol mike...@gmail.com [snip] In theory that's how key signing systems are suppose to work. In practice, they rarely implement the blacklists as they are (i) hard to maintain, and (ii) hard to distribute in an effective manner. Indeed. While Firefox, Chromium, et al check certificate revocation lists, Microsoft doesn't; they distribute them as part of Windows Update. Honestly, I don't expect SecureBoot to last very long. Either MS and the OEMs will be forced to always allow users to disable it, or they'll be simply drop it - kind of like they did with TPM requirements that were talked about 10 years back and never came to fruition. TPM is still around for organizations which can use them. And, honestly, I've been annoyed that they haven't been widespread, nor easy to pick up in the aftermarket. (They come with a random number generator...just about any HRNG is going to be better than none.) I see something like SecureBoot as being useful in corporate and military security contexts. I don't see it lasting in SOHO environments. [snip] What kind of signature is the bootloader checking, anyway? Regardless of the check, it'll never be sufficient. Sure; ultimately, all DRM solutions get cracked. -- :wq
[gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers
http://boingboing.net/2012/05/31/lockdown-freeopen-os-maker-p.html and something I had not considered with the whole idea was even bootable cd's and usb keys for rescue will need the same privileges ... BillK
