Slashdot Mirror
Ask Slashdot: Establishing Procurement Policies Regarding Secure Boot?
New submitter Firx writes: My university department has a tradition of selling its used computers and/or repurposing them with Linux for graduate students and science computer labs. With Windows no longer requiring one be able to disable secure boot, my department is writing up a procurement policy to ensure future machines we buy will still have this feature. Part of the draft motion reads: "Be it resolved that computers running or intending to run Microsoft Windows purchased by the
department which boot using the Unified Extensible Firmware
Interface (UEFI) have the ability to disable the Secure Boot features for both local hard drive and
network booting." Is there something further we should be including here and what is the best way to explain the need for this policy to colleagues less technically literate?
Require it, for example, to be installable with Linux with the "current version of the stable Debian installer" at the time of purchase. For an individual contract, that version needs to be specified, of course. This way you have at least somebody to blame if it later turns out this does not work.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Is there something further we should be including here
Yes. "Be it resolved that due to the known threat of firmware-based rootkits created and deployed by the US National Security Agency, American vendors are disqualified from consideration during procurement."
what is the best way to explain the need for this policy to colleagues less technically literate?
We bought the computers, we should be able to use them as we see fit.
Linux can UEFI Boot with and without Secure Boot. With Secure Boot you have to be able to install keys or use a Grub Shim, but I have seen both Toshiba and HP Laptops boot Mageia and RedHat in UEFI and CSM modes.
What about Surface Pro tablets? I think that this policy would preclude their purchase (a good idea IMHO), but others may disagree. You probably need to figure this out before it sinks your attempt to bring in a new policy.
The real "Libtards" are the Libertarians!
You are both over-specifying the mechanism, and scope.
Not all computers you can buy to run Windows have UEFI, and some otherwise useful devices can't disable it.
2 examples that would be excluded from purchase by how you have phrased this :
- Macs (do not have UEFI, but an Apple fork of EFI)
- iPads (locked boot loader)
- Many Windows 10 tablets/hybrids/ultrabooks e.g. Surface (locked boot loader)
- Windows Phone (locked boot loader)
- Sony Playstation (sometimes used as GPU clusters, but have a locked boot loader )
Now if you want to ban those other device types , thats really up to you. It depends on do you consider a tablet to be a computer or a phone to be a computer, but heck. Increasingly , the number of computers that function as you describe are going to go down, and more and more locked down devices like tablets and hybrids will become the norm in the market.
Why not frame it in terms of why :
"The department believes that it is essential to generate long term utility from computers it buys, and that they shouldn't simply be disposable. We believe that long term use requires flexibility in the operating system used on a computer. We believe that long term use can be achieved in multiple ways - such as reselling used devices to other entities that have need for them, re-purposing computers for graduate students and laboratories, or converting computers for use in instrumentation. This means that wherever possible, computers should be purchased ensuring they have the capability to be unlocked from only running Windows, and running other operating systems such as Linux. This ensures maximum flexibility for our department in generating value from the money we invest in our IT hardware. Exceptions to this need to present a business case and be approved by XXXX"
The committee approving the exceptions is the mechanism to handle your other options.
Other than pure FUD, why mention Windows or Microsoft at all? We have hundreds of servers running Linux that have Secure Boot enabled, and our requirements for the next gen of servers is that the Secure Boot can not be disabled. So don't pretend it is just a 'Windows' thing.
Dragging MS into it is really childish. A manufacturer that gets a Windows 10 cert has the choice of allowing Secure Boot to be disabled or not. Are you trying to claim that a manufacturer who DOESN'T get an MS certification is somehow prevented from that option?
As mobile devices and desktops eventually share more in common, it's not unlikely that we'll soon see locked bootloaders on PCs, probably starting with netbook like laptops. I would be more general/generic in the terms.
"Be it resolved that devices running pre-installed operating systems purchased by the department must have the ability to boot third-party software from local storage, or network if no local storage exists."
"Be it resolved that computers ... purchased by the department which boot using the Unified Extensible Firmware Interface (UEFI) have the ability to disable the Secure Boot features for both local hard drive and network booting."
I would also explicitly exclude "special purpose" computers that your department may purchase for other purposes (e.g. computers that run security cameras, which you may WANT to be locked-down), provided the individual purchase is approved by a review board. I would also allow the same "escape clause" for equipment purchased by your department using outside, restricted funds where the funding restriction contradicts the policy. Such specific exemptions may already be implicit in your organization's structure. If they are, then you do not need to spell them out explicitly.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
For computers that can be re-purposed or re-sold, the actual residual value after 3 years (or whatever your "time to fully depreciated" is) significantly greater than zero.
For "locked down" computers, the actual residual value becomes a cost - the cost of having it hauled off as e-waste.
In cases where computers must be locked-down (e.g. due to a grant requirement), the "true cost" should be the buy-in cost + the ongoing maintenance cost - the residual cost (or ... + the disposal cost).
By explicitly calling this out in your requisition process, it will make people think twice before applying for grants that require locked-down computers.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
I don't mind Secure UEFI. But, I like the ability to turn it off and run in MBR mode if needed... for example, to boot a MS-DOS drive so I can do a BIOS flash the "right" way. Or run an OS like Solaris that is required by some applications.
Will someone please tell me why an institutional purchaser ---- particularly in a mixed OS environment --- isn't that all new systems support Secure Boot.
Every year at security conferences, more and more people are showing that once something gets into the secure boot area, it won't ever leave. Nearly every bit of anti-malware in the world won't even detect if something is running in the secure area. Being able to disable it is a security feature. Being able to remove or replace it is even better.
Ability to add your own keys, and remove the others.
Hello,
I would suggest the following amendment to your draft text:
Be it resolved that computers running or intending to run Microsoft Windows purchased by the department which boot using the Unified Extensible Firmware Interface (UEFI) have the ability to disable the Secure Boot feature." REMOVING: s for both local hard drive and network booting.
If you want to put in verbiage saying Secure Boot should be disabled, the language should reflect this in its entirety, not just for what types of devices the computer boots from. Example: A manufacturer who disabled booting from SSDs, USB flash drives or optical media would still be in spec with your requirements, since you only specified hard disk drives and PXE booting in your text.
Also, keep in mind your requirement is not going to work with Windows 10 Mobile devices (phones, phablets and the like) as UEFI with Secure Boot enabled is part of the requirements for devices running that edition of Windows 10.
Regards,
Aryeh Goretsky
Dexter is a good dog.
So make sure every box comes with appropriate keys that can be individually passed on when the box is eventually sold or otherwise disposed of. Perhaps a sticker on the side or something. That, or a guarantee (as noted earlier, a tried and tested guarantee!) that all key material can be emptied out and so a "clean" unencumbered box results. Oh, and you have to take care about the (U)EFI storage windows likes to scribble all over. That might need cleaning too.
BIOS compatibility should be ensured, too. I'd suggest as a test Quake for DOS, under latest FreeDOS, in SVGA mode (at least 1024x768). Sound is not mandatory, but still a welcome extra.
Or maybe you honestly haven't a clue what secure boot really does and are letting yourself be blinded by the fancy name. Yes, most if not all new systems come with this thing, but that doesn't mean it is automatically a good thing. And OP is asking how to deal with it.
Secure boot is not, never was, about your security. The malware it is said to protect against has little trouble with this measure. It's about locking you down, but that doesn't make you more secure, just more restricted. Go look it up, see how it works and what that means.
Institutions may or may not care but ending up with old equipment that requires keys that have long since vanished (or otherwise cannot be separated out and passed on with the equipment) is worth a lot less than equipment that can be usefully repurposed, sold on, even given away to the workers or some good cause or other. (Even giving things away is worth something. Goodwill is a thing, go look on a nearby balance sheet. Useless gifts can have negative goodwill value, too.)
We already have various good examples, but I'm going to pick "windows RT" which --contrary to windows 7-- required secure boot to be fully engaged on the tablets it was sold on. Now "RT" has been discontinued and the remaining hardware can neither be upgraded nor repurposed with some aftermarket OS. So your discontinued windows tablet may not quite be a brick, its software is outdated and unpatchable, making it unfixably dangerous. So no, secure boot is not to your advantage. It's a destroyer of value, thus costing you money like when you're forced to buy new.
The main issue with secure boot that you can't get around by updating the secure boot keys, is that you can't use any PCI/PCIe cards which have options roms, that are not signed. ( Also you can't use add in cards with option roms if you remove microsofts keys as that's what they're signed with and you have no way to resign the card firmware.... )
Be it resolved? It's 2016! Who the fuck talks or writes English like that, except lawyers?
How about you make your policies readable and understandable?
I don't understand why the university doesn't simply purchase Linux computers from a major vendor like System76? Save money on costly Microsoft licenses by keeping as many machines as possible running Linux and only install Windows where necessary. If negotiated contracts are a factor, then purchase Linux systems from Dell or HP. They do sell them, you know?!
-==- Buy a Mac and leave me alone!
> what is the best way to explain the need for this policy to colleagues less technically literate?
Secure Boot prevents your boot process from being hijacked. Why would you want to disable that?
With shim and/or preloader and you can Secure Boot any OS that has a UEFI bootloader.
"Windows 10 hardware must support Secure Boot and won't have to let you turn it off." - or that sticker can't be used.
http://arstechnica.com/informa...