Re: [Discuss] UEFI secure boot pre-loader security considered further Re: Fwd: [linux_forensics] Did you see this ? - Linux Foundation Announces Secure Boot Solution ....
The bottom line here is that UEFI will prevent some Linux users from installing Linux, especially in the near future. I suspect that all major distros will be able to install on a UEFI system with very little user interaction. However, we also need to gain some knowledge so that when we do encounter UEFI at installfests, we know what to do. On 11/02/2012 08:59 AM, Bill Ricker wrote: On Thu, Nov 1, 2012 at 4:02 PM, Rich Pieri richard.pi...@gmail.com wrote: This is a lie. Harsh. Not all errors are lies. Sometimes people are just wrong without malice. Writing is an inexact science. Sometimes editing for style destroys accuracy, even with formerly technical people doing it. The statement is closer to the UEFI's (failed) intent than it's (actual) result, but is not phrased thus, so it is false in detail. I didn't read the rest of the article. Your loss. If your point is it only prevents execution of unsigned bootloaders, you are correct. The rest of the article explains that. Since you already knew that, no loss to you perhaps. The intent of course is to prevent installing malware, Hackintosh, Linux, and *BSD. But no one expects it will prevent VMware, IBM, HP, Oracle from shipping ESX RHEL OEL Solaris86 to their commercial server customers. So far I've seen PLANS by top distros and the Foundation to buy a Key from M$. I will be happy when i see evidence they've received the goods. Will MS accept their money, or make some excuse to defend their monopoly? The wrong sentence we should take exception to is Bottomley noted that this pre-bootloader “provides no security enhancements over booting linux with UEFI secure boot turned off,” This does not seem true, since it will require a user acceptance of an unsigned 2nd load, it will provide a bar to programatic reboot to elevate privilege by starting unattended install or installing a malware hypervisor when rebooting with a USB/DVD mounted. I won't call that a lie either, it's just sloppy thinking. Sounds like for SERVERS (that we often want to reboot remotely or automatically) we either need to turn UEFI SecureBoot off in the mobi FLASH UEFI settings OR stick to distros that have their own purchased signatures. Servers mostly use the big three or their derivatives anyway, but Debian still has some % of server share, this may push them to Ubutu's Server spin. -- Jerry Feldman g...@blu.org Boston Linux and Unix PGP key id:3BC1EB90 PGP Key fingerprint: 49E2 C52A FC5A A31F 8D66 C0AF 7CEA 30FC 3BC1 EB90 ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
[Discuss] Getting OS/HW details?
If I wanted to write a script to obtain distro flavor (Ubuntu, CentOS, RH, Mint, BSD, Solaris, etc), major/minor version (5.3, 10.6, etc), hardware brand/make/model, at least for starters, what would be the best way to attack it? This script may or may not assume being run as root. Environment is completely heterogeneous, so while I may be using an OEM system, my officemate might be using a white box system. I think the only assurance might be it be run as /bin/sh so we don't have to worry about shells. We cannot assume /etc/motd, /etc/issue, or anything else exists in its out-of-box state (they could have been replaced with other text). I thought about uname -a, but it does not indicate OS distro nor version. Arch can only assist with 32/64 bit. Thanks for leads and ideas. Scott ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] Getting OS/HW details?
On Fri, Nov 2, 2012 at 1:09 PM, Scott Ehrlich srehrl...@gmail.com wrote: If I wanted to write a script to obtain distro flavor (Ubuntu, CentOS, RH, Mint, BSD, Solaris, etc), major/minor version (5.3, 10.6, etc), hardware brand/make/model, at least for starters, what would be the best way to attack it? For systems that support the Linux Standard Base (LSB), the /etc/lsb-release file and lsb_release command are good ways to get OS information. For hardware, if you are running as root and it is installed; the dmidecode command is a good start. Good Luck, Bill Bogstad ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] Getting OS/HW details?
I'd take a look at the perl script memconf and see how it works. Even though it was written for Solaris, it does a decent job on Linux. It does like to be run as root, however. http://www.4schmidts.com/unix.html There is a package lshw on Fedora (among others) you could look at the source. decode-dimms, a perl script in lm-sensors, is another good source. It also wants to be run as root, and requires eeprom to be loaded. Jerry Natowitz ===j.natowitz (at) gmail.com On 11/02/12 13:09, Scott Ehrlich wrote: If I wanted to write a script to obtain distro flavor (Ubuntu, CentOS, RH, Mint, BSD, Solaris, etc), major/minor version (5.3, 10.6, etc), hardware brand/make/model, at least for starters, what would be the best way to attack it? This script may or may not assume being run as root. Environment is completely heterogeneous, so while I may be using an OEM system, my officemate might be using a white box system. I think the only assurance might be it be run as /bin/sh so we don't have to worry about shells. We cannot assume /etc/motd, /etc/issue, or anything else exists in its out-of-box state (they could have been replaced with other text). I thought about uname -a, but it does not indicate OS distro nor version. Arch can only assist with 32/64 bit. Thanks for leads and ideas. Scott ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] UEFI secure boot pre-loader security considered further Re: Fwd: [linux_forensics] Did you see this ? - Linux Foundation Announces Secure Boot Solution ....
On Fri, 02 Nov 2012 10:17:21 -0400 Jerry Feldman g...@blu.org wrote: The bottom line here is that UEFI will prevent some Linux users from installing Linux, especially in the near future. I suspect that all No, it will not. Anyone who tells you otherwise is either lying or has bought into the anti-Microsoft propaganda. There is no truth to the claim that UEFI Secure Boot will lock users out of running the OS of their choice. If you buy x86 hardware with the Windows 8 sticker then it MUST be possible to disable UEFI Secure Boot. Microsoft will not allow the manufacturer to ship the hardware with Windows 8 otherwise. I keep hearing about how manufacturers will forget to include the option. No, they won't forget, or they'll correct it with a hotfix, because if they forget and don't fix then Microsoft will pull their Windows 8 certifications and the OEMs don't get to ship Windows 8 until they undergo the certification process again. If you buy x86 hardware without the Windows 8 sticker then it won't have UEFI Secure Boot enabled or it will be a switch for specific operating systems that have signed boot loaders. In none of these cases does UEFI Secure Boot prevent the installation and operation of the OS of your choice. In the case of ARM hardware that ships with Windows 8, which is Windows Phone and Surface/RT, you can't run Linux on any of it anyway due to lack of hardware support. UEFI Secure Boot has nothing to do with that. major distros will be able to install on a UEFI system with very little user interaction. However, we also need to gain some knowledge so that when we do encounter UEFI at installfests, we know what to do. I am writing this right now on a Dell (Alienware) notebook running Windows 7. The system firmware has UEFI Secure Boot which Windows 7 does not recognize. I use a Clonezilla live USB image to perform backups with this firmware on the system. I sometimes try out new Linux live CD spins on it. None of these recognize or support UEFI Secure Boot and none of them are blocked by it. Why? Because it's turned off. You shut it off in the EFI configuration screen. That's it. Press whatever key sequence during POST, shuffle over to the appropriate settings tab, and set it to OFF. Save and reboot. Do the same thing on servers -- although why you'd buy a server with Windows 8 on it is beyond me. The Windows 8 trust chain runs from the firmware all the way up through the kernel going multi-user (maybe further; I'm not sure about that). Each step of the startup process validates the signature on the next step before executing it. Linux has no such trust chain so there's no point to having UEFI Secure Boot enabled on Linux computers. Just turn it off. In the oddball case where you need Secure Boot and you can't use one of the Big Three-provided signed boot loaders then install your own certificates in the UEFI protected storage and use that to sign your otherwise standard boot loader. The example that I'm looking at requires three commands with the Windows 8 SDK (because if you're even looking at this option then you have Windows 8) to generate the certificates and one to sign an EFI executable. Installing the certs from the EFI shell is a simple process: Enroll KEK, Enroll PK. Copy the self-signed EFI loader to the correct place and you're done. -- Rich P. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] Getting OS/HW details?
Noah Friedman friedman aaat splode dawt com maintains a shell script that is basically GNU autoconf's hosttype detection logic, standalone. It doesn't need root, but in some obscure situations may require a C compiler. It is certainly thermonuclear overkill for your situation, but will offer plenty of hints at technique if you really do feel the need to trim it down. ftp://ftp.splode.com/pub/users/friedman/inits/init-7.4.tar.gz contains a copy in init-7.4/bin/hosttype . ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
