To elaborate on option #1 by FSMaxB, I've written a page with (mostly) step-by-step instructions for replacing your Secure Boot keys here. Note, however, that some of the details of what to select in the firmware's own user interface will be system-specific. There are also other ways to accomplish this goal. Adding new keys (as described shortly) will require steps not documented on that page.
This approach works to limit what the computer can boot, but it goes a little too far, in terms of FSMaxB's requirements. Specifically, it not only prevents Windows from booting, but it also prevents most Linux live CDs from booting. I can think of a number of ways to minimize this problem, but some of them are awkward and most of them work only on distributions that are Secure Boot-enabled:
- Add distributions' public keys to the Secure Boot keys in the computer and adjust their boot processes to bypass shim and to boot GRUB or some other boot loader directly. This requires altering files on the live CDs, though, which is a tedious task for technically unsavvy end users.
- Place a copy of rEFInd on the hard disk. This should enable redirecting the boot process to GRUB on a live CD, bypassing its copy of shim. In theory this should work for anything that uses shim, provided that the distribution's key is in the Secure Boot key list you've created.
- Place a copy of rEFInd on the hard disk, launched via the Linux Foundation's PreBootloader. This will enable users to add hashes for any boot loader to the firmware, enabling them to launch any version of Linux, even if its boot loader and kernels are unsigned. This would probably also enable them to boot Windows, too, but at least they'd have to explicitly approve of this action.
- Place a copy of rEFInd on the hard disk, launched via shim. This has no advantage over the basic setup except that it makes it easier for users to add keys (via shim's MOK list). It's conceivable that the presence of shim would help with some boot loaders, though.
- Include in the set of keys you add to the Secure Boot list the public key that's paired with the one that Microsoft uses to sign third-party binaries. Since Microsoft signs its own products with a different key, this will enable the firmware to launch third-party tools, such as Ubuntu 12.10 or Fedora 18, but not to launch Microsoft's own version of Windows. Third-party Windows-based products, though, might be signed with the Microsoft third-party key and so would launch. Note that some plug-in cards have firmware that's signed with this key, too, so this action might be necessary to use such cards' firmware.
As to the suggestion that this is a bad idea, I disagree, provided it's what the machine's owner actually wants. In the days of DOS, it was common for computers to become infected by accidentally booting a floppy disk that contained a boot-sector virus. In principle, the same thing could happen today via a USB flash drive or CD-R. Shutting off that avenue of attack, even if it's not a common one today, is worthwhile. That said, I wouldn't recommend gifting or selling such a computer without making it clear to the recipient what's been done to it and providing instructions on how to undo the changes, if desired.