Windows 8.1: Not Using Secure Boot? Don't Worry We'll Let You Know
tom-pryor.co.uk
tom-pryor.co.uk
I think I found that method.
Run `gpedit.msc`. Navigate to:
Computer Policy > Administrative Templates > Windows Components > Bitlocker Drive Encryption > Operating System Drives
Allow Secure Boot for integrity validation
Use enhanced Boot Configuration Data validation profile
Why wouldn't you just put bitlocker, anti-virus, secure boot, UAC, ...etc under one menu called 'Comp. Security'.
Your suggestion is akin to putting every RHEL/SLED/Ubuntu security setting into one flat configuration file. IPSec, Sudo (and gksudo and friends), anti-virus, cryptfs, apparmor / selinux, ufw / iptables, package signing requirements (including repositories to use), etc.
Something like that would never happen even if Red Hat did control all of the pieces of the puzzle. Now contrast Linux versus Windows here: if you want to configure those things you have to discover the tools or file formats for each security layer configuration manually, versus going into "gpedit.msc" and having categorized settings for the whole OS.
Still makes no sense.
BitLocker, although it can be used to encrypt external/data volumes, is primarily a technology for encrypting the boot volume and then storing the encryption key in the TPM chip. That encryption key can itself be encrypted using some combination of a passphrase, a biometric signature, and a smart card, which must be presented at startup.
In the TPM chip, along with the boot-volume encryption key, there is stored a manifest of SHA signatures for important OS files (specifically, the kernel and drivers required to bring up policy-based security like ACLs and domain authentication.) This manifest is signed by that same encryption key. Thus, the bootstrap loader, having retrieved the credentials necessary to make use of the TPM, can then verify the manifest with the key, and then use the manifest to verify that the OS it's going to boot into can be trusted, and will continue to protect the security of the files stored on the drive when control is passed to it.
This whole setup basically means that there's no way to get data off a BitLocker+Secure Boot computer without it allowing it (or, in limited cases, doing tricks with sticking RAM chips in liquid nitrogen.) If you didn't have BitLocker, you could just read the data "at rest"; if you didn't have Secure Boot, you could just install a rootkit and grab the data "in motion."
---
[1] Really, I think the only reason the two technologies (BitLocker and Secure Boot) ended up with different names is that they were supposed to be two subfeatures of one initiative -- Microsoft Palladium or http://en.wikipedia.org/wiki/Next-Generation_Secure_Computin... -- but that initiative was shelved (likely due to the huge public backlash), leaving just these few practical remnants behind. (It's pretty obvious that the BitLocker Settings panel was originally the Palladium Settings panel; it's where you go to reset TPM keys et al.)
MS hides things in GPO or registry settings when it wants to alleviate the concerns of network administrators while still managing to infuriate the end users who have no business touching 'their' operating system.
And that's, of course, absolutely intuitive.
In the most user-hostile move ever, I wanted to disable the "automatic restart in 15 minutes" thing on Windows 8 (Home). It required adding a registry key(!) I hope there's an easier way that I just somehow missed...
Really, really, horrible experience.
During the beta phase, they had mentioned that updates wouldn't do that, that they would auto apply the next time you rebooted.
I really think that all they should do is display a message that says, "New security updates have been installed. To ensure your computer is secure, please reboot your computer."
Not that I'm apologizing it's behavior - it was a design decision that Windows team made in the past, when it was deemed not important and worth reduction in complexity. Now just it comes and bites them back.
You can perform hot updates to a system but it can be complex and there are a number of restrictions on the types of updates that can be done.
Not exactly. Its up to the application which opens files to control whether the file can be modified externally. It can do this in two ways. (1) Open the file in some FILE_SHARE_* mode and let the OS sort it out. (2) use opportunistic locks that will detect external access and then let the app decide how to react - anti-virus programs use this when they are scanning files.
>That's the cause of most reboots, it will replace them before services or apps that use them start again.
Actually the cause for reboots is much more mundane. Files replaced on disks means new programs using those files get the new version, however, processes which are already running keep using the older version in memory and are thus open to being exploited by bugs that are already patched.
On servers, things are a bit different. To prevent downtime you can 'hotpatch' the update and thus avoid the reboot.
The problem Microsoft is balancing against is people who never ever reboot their computers no matter what--and thus never update, and become infection vectors. They have to force these people to update against their will to ensure the digital equivalent of herd immunity. And it's really quite hard to tell whether the user trying to "permanently" dismiss the "REBOOT NOW GOSH DARNIT" popup really has something urgent they're doing, or is just a "power user" who thinks they know better than the computer.
This is really frustrating.
But of course the option to disable secure boot was grayed out, and it took me some searching on the Internet to find a solution: first you have to go to the key management window, and delete all the keys there. Then you're allowed to turn off secure boot.
If they wanted it to be usable, they'd just offer me an option 'boot once without secure boot' (and ask for the BIOS/EFI administrator password if set).
After this experience, my hypothesis is that the main purpose of "secure boot" is to discourage the user from installing anything non-default (aka Linux).
In particular, the bit about wanting to dual-boot WP8 on Android phones: https://news.ycombinator.com/item?id=6497126
(First link I found)
Because an important security feature (in their eyes, DUH) is disabled.
> If a message is needed, at all, then why not display it on the System “View Basic Information about your computer” control panel item.
lol.
That's a dark pattern itself, hiding important settings in places where users can't see it.
And the douchey part is that Microsoft doesn't even acknowledge issues such as the unsigned option ROM thing.
Microsoft used an existing UEFI feature to guard against attacks even when your Admin account is compromised. I consider it to be a good thing. I'd want as many clueless people to enable secure boot as possible.
The only time the messaging is useful is when someone has unintentionally disabled secure boot. In this case they can go enable it again (or bring it to geek squad, etc).
If the user intentionally disabled it, then the it should be possible to suppress any warning messages about it.
If malicious software somehow disabled it, it can probably also make the registry settings tweaks required to hide the messaging so the user won't know anyway.
I don't know the answer to that question, but if I was a malware writer, disabling that warning would be the very first thing I would do.
In any case the most likely group of people who will see this message are people who know what they are doing. Off the shelf Windows 8 certified computers will have secure boot as default therefore the message won't be displayed. People who are likely to see this message are:
- Those who manually disabled secure boot
- Those who purchased components individually and built their PC as most individually purchased motherboards come with secure boot in setup mode (disabled).
I'd say people in those two groups are highly likely to know what secure boot is and don't need a reminder about it.
Also, let's say your average user somehow sees this message. They are not going to be able to solve the problem themselves. They've most likely never heard of secure boot let alone know how to enter the BIOS and enable it.
Um.. Okay, Name 5?
>I'd say people in those two groups are highly likely to know what secure boot is and don't need a reminder about it.
>Also, let's say your average user somehow sees this message. They are not going to be able to solve the problem themselves. They've most likely never heard of secure boot let alone know how to enter the BIOS and enable it.
Okay, good, your arguments are valid - BUT - only if your premises is valid. I see - "likely" , "most likely" , "highly likely". How have you established this to be the case?
All those help prevent a situation where the boot up sequence is somehow compromised. Whereas secure boot is only reactive - it won't do anything to prevent the malicious software from installing itself in the first place.
Also, no, I have not gone out and done a survey to find out how many people understand secure boot. However, if you just use common sense and apply your experiences with interacting with an average user (might be your parents, co-workers, relatives, friends, etc.) then how likely do you think the majority of average users will have even heard of secure boot? I'd be willing to bet money on the answer to that.
DEP is already on by default, so is UAC. Updates not being installed shows up as a warning on the Win 8 login screen. Next, Win 8 AFAIK creates a non-admin account by default, so if you are logged in as admin, you have jumped through some hoops to create one. And there is some kind of "action center" warning on not having an anti-virus installed.
Remember, secure boot needs to be enabled outside the OS. If the OS could enable it by default, it already would have been enabled. It could be that the user has knowingly disabled it. The OS has no way of knowing the intent of the user, hence the warning. Assuming the worst-case scenario in security matters is nothing new.
>All those help prevent a situation where the boot up sequence is somehow compromised
DEP primarily prevents "fishing" expeditions for remote-attack scenarios where the attacker blows through the stack, writes to some random region in memory and attempt to execute code from there. DEP defaults to pages being either executable or writable but not both. UAC has nothing to do with the bootup sequence, nor has anything else you mentioned.
> Whereas secure boot is only reactive - it won't do anything to prevent the malicious software from installing itself in the first place.
Nothing can prevent an user from running executable code he wants to run. Secureboot implements a method to counter an Admin account compromise. It is not needed if the user is running as a non-admin.
Yes, all of those have nothing to do directly with the boot sequence. But again, that is not the point. They all help prevent the malware from executing or gaining hold in the first place, before it has the chance to compromise the boot sequence. Secure boot does nothing to stop the malware in the first instance, just prevents it from messing with anything at boot. In my view, I'd say that actively defending from the malware is far better than reacting after the event to limit the impact. I'm not saying secure boot is not helpful but rather the current level of notification you get when it is disabled is disproportionate.
All those settings are controlled from inside the OS. The OS can track whether the user has intentionally changed them. Secure boot has to be enabled outside the OS. In which case the OS has no way of knowing whether the user has intentionally disabled it. Assuming the worst-case scenario can be a good thing when it comes to security.
Personally, unless I can get it to work with CentOS, I wont be using Secure Boot since I ship products on Linux. However, I don't think the warning is disproportionate.
In this case there is a valid use case for not having secure boot enabled, but I can see where Microsoft might not recognize any of them as the 'general case.' Another step in the process of appliancizing computers into application platforms.
[1] At the time federal law stated that no speed limit could be higher than 55 MPH so exceeding 55 was by definition 'speeding' anywhere in the US.
Maybe that's because a prominent reason to disable secure boot is to use Windows Loader to pirate Windows. Of course, there may be an updated version soon that tricks Windows into thinking it booted securely.
The real pirated software is MS Office.
Also there's a reason self assembled laptops aren't a thing, packing all the components in the size of a laptop is a really hard problem.
Instead of fixing this -- and to maintain backward compatibility -- they've always applied security models further up the tree, closer to the apps and the user. As a result MS has more and more complex security controls but is less secure. This complexity and security bloat results from trying to patch a boat that's full of holes in its fundamental design.
Secure boot is needed for the same reason lots of other controls are needed-- to make it harder to permanently screw the system once you've gotten malware onto it. This is so important because it is historically so easy to get malware onto Windows.
Everything. I mean literally everything. Every single sentence.
First of all.. calling NT 'not multi-user' is laughable. Anyone who knows anything about OS design knows that NT was designed from the ground up to be muti-user - with an extremely well thought out token/object security model that was hands down superior to any other general purpose mainstream OS at the time.
Secondly secureboot is not an active security model. It is a one-time validation of a chained-loading sequence from the uefi/bios to the OS kernel. It has nothing to do with "patching holes" in NT. NT is already a highly secure operating system. Infact, there have only been a very small amount of kernel vulnerabilities ever found in NT compared to most other widely used OSs.
Secure boot is also nothing new. They have been using something similar on the xbox 360 for years. In any case, Secure Boot is an OS agnostic general security 'best practice'. Many Linux distributions are also adopting it.
So in the end, worse is better, because it is usable in practice by people with deadlines.
Similarly, in the Linux world, SELinux provides much better security. But then again, very few people know how it works and how to configure it, so even when it is enabled, it relies on policies supplied by OS vendor.
The problem is you're comparing two unequal things and calling it even. Linux clearly has had to deal with several challenges in improving its design due to its UNIX heritage (time-sharing OS, synchronous I/O, blocking syscalls, etc), while NT did not because it was a fresh design.
Frankly this type of discussion is more suited for a comparative analysis type paper than the comments section. Also, FWIW - I don't claim any special expertise or knowledge on OS design, its simply a topic of general interest of mine.
Sorry, then nothing I say will change your mind. It would be a waste of my time.
Oh. I know what a good word for it is: douchey.
It's a nice thought, and not en entirely pointless one. The more population that migrates to alternatives, the better those alternatives become. Of course it's not linear, but right now it's all likely positive gains.
The only point being that all corporations that aspire to Microsoft's market share are no saints either.
In todays world of wonderfully powerful machine, a WindowsXP or Windows7 installation in a seamless Virtualbox machine will solve most Windows-related problems: proprietary apps at work, a photobook creation Windows app or maybe an old game or so. For everything else there's at least one Linux distribution that works.
I install Mint 15 Mate for my retirees and with it they can surf, bank, write e-mail and word process. After installing it I never hear about viruses, trojans or weird popups telling them that something is out of date.
Now if only younger people would have the courage to try something other than Windows for once. Unfortunately you're going to be playin the latest Call of Duty or Madden 2047, but them's the breaks.
For most people, there is also very little reason to make the effort of switching from Windows (or OSX - whichever they're on) to a Linux distro. Do you also think regular people would understand the concept of a VM well?
I think you're getting a little ahead of yourself.
I, today, had a very quick look at installing Libre Office on a Fedora VM. Windows: download exe file, double click, it installs. Now go look up the instruction for Linux. So absurdly, hilariously complicated. I thought of Linux fanbois, and began to laugh, then cry. Right there is one reason Linux has a long, long way to go.
Yeah, fine for geeks and great for running server services, as I have been doing for decades, but as a general desk top for normal human beings? No way. Not even slightly. Sure Windows has its issues, but you know what? It works.
But, I'll give your Mint a go. See if that is as easy as Windows. You never know....
http://www.postgresql.org/download/linux/ubuntu/
It's hard to argue that secure boot, on which your machine comes with keys installed by Microsoft (I don't trust them) and requires the user to know how to a: install another set of keys to run Ubuntu (or b: disable the feature entirely and forsake bootloader signing)... should be blessed
... but that users installing a piece of software as complex as a database server, on a system where packages are cryptographically signed, can't be arsed to follow the instructions on this page provided by the vendor, that was the first search result on Google, to install the vendor key and to download vendor packages from the vendor's own PPA repos.