Slashdot Mirror
Secure Boot Coming To SuSE Linux Servers
darthcamaro writes "UEFI Secure Boot is a problem that only desktop users need to worry about right? Well kinda/sorta/maybe not. SeSE today is releasing SUSE Linux Enterprise 11 SP3 which will include for the first time — support for UEFI Secure Boot. Apparently SUSE sees market demand for Secure Boot on servers too. Quoting Matthias Eckermann, Senior Product Manager at SUSE: 'Our market analysis shows that UEFI Secure Boot is a UEFI extension that does not only cover desktops, but might very well also be deployed and even required on server systems going forward.'"
Secure boot only ensures that you know that what you are booting is signed by someone you trust. It does not provide 'attestation'. If you want attestation, use TPM, possibly combined with secure boot. TPM is not subject to being tricked by hypervisors.
Secure boot does nothing to prevent the end user from being in control, and it does not require anything from Microsoft. If your vendor does not allow you to install your own keys, get a better vendor.
So first you say that Windows Boot doesn't prevent the end user from being in control, then you admit that it puts the vendor in control. Vendor lock-in is the whole point of Windows Boot.
Unless the hardware manufacturer won't let you.
Isn't this argument essentially fear, doubt, and uncertainty?
"His name was James Damore."
Secure Boot isn't secure nor is it a security feature. It's sole purpose is to keep Linux off of x86 computers. It's already easy to get around 'Secure Boot so I think it's broken as a concept. Security has to constantly evolve to meet evolving problems. Hardware can't do that.
+3 interesting? What's wrong with Slashdot that posts with the most misinformation are modded up? And then other people take these modded up posts as gospel and keep repeating the FUD.
Can you tell us how it's easy to get around Secure Boot?
Secure Boot isn't secure nor is it a security feature. It's sole purpose is to keep Linux off of x86 computers
Here's a couple of viruses that Secure Boot prevents.
http://www.chmag.in/article/sep2011/rootkits-are-back-boot-infection
http://www.theregister.co.uk/2010/11/16/tdl_rootkit_does_64_bit_windows/
http://www.computerworld.com/s/article/9217953/Rootkit_infection_requires_Windows_reinstall_says_Microsoft
I recommend reading atleast the first link.
Here's one juicy bit:
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 able to load its kernel-mode driver on systems with an enforced kernel-mode code signing policy (64-bit versions of Microsoft Windows Vista and 7) and perform kernel-mode hooks with kernel-mode patch protection policy enabled.
When the driver is loaded into kernel-mode address space it overwrites the MBR (Master Boot Record) of the disk by sending SRB (SCSI Request Block) packets directly to the miniport device object, then it initializes its hidden file system. The bootkit’s modules are written into the hidden file system from the dropper.
The TDL4 bootkit controls two areas of the hard drive one is the MBR and other is the hidden file system created at the time of malware deployment. When any application reads the MBR, the bootkit changes data and returns the contents of the clean MBR i.e. prior to the infection, and also it takes care of Infected MBR by protecting it from overwriting.
The hidden file system with the malicious components also gets protected by the bootkit. So if any application is making an attempt to read sectors of the hard disk where the hidden file system is stored, It will return zeroed buffer instead of the original data.
The bootkit contains code that performs additional checks to prevent the malware from the cleanup. At every start of the system TDL4 bootkit driver gets loaded and initialized properly by performing tasks as follows: Reads the contents of the boot sector, compares it with the infected image stored in hidden file system, if it finds any difference between these two images it rewrites the infected image to the boot sector. Sets the DriverObject field of the miniport device object to point to the bootkit’s driver object and also hooks the DriverStartIo field of the miniport’s driver object. If kernel debugging is enabled then this TDL4 does not install any of it’s components.
TDL4 Rootkit hooks the ATAPI driver i.e. standard windows miniport drivers like atapi.sys. It keeps Device Object at lowest in the device stack, which makes a lot harder to dump TDL4 files.
All these striking features have made TDL4 most notorious Windows rootkit and it is also very important to mention that the key to its success is the boot sector infection.
Another bit:
The original MBR and driver component are stored in encrypted form using the same encryption. Driver component hooks ATAPI's DriverStartIo routine where
This space for rent.
what you are booting is signed by someone you trust
Or Microsoft.
It complicates use of non-microsoft OSes
And that's the whole reason SecureBoot is getting pushed onto manufacturers.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
As I understand it, the signed redhat bootloader will only boot redhat kernels (which in turn will extend the chain of trust upwards). The generic linux bootloader will boot anything, but will require proof from a person that they acknowledge that it is booting that thing (in order to prevent a "blue pill" type attack).
In this instance, the person with physical control over the system could load an arbitrary kernel, but it is difficult for an attacker to install a hidden rootkit.
There's no place for rational discourse here, whoever posts the most anti-MS screed gets voted up regardless of facts.
I am going to test your theory.
MS Sucks balls, They have since 1978. In fact Gates dropped out because everyone's balls at Harvard were chafed from staying damp with Gates saliva.
Balmer is CEO now, because he even has a ball in his name.
If you look deep in the resources in shell32.dll, there is a string that reads, "insert balls into CD-ROM for a 'Gates job'."
Silence is a state of mime.