Siduction Forum

Siduction Forum => Ideas & Improvements => Topic started by: titan on 2012/12/04, 17:21:44

Title: Shim and secure boot support
Post by: titan on 2012/12/04, 17:21:44
This looks like it may have possibilities for Debian, no MS approval needed.
www.h-online.com/open/news/item/State-of-Secure-Boot-detailed-1741460.html
Title: Shim and secure boot support
Post by: reddark on 2012/12/04, 17:45:10
German-Info:

http://www.pro-linux.de/news/1/19183/secure-boot-bootloader-fuer-alle-distributionen.html
Title: Re: Shim and secure boot support
Post by: michaa7 on 2012/12/04, 19:46:15
Quote from: "titan"
...no MS approval needed.
...


Quote
He explains that the current approach, a shim bootloader, "cunningly called 'Shim'", contains a public key under their own control and is signed by Microsoft.
Title: Re: Shim and secure boot support
Post by: devil on 2012/12/04, 19:47:37
We will for sure look into this for one of the releases next year. Looks rather straight forward to me.

greetz
devil
Title: Re: Shim and secure boot support
Post by: titan on 2012/12/04, 23:38:39
Quote from: "michaa7"
Quote from: "titan"
...no MS approval needed.
...


Quote
He explains that the current approach, a shim bootloader, "cunningly called 'Shim'", contains a public key under their own control and is signed by Microsoft.


I should have said for continued use after first install for kernel update.

Quote
We didn't want to have to get binaries re-signed every time we updated our bootloader or kernel, so we came up with a compromise approach. We implemented a shim bootloader (cunningly called "Shim") which is signed by Microsoft and includes a copy of a public key that's under our control. Shim will launch any binary signed with either a key installed in the system firmware or the public key built into it. This allows us to build and sign all other binaries ourselves.
Title: RE: Re: Shim and secure boot support
Post by: titan on 2012/12/06, 09:03:39
Just as I thought I was beginning to understand secure boot there is this
 
http://lxer.com/module/newswire/view/177482/index.html  

even Carla Schroder got it wrong.
Title: RE: Re: Shim and secure boot support
Post by: michaa7 on 2012/12/06, 18:05:51
Very interesting side note from Matthew Garrett

Quote
... As of 17:00 EST today, I am officially (rather than merely effectively) no longer employed by Red Hat, and this binary is being provided by me rather than them, so don't ask them questions about it....


Found here, full story, very interesting first hand info:

Secure Boot bootloader for distributions available now
http://mjg59.dreamwidth.org/20303.html

But still I have no clue what happens if MS revokes the key/the signature for shim ?
Answer from MJG:
Quote
Will MS revoke it?
Date: 2012-12-01 03:43 pm (UTC)
From: (Anonymous)
More importantly, can they?
Link Reply Thread
Re: Will MS revoke it?
Date: 2012-12-01 03:54 pm (UTC)
From: mjg59
They can, but unless there's any security issues with it, I have no reason to think that they will.
Title: RE: Re: Shim and secure boot support
Post by: ralul on 2012/12/06, 20:52:44
Can someone in simple words explain the feature of secure boot?
I mean:
- If I am under a thread of espionage I don't want shim going around the secured boot.
- If I am not threatened I turn secure boot off?

I really don't get it the whole fuzz going on ...
Title: RE: Re: Shim and secure boot support
Post by: Bequimão on 2012/12/06, 21:29:30
Or the other way round,
where is the additional security with secure boot on as any live OS with shim is able to boot your computer? The chain of trust is not broken.

Best regards,
Bequimão
Title: Re: RE: Re: Shim and secure boot support
Post by: DeepDayze on 2012/12/07, 04:40:55
Quote from: "Bequimão"
Or the other way round,
where is the additional security with secure boot on as any live OS with shim is able to boot your computer? The chain of trust is not broken.

Best regards,
Bequimão


So if the code for Shim is available what would stop malicious types from creating malicious code and using the key that Shim uses...then the code shim loads would then be deemed trusted. Sounds like the chain is broken
Title: Re: RE: Re: Shim and secure boot support
Post by: michaa7 on 2012/12/07, 11:02:44
If you alter Shim you need to resign it.
Title: Re: RE: Re: Shim and secure boot support
Post by: ralul on 2012/12/07, 13:26:01
Using my broken english, I think I meant the same question as
Bequimão and DeepDayze:

A TPM chip enabled secure boot should give me assurance in for example such a case: I am for example a high business manager travelling to Iran. The iranian intelligence service should not be able to implement a rootkit in a moment of my unawareness, when they have hardware access to my notebook.

If I use Linux:
With shim they woold be able to install their own manipulated Linux kernel on my notebook?

If I use Windows:
They would not be able (but of cause the CIA will have their own keys) ?
Title: Re: RE: Re: Shim and secure boot support
Post by: michaa7 on 2012/12/07, 13:53:18
As Mathew Garret pointet out several times and as you can read in the comments of the above cited page, secure boot is NOT secure, but restricted. It consists in a chain of trust. If you mistrust one link in the chain you disable/revoke their keys.

The whole discussion about "security", whether secure boot is secure is completely misleading. You should google for a discussion where Matthew Garrett explained the difference between secure and restricted.

In future with UEFI systems:
On a pure Linux system you simply may disable secure boot if you feel it is only nagging you. But on dual boot with windows 8 you are stuck with it. The same goes for running windows 8 in a VM. That's a fact.

Very entertaining:
http://www.youtube.com/watch?v=V2aq5M3Q76U
Title: Re: RE: Re: Shim and secure boot support
Post by: ralul on 2012/12/07, 15:24:06
Quote from: "michaa7"
But on dual boot with windows 8 you are stuck with it. The same goes for running windows 8 in a VM. That's a fact.
Aahhh!
This fact I was missing, because I don't use Win. This the reason to have to use shim like workarounds ...