Re: Q: secure boot

2018-11-08 Thread Domenico Andreoli



On November 6, 2018 1:14:03 AM UTC, Paul Wise  wrote:
>So, really the only reason to support Secure Boot is to avoid users
>having to turn Secure Boot off in their BIOS and avoid having to
>document how to do that on every firmware implementation that is being
>shipped on new hardware. I think it is definitely worth the effort to
>do this to avoid turning people away to other distros.

I'm booting Debian from an external ssd on a locked down laptop, where I cannot 
disable the secure boot. I had to install the shim of ubuntu.

I would definitively prefer to use the Debian one, the install phase would be 
way easier and I could even decide to install to the internal drive.

thanks,
Domenico



Re: Q: secure boot

2018-11-06 Thread Holger Levsen
On Tue, Nov 06, 2018 at 09:21:32AM -0800, Russ Allbery wrote:
> >> What is non-free?  Signing stuff does not change the freeness of the
> >> software.
> > it does introduce https://en.wikipedia.org/wiki/Tivoisation however.
> I'm not sure how us signing our stuff does that. 

you are right and I was sloppy to express what I meant. Sorry about
this.

> The computer's firmware
> may do this if it enforces secure boot and doesn't provide a way to turn
> it off.

this is what I meant with "it" in the above sentence...

> But only running signed software is a valid and sometimes
> desirable security configuration, which our users may want to choose.
> 
> By default, apt will only install software signed by Debian's archive keys
> and will refuse to install anything else.  We rightfully don't consider
> that to be Tivoisation.  I feel like supporting secure boot is similar.
> 
> By this, I am not trying to defend hardware vendors who lock the owners
> of the hardware out of installing software of their choice, only
> contending that Debian signing its software doesn't create that problem.

agreed.
 
thanks for correcting me!


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature


Re: Q: secure boot

2018-11-06 Thread Russ Allbery
Holger Levsen  writes:
> On Tue, Nov 06, 2018 at 10:08:10AM +0100, Bastian Blank wrote:
>> On Tue, Nov 06, 2018 at 01:09:50AM +0100, Adam Borowski wrote:

>>> But only the stock kernel, which turns it non-free software.

>> What is non-free?  Signing stuff does not change the freeness of the
>> software.

> it does introduce https://en.wikipedia.org/wiki/Tivoisation however.

I'm not sure how us signing our stuff does that.  The computer's firmware
may do this if it enforces secure boot and doesn't provide a way to turn
it off.  But only running signed software is a valid and sometimes
desirable security configuration, which our users may want to choose.

By default, apt will only install software signed by Debian's archive keys
and will refuse to install anything else.  We rightfully don't consider
that to be Tivoisation.  I feel like supporting secure boot is similar.

By this, I am not trying to defend hardware vendors who lock the owners
of the hardware out of installing software of their choice, only
contending that Debian signing its software doesn't create that problem.

One could argue that we should refuse to ever sign anything on the grounds
that it makes it possible to use Debian with hardware that requires
signatures, and we should be boycotting such hardware.  And indeed I
wouldn't be surprised to see an FSF distribution take such a stance.  But
I think that would be incompatible with our project choice to allow our
users to run Debian on non-free hardware and leave that choice up to the
user.  (I also don't think this would be useful from a tactical
standpoint; vendors making such locked-down hardware don't care whether
Debian runs on it.)

-- 
Russ Allbery (r...@debian.org)   



Re: Q: secure boot

2018-11-06 Thread Ansgar Burchardt
On Tue, 2018-11-06 at 09:14 +0800, Paul Wise wrote:
> AFAICT the Debian Secure Boot packages are not designed for the
> scenario where only Debian keys or per-user keys are trusted by the
> firmware, if they were then shim-signed would be named
> shim-signed-microsoft and there would be a shim-signed-debian package
> too.

This was discussed: you can attach multiple signatures to a UEFI binary
such as shim, so all this would need is to add an additional signature.
Maybe also a legacy version with only the MS signature in case some
implementations don't like multiple signatures (it was added in a later
UEFI version as far as I understand).

> In addition, the revocation situation is just ridiculous. There is no
> way to revoke known-insecure (but still validly signed) software from
> every vendor that supports secure boot.

I agree.  You can probably always get something with a valid signature
and a code execution bug running...

Ansgar



Re: Q: secure boot

2018-11-06 Thread Ansgar Burchardt
On Tue, 2018-11-06 at 10:42 +, Holger Levsen wrote:
> On Tue, Nov 06, 2018 at 10:08:10AM +0100, Bastian Blank wrote:
> > On Tue, Nov 06, 2018 at 01:09:50AM +0100, Adam Borowski wrote:
> > > But only the stock kernel, which turns it non-free software.
> > What is non-free?  Signing stuff does not change the freeness of
> > the
> > software.
> 
> it does introduce https://en.wikipedia.org/wiki/Tivoisation however.

I don't think it does as `shim` allows to either register your own
signing keys or disable secure boot verification (as long as you have
physical access to the machine).

Ansgar



Re: Q: secure boot

2018-11-06 Thread Holger Levsen
On Tue, Nov 06, 2018 at 10:08:10AM +0100, Bastian Blank wrote:
> On Tue, Nov 06, 2018 at 01:09:50AM +0100, Adam Borowski wrote:
> > But only the stock kernel, which turns it non-free software.
> What is non-free?  Signing stuff does not change the freeness of the
> software.

it does introduce https://en.wikipedia.org/wiki/Tivoisation however.


-- 
cheers,
Holger (amazed that there is a wikipedia page about this)

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature


Re: Q: secure boot

2018-11-06 Thread Bastian Blank
On Tue, Nov 06, 2018 at 01:09:50AM +0100, Adam Borowski wrote:
> But only the stock kernel, which turns it non-free software.

What is non-free?  Signing stuff does not change the freeness of the
software.

Bastian

-- 
"That unit is a woman."
"A mass of conflicting impulses."
-- Spock and Nomad, "The Changeling", stardate 3541.9



Re: Q: secure boot

2018-11-05 Thread Paul Wise
On Tue, Nov 6, 2018 at 6:53 AM Adam Borowski wrote:

> Another question: do we want it?  It's beneficial only if you can not only
> add your own keys but also _remove_ built-in ones, and typical "consumer"
> machines don't allow that.

AFAICT the Debian Secure Boot packages are not designed for the
scenario where only Debian keys or per-user keys are trusted by the
firmware, if they were then shim-signed would be named
shim-signed-microsoft and there would be a shim-signed-debian package
too.

In addition, IIRC in such a scenario you still have to trust keys for
the non-CPU firmware (VBIOS?), so you probably won't be able to
actually remove any of the built-in keys.

In addition, the revocation situation is just ridiculous. There is no
way to revoke known-insecure (but still validly signed) software from
every vendor that supports secure boot.

So, really the only reason to support Secure Boot is to avoid users
having to turn Secure Boot off in their BIOS and avoid having to
document how to do that on every firmware implementation that is being
shipped on new hardware. I think it is definitely worth the effort to
do this to avoid turning people away to other distros.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



Re: Q: secure boot

2018-11-05 Thread Yao Wei (魏銘廷)
Hi,

As far as I remember there are some netbooks (from Lenovo) which cannot turn 
Secure Boot off even if it is x86 based.

We can tell user to buy laptop with Coreboot + HEADS preinstalled, or laptops 
that can turn Secure Boot off, but what if they are installing their existing 
machine?

(I hope Coreboot becomes more common in the market instead of Aptio, but it is 
hard to buy such laptop, even Chromebook, unless overseas from Taiwan...)

Yao Wei

(This email is sent from a phone; sorry for HTML email if it happens.)

Re: Q: secure boot

2018-11-05 Thread Steve McIntyre
Hi!

Hideki Yamane wrote:
>
> I'm curious that what is the blocker for introducing secure boot feature
> into Debian now? Already kernel, grub2 and shim are signed, then what should
> we do to achieve it?

We're just working out the last steps on the debian-efi list at the
moment.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Further comment on how I feel about IBM will appear once I've worked out
 whether they're being malicious or incompetent. Capital letters are forecast."
 Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html



Re: Q: secure boot

2018-11-05 Thread Hideki Yamane
On Tue, 6 Nov 2018 01:09:50 +0100
Adam Borowski  wrote:
> But only the stock kernel, which turns it non-free software.

 Sorry, I'm not sure what you're saying.


> There's no benefits for us, too

 As I said, our users can install Debian easily. It's huge benefit.


> -- a thief or attacker can boot/install
> Windows, read any non-encrypted data, etc.  We're better off if we don't
> support secureboot on such hardware.  Debian has enough use share to be
> named when governments are concerned -- if we start providing "secure"boot
> enabled kernels, it'd be an easy sell to lock down consumer machines to
> disallow kernels not blessed by Microsoft's key.

 What you're talking about? It does NOT depend on whether Debian ships 
 secureboot enabled kernel or not.



-- 
Hideki Yamane 



Re: Q: secure boot

2018-11-05 Thread Adam Borowski
On Tue, Nov 06, 2018 at 09:01:23AM +0900, Hideki Yamane wrote:
> On Mon, 5 Nov 2018 23:52:35 +0100
> Adam Borowski  wrote:
> > Another question: do we want it?  It's beneficial only if you can not only
> > add your own keys but also _remove_ built-in ones, and typical "consumer"
> > machines don't allow that.
> 
>  I disagree it. With my understand, secure boot support in Debian is we can
>  install Debian without modifying secureboot option in BIOS.

But only the stock kernel, which turns it non-free software.

There's no benefits for us, too -- a thief or attacker can boot/install
Windows, read any non-encrypted data, etc.  We're better off if we don't
support secureboot on such hardware.  Debian has enough use share to be
named when governments are concerned -- if we start providing "secure"boot
enabled kernels, it'd be an easy sell to lock down consumer machines to
disallow kernels not blessed by Microsoft's key.


Meow.
-- 
⢀⣴⠾⠻⢶⣦⠀ Have you heard of the Amber Road?  For thousands of years, the
⣾⠁⢰⠒⠀⣿⡁ Romans and co valued amber, hauled through the Europe over the
⢿⡄⠘⠷⠚⠋⠀ mountains and along the Vistula, from Gdańsk.  To where it came
⠈⠳⣄ together with silk (judging by today's amber stalls).



Re: Q: secure boot

2018-11-05 Thread Steve Langasek
On Mon, Nov 05, 2018 at 11:52:35PM +0100, Adam Borowski wrote:
> On Tue, Nov 06, 2018 at 04:15:31AM +0900, Hideki Yamane wrote:
> > Hi,

> >  I'm curious that what is the blocker for introducing secure boot feature
> >  into Debian now? Already kernel, grub2 and shim are signed, then what 
> > should
> >  we do to achieve it?

> Another question: do we want it?  It's beneficial only if you can not only
> add your own keys but also _remove_ built-in ones, and typical "consumer"
> machines don't allow that.

[citation needed]

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature


Re: Q: secure boot

2018-11-05 Thread Hideki Yamane
On Mon, 5 Nov 2018 23:52:35 +0100
Adam Borowski  wrote:
> Another question: do we want it?  It's beneficial only if you can not only
> add your own keys but also _remove_ built-in ones, and typical "consumer"
> machines don't allow that.

 I disagree it. With my understand, secure boot support in Debian is we can
 install Debian without modifying secureboot option in BIOS.



-- 
Hideki Yamane 



Re: Q: secure boot

2018-11-05 Thread Adam Borowski
On Tue, Nov 06, 2018 at 04:15:31AM +0900, Hideki Yamane wrote:
> Hi,
> 
>  I'm curious that what is the blocker for introducing secure boot feature
>  into Debian now? Already kernel, grub2 and shim are signed, then what should
>  we do to achieve it?

Another question: do we want it?  It's beneficial only if you can not only
add your own keys but also _remove_ built-in ones, and typical "consumer"
machines don't allow that.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ Have you heard of the Amber Road?  For thousands of years, the
⣾⠁⢰⠒⠀⣿⡁ Romans and co valued amber, hauled through the Europe over the
⢿⡄⠘⠷⠚⠋⠀ mountains and along the Vistula, from Gdańsk.  To where it came
⠈⠳⣄ together with silk (judging by today's amber stalls).



Q: secure boot

2018-11-05 Thread Hideki Yamane
Hi,

 I'm curious that what is the blocker for introducing secure boot feature
 into Debian now? Already kernel, grub2 and shim are signed, then what should
 we do to achieve it?


-- 
Hideki Yamane