Half-OT: Secure boot and thirdy party kernel modules

[Sergio Belkin]

Hi Fedora folks,

I've found that Oracle VirtualBox kernel module are not signed so I have to
disable secure boot. Oracle says that is not a VirtualBox bug. And Fedora
cannot sign it because of license, can it?

So, the question is: Is it worth signing "my own" kernel? Of course I can
circunvent this problem simply by disabling secureboot... what do you
think, is there a simple way of doing that, or should I spend a weekend
doing all of it?

I've found this:
http://www.linuxfoundation.org/news-media/blogs/browse/2013/09/booting-se...

Can I sign only the virtualbox kernel module, or should I recompile the
entire kernel and sign it?

Thanks in advance!

-- 
--
Sergio Belkin  http://www.sergiobelkin.com
LPIC-2 Certified - http://www.lpi.org

[Matthew Garrett]

On Sun, Jul 06, 2014 at 02:10:45PM -0300, Sergio Belkin wrote:

>  I've found that Oracle VirtualBox kernel module are not signed so
> I have to
>  disable secure boot. Oracle says that is not a VirtualBox bug. And Fedora
>  cannot sign it because of license, can it? 
Correct. You can generate your own key, enroll it with mokutil and 
then sign the modules with that key.

-- 
Matthew Garrett | mjg59(a)srcf.ucam.org

[Florian Weimer]

On 07/06/2014 07:10 PM, Sergio Belkin wrote:
>  So, the question is: Is it worth signing "my own" kernel?
Only if you keep your own key on a sufficiently separated machine, 
otherwise it's equivalent to disabling Secure Boot anyway.

It's also not clear if the Virtualbox kernel modules themselves are 
capable of bypassing Secure Boot, so the entire effort might be futile 
for this reason as well.

Note that Microsoft's current policy may not allow unrestricted 
virtualization (KVM or Virtualbox—does not matter) because that "permits 
launch of another operating system instance after execution of 
unauthenticated code"—the wording is rather unclear.  If Microsoft 
clarifies that this is forbidden, a future Fedora update will remove 
this functionality, so you will be forced to disable Secure Boot at this 
point anyway if you want to continue to use virtualization.

-- 
Florian Weimer / Red Hat Product Security

[Petr Pisar]

On 2014-07-07, Florian Weimer <fweimer(a)redhat.com&gt; wrote:
>  Note that Microsoft's current policy may not allow unrestricted 
>  virtualization (KVM or Virtualbox—does not matter) because that "permits 
>  launch of another operating system instance after execution of 
>  unauthenticated code"—the wording is rather unclear.  If Microsoft 
>  clarifies that this is forbidden, a future Fedora update will remove 
>  this functionality, so you will be forced to disable Secure Boot at this 
>  point anyway if you want to continue to use virtualization.
>  
Could you elaborate more what "unauthenticated code" is in this case? Is
it a userspace tool for controlling in-kernel virtualization (e.g. qemu
in case of KVM)? Because KVM as a kernel module is signed.

If so, what if user uses pure user-space emulation (e.g. qemu). Either
that imposes user space executables have to be signed too, or the
unclarified statement lacks any meaningful purpose.

-- Petr

[Florian Weimer]

On 07/08/2014 10:19 AM, Petr Pisar wrote:
>  On 2014-07-07, Florian Weimer <fweimer(a)redhat.com&gt; wrote:
> > Note that Microsoft's current policy may not allow unrestricted
> > virtualization (KVM or Virtualbox—does not matter) because that "permits
> > launch of another operating system instance after execution of
> > unauthenticated code"—the wording is rather unclear.  If Microsoft
> > clarifies that this is forbidden, a future Fedora update will remove
> > this functionality, so you will be forced to disable Secure Boot at this
> > point anyway if you want to continue to use virtualization. 
>  Could you elaborate more what "unauthenticated code" is in
> this case? 
I think it's code that is not cryptographically tied (indirectly) to one 
of the Secure Boot trust roots.

However, I don't really know what Microsoft means.  It's conceivable 
that they assume we sign all of user space (not just for installation 
purposes), and they might have a wrong idea about what we can implement 
in our system.

>  Is
>  it a userspace tool for controlling in-kernel virtualization (e.g. qemu
>  in case of KVM)? Because KVM as a kernel module is signed. 
It's unclear.  One possible interpretation is that virtualization acts 
as a barrier because it does not provide access to "real" ring 0 on the 
host.  It sounds reasonable, but it doesn't really match Microsoft's 
wording I quoted above (from a public blog post).

-- 
Florian Weimer / Red Hat Product Security

[Sergio Belkin]

2014-07-08 5:47 GMT-03:00 Florian Weimer <fweimer(a)redhat.com&gt;:

>  On 07/08/2014 10:19 AM, Petr Pisar wrote:
>
> > On 2014-07-07, Florian Weimer <fweimer(a)redhat.com&gt; wrote:
> >
> >> Note that Microsoft's current policy may not allow unrestricted
> >> virtualization (KVM or Virtualbox—does not matter) because that "permits
> >> launch of another operating system instance after execution of
> >> unauthenticated code"—the wording is rather unclear.  If Microsoft
> >> clarifies that this is forbidden, a future Fedora update will remove
> >> this functionality, so you will be forced to disable Secure Boot at this
> >> point anyway if you want to continue to use virtualization.
> >>
> >
>   Could you elaborate more what "unauthenticated code" is in this case?
> >
>
>  I think it's code that is not cryptographically tied (indirectly) to one
>  of the Secure Boot trust roots.
>
>  However, I don't really know what Microsoft means.  It's conceivable that
>  they assume we sign all of user space (not just for installation purposes),
>  and they might have a wrong idea about what we can implement in our system.
>
>
>   Is
> > it a userspace tool for controlling in-kernel virtualization (e.g. qemu
> > in case of KVM)? Because KVM as a kernel module is signed.
> >
>
>  It's unclear.  One possible interpretation is that virtualization acts as
>  a barrier because it does not provide access to "real" ring 0 on the host.
>   It sounds reasonable, but it doesn't really match Microsoft's wording I
>  quoted above (from a public blog post).
>
>
>  --
>  Florian Weimer / Red Hat Product Security
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>  
Thanks everybody for enlighten me about this obscure topic :)

-- 
--
Sergio Belkin  http://www.sergiobelkin.com
LPIC-2 Certified - http://www.lpi.org

[quickbooks office]

So did any of you get it to work?

That is signing VirtualBox modules and enabling secure boot in the bios?

On Tue, Jul 8, 2014 at 6:20 AM, Sergio Belkin <sebelk(a)gmail.com&gt; wrote:
>  2014-07-08 5:47 GMT-03:00 Florian Weimer <fweimer(a)redhat.com&gt;:
>
> > On 07/08/2014 10:19 AM, Petr Pisar wrote:
> >>
> >> On 2014-07-07, Florian Weimer <fweimer(a)redhat.com&gt; wrote:
> >>>
> >>> Note that Microsoft's current policy may not allow unrestricted
> >>> virtualization (KVM or Virtualbox—does not matter) because that
> "permits
> >>> launch of another operating system instance after execution of
> >>> unauthenticated code"—the wording is rather unclear.  If Microsoft
> >>> clarifies that this is forbidden, a future Fedora update will remove
> >>> this functionality, so you will be forced to disable Secure Boot at this
> >>> point anyway if you want to continue to use virtualization.
> >
> >
> >> Could you elaborate more what "unauthenticated code" is in this case?
> >
> >
> > I think it's code that is not cryptographically tied (indirectly) to one
> > of the Secure Boot trust roots.
> >
> > However, I don't really know what Microsoft means.  It's conceivable that
> > they assume we sign all of user space (not just for installation purposes),
> > and they might have a wrong idea about what we can implement in our system.
> >
> >
> >> Is
> >> it a userspace tool for controlling in-kernel virtualization (e.g. qemu
> >> in case of KVM)? Because KVM as a kernel module is signed.
> >
> >
> > It's unclear.  One possible interpretation is that virtualization acts as
> > a barrier because it does not provide access to "real" ring 0 on the host.
> > It sounds reasonable, but it doesn't really match Microsoft's wording I
> > quoted above (from a public blog post).
> >
> >
> > --
> > Florian Weimer / Red Hat Product Security
> > --
> > devel mailing list
> > devel(a)lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/devel
> > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>
>
>  Thanks everybody for enlighten me about this obscure topic :)
>
>
>  --
>  --
>  Sergio Belkin  http://www.sergiobelkin.com
>  LPIC-2 Certified - http://www.lpi.org
>
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct