James Knott said the following on 10/23/2012 10:26 AM:

BTW, if we want secure computers, we should ban Microsoft products, as they are responsible for most of the vulnerabilities out there.

Its not Microsoft, per se, its an emergent property of the fact that Microsoft is a marketing company not a software development company. When time-to-market and sales volume and market placing/dominance matter, the software quality slips. Conversely, so much of Linux isn't concerned with these matters, but *is* concerned with quality and hence security. Will this change? Possibly. Look at the demands that inadequately tested ("the next release of..") software is included in the next release of, for example, openSuse. Look, for example, at the issues raised in http://www.amazon.ca/Geekonomics-Real-Cost-Insecure-Software/dp/0321477898 <quote src="http://vimeo.com/8100759"> Poorly written, insecure software is no longer a technology issue; it is a public policy issue. Software vulnerabilities leave consumers, businesses, national infrastructures, government and the military susceptible to cyber attacks. The market does not provide significant or compelling incentives for developing secure software, thus current cyber security spending largely deals with the effects of insecure software. In essence, software manufacturers practice unrestrained vulnerability dumping onto downstream market participants. In the absence of policy discouraging this behavior, cyber defenders are too busy mopping the floor to turn off the faucet. This must change. </quote> http://my.safaribooksonline.com/book/technology-management/9780321477897/pra... See also http://www.amazon.com/Deadly-Sins-Software-Security-Programming/dp/007162675... We aren't teaching the mistakes of the past as we are with other engineering disciplines. Part of this is because anyone can call themselves a 'programmer'. Its sort of like 'home renovations', only this is stuff that affects the public. -- I have no faith, very little hope, and as much charity as I can afford. Thomas H. Huxley -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Tue, Oct 23, 2012 at 11:05 AM, Mark Hounschell wrote:

On 10/23/2012 10:52 AM, Greg Freemyer wrote:

...

On Tue, Oct 23, 2012 at 9:43 AM, Tony wrote:

...

With the upcoming UEFI and Secure Boot WIndows 8 etc....

UEFI Secure Boot is scheduled to be incorporated into opensuse 12.3 (Currently due in March 2013). It might be in factory before that if you critically have to have it.

The process is to manually disable Secure Boot in the bios, boot from opensuse CD. It will install a Secure Boot key/extension which will opensuse to boot.

Manually re-enable secure boot. The opensuse kernels should now be recognized and allow boot.

Greg

Does this mean we won't be able to run any kernels other than opensuse kernels?

Mark

Mark, Quick answer (that I expect most kernel hackers to use): The spec calls for x86 PCs to have a bios option to disable UEFI Secure Boot. With that disabled, you can do what you please. Long answer (which assumes Secure Boot is enabled): This is linux. The SUSE team is doing its very best to make sure you are still in control. Fortunately, they are also contributing their solution to openSUSE. Hopefully you know about private and public keys. Private keys are used to sign, public keys to authenticate. (You will not have access to the openSUSE private key, so you won't be able to sign kernels with it.) opensuse is developing an open/extensible solution that will leverage their private key by installing their public key into a Secure Boot key database. If you have a true need to sign your own kernels, then I assume you can get a copy of the extensible Secure Boot module that openSUSE is developing and use it to install your own public key to the secure boot key database. Then you will need to sign your kernels with your private key. I can see large enterprises wanting to implement a policy that only kernels signed by the enterprise can be used. From my understanding , the UEFI Secure Boot process combined with the SUSE extensions would allow that to be done. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 10/24/2012 09:21 AM, Roger Oberholtzer wrote:

On Tue, 2012-10-23 at 12:18 -0400, Greg Freemyer wrote:

...

I can see large enterprises wanting to implement a policy that only kernels signed by the enterprise can be used. From my understanding , the UEFI Secure Boot process combined with the SUSE extensions would allow that to be done. Which would mean I could not run Linux on company hardware. ............................................

- perhaps, if it were possible to load VirtualBox [for M$] on company hardware, then supposedly, it would be possible to run Linux upon that instance of VirtualBox?? .......... best regards Ellan -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It would appear that on Oct 23, Greg Freemyer did say:

On Tue, Oct 23, 2012 at 11:05 AM, Mark Hounschell wrote:

...

Does this mean we won't be able to run any kernels other than opensuse kernels?

Quick answer (that I expect most kernel hackers to use):

The spec calls for x86 PCs to have a bios option to disable UEFI Secure Boot.

With that disabled, you can do what you please.

I do hope that's what happens. But when I googled the secure boot topic about a week ago I got the distinct impression that: while the spec allows for that on x86 PCs, I read something that indicated the spec fell short of actually requiring that the manufacturer actually include the means to do so... The supposed risk was that the manufacturer might be able to build it slightly cheaper if they don't. And that some of them might not see the marketing advantage of playing nice to multi-booters. And it occurs to me that they might rather that more Linux users start need to buy their own *_new_* PC rather than being able to reuse some Windows user's old PC {when it's time for win 8 users to upgrade to the next version} So I got to ask, just how sure are you about that {disable secure boot} option being implemented by ALL manufacturers??? And even if it is, what are the odds that it would require well timed user intervention {similar to pressing some Fkey at the right point in the boot process to enter a bios config utility} each and every time the user wants to boot something that isn't signed by an accepted key??

Long answer (which assumes Secure Boot is enabled):

This is linux. The SUSE team is doing its very best to make sure you are still in control. Fortunately, they are also contributing their solution to openSUSE.

Hopefully you know about private and public keys. Private keys are used to sign, public keys to authenticate. (You will not have access to the openSUSE private key, so you won't be able to sign kernels with it.)

Yeah, Just barely well enough to use gpg to sign or encrypt something... But how this relates to signing kernels is beyond my understanding.

opensuse is developing an open/extensible solution that will leverage their private key by installing their public key into a Secure Boot key database.

If you have a true need to sign your own kernels, then I assume you can get a copy of the extensible Secure Boot module that openSUSE is developing and use it to install your own public key to the secure boot key database. Then you will need to sign your kernels with your private key.

I expect that a true kernel hacker would be up to that. But what about those of us who just like the choice of being able to choose to boot one of the other small distro's now and then?? I'm not ready for a new PC yet anyway. But when I am, I would greatly appreciate it if OpenSuSE's solution would allow me to use OpenSuSE's grub menu to also boot other Linux. including those that haven't the resources to have their own secure boot solution. {Without requiring that I have hacker grade skill levels.} Speaking of other Linux though: Even assuming that I only wanted to multi-boot major distro's that have secure boot strategies in place, will it be possible to have one secure boot loader chainload another with a different secure boot strategy?? (I heard that Ubuntu {for example} isn't even going to use grub2 on UEFI systems due to anticipated legal problems with the GPLv3 license) My preference has for a long time been to keep one manually updated version of grub on a separate grub partition installed to the MBR, And to let each one of several installed Linux install their own automatically managed boot loaders to their own "root" partitions. That way I can easily use my own pet names for the menu choices of the entries I manually update {such as "kid's Linux" for the one with *_only_* rated G wallpapers installed} AND also have generic chainloader entries to use whenever I didn't find the time to update it after a kernel change... I was hoping that I could simply let OpenSuSE install it's bootloader to whatever passes for the MBR on an UEFI system. And them learn how to use the stuff in /etc/grub.d to get customized menuentry to be listed before the automatically generated ones... But I doubt it will be that easy. ############################################################# ##_if_you'd_prefer_an_clearsigned_".asc"_text_file_of_this_## ##message_as_an_mime_encoded_attachment,just_ask_me_while__## ##it's_STILL_IN_my_outbox_folder_._._._=+=+=+=+=+=+=+=+;-)_## #gpg sig for: Joe (theWordy) Philbrook DSA key ID 0x6C2163DE# # You can find my public gpg key at http://pgpkeys.mit.edu/ # ############################################################# -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlCIB2sACgkQRZ/61mwhY95z6gCfT9RB28CA8II1ZCCLFV1ERwyj S1wAoLxtBVWmC0X/Xek5UYpHyVfasgZy =C9Vx -----END PGP SIGNATURE----- -- | ~^~ ~^~ | <?> <?> Joe (theWordy) Philbrook | ^ J(tWdy)P | \___/ <> -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Wed, Oct 24, 2012 at 4:39 PM, Greg Freemyer wrote:

The SUSE Secure Boot extension module is itself extensible. It creates a small database to securely hold private keys. There is in turn a mechanism provided to update that private key database. Red Hat has already said they like the sounds of that and will likely use the same solution. (After all the SUSE module code is opensource (I assume) so they can add it to their own boot CDs etc..)

I very much meant "public" keys in the above. The keys themselves are public, but you as the hardware owner will have to approve keys being added to public key database and therefore ensure you are only adding public keys for entities you trust. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

C wrote:

On Tue, Oct 23, 2012 at 4:52 PM, Greg Freemyer wrote:

...

On Tue, Oct 23, 2012 at 9:43 AM, Tony wrote:

...

With the upcoming UEFI and Secure Boot WIndows 8 etc....

UEFI Secure Boot is scheduled to be incorporated into opensuse 12.3 (Currently due in March 2013). It might be in factory before that if you critically have to have it.

The process is to manually disable Secure Boot in the bios, boot from opensuse CD. It will install a Secure Boot key/extension which will opensuse to boot.

Manually re-enable secure boot. The opensuse kernels should now be recognized and allow boot.

It might be worth noting that new motherboards are already being shipped with UEFI instead of BIOS. My current computer is UEFI, but without any SecureBoot options. openSUSE 12.2 installs fine on UEFI systems (assuming SecureBoot isn't getting in your way) and even plays nice with the UEFI operating system list. OpenSUSE shows up in the UEFI menu system as one of the selectable/bootable OSes. The default installation includes a new partitioning scheme to allow for UEFI requirements if UEFI is detected.... or at least it did some magic on my system when I installed 12.2.

C.

I think grub2 was added to 12.2 at least partially because it supports uefi boot and grub didn't. So it's: 12.2 - add uefi support 12.3 - add uefi secure boot support Fyi: Newer Apple machines mostly use uefi, so i "assume" 12.2 will work better on them than 12.1. Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

James Knott wrote:

Greg Freemyer wrote:

...

On Tue, Oct 23, 2012 at 9:43 AM, Tony wrote:

...

With the upcoming UEFI and Secure Boot WIndows 8 etc.... UEFI Secure Boot is scheduled to be incorporated into opensuse 12.3 (Currently due in March 2013). It might be in factory before that if you critically have to have it.

The process is to manually disable Secure Boot in the bios, boot from opensuse CD. It will install a Secure Boot key/extension which will opensuse to boot.

Manually re-enable secure boot. The opensuse kernels should now be recognized and allow boot.

Greg

The way I read it earlier, the "fix" would require user intervention at every boot. This would of course be a disaster for servers etc.,

Servers are rarely dual-boot systems, in my experience. -- Per Jessen, Zürich (8.8°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

James Knott wrote:

Per Jessen wrote:

...

...

The way I read it earlier, the "fix" would require user intervention

...

at every boot. This would of course be a disaster for servers etc., Servers are rarely dual-boot systems, in my experience.

I wasn't thinking dual boot. I was thinking servers that can boot up without manual intervention. For example if the server is on UPS and the power fails long enough for the UPS to shut down the server, at some point the power will be restored and the server should be able to boot up into full operation, without someone sitting at a keyboard to get past secure boot.

So why not just disable it? Any decent server would surely support that. -- Per Jessen, Zürich (10.0°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

James Knott wrote:

Per Jessen wrote:

...

So why not just disable it? Any decent server would surely support that.

Assuming Microsoft hasn't "encouraged" the manufacturer to remove that option.

Very true, but my imagination doesn't quite stretch to thinking IBM, HP or Dell would agree to that. Supermicro? Nah. -- Per Jessen, Zürich (10.2°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R. wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

On 2012-10-25 14:54, Per Jessen wrote:

...

So why not just disable it? Any decent server would surely support that.

The owner or boss may insist on having it enabled (both real reasons and bogus reasons).

Sure, pointed haired bosses rule the world, but anyone worth his or her salt will know how to deal with those. :-) /Per -- Per Jessen, Zürich (2.7°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Per Jessen wrote:

Servers are rarely dual-boot systems, in my experience.

Mine are, in case of OS problems and to help with failed disk or CPU recovery etc. But that's just my idiosyncratic setup. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Per Jessen wrote:

Dave Howorth wrote:

...

Per Jessen wrote:

...

Servers are rarely dual-boot systems, in my experience. Mine are, in case of OS problems and to help with failed disk or CPU recovery etc. But that's just my idiosyncratic setup.

But would you have Windows8 as a recovery system ? :-)

http://images1.wikia.nocookie.net/__cb20070831020749/uncyclopedia/images/a/a... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org