Re: *countable infinities only

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Mon, 25 Jun 2012, Seth Johnson <seth.p.johnson@xxxxxxxxx> wrote:

> On Mon, Jun 25, 2012 at 2:48 PM, Gregory Maxwell <gmaxwell@xxxxxxxxx> wrote:
> On Mon, Jun 25, 2012 at 2:37 PM, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote:
>> I'm reading they're going to use a modified Intel efilinux, not writing a new boot loader. And that they will not require either signed kernel or kernel modules.
>
> Thats my understanding.
>
>> So what's the point of Secure Pre-Boot?
>
> Making Ubuntu work on the hardware people have. Which is the
> justification given here why Fedora needed to adopt crytographic
> signing of the kernel/drivers/etc.
>
> I think this all would have been a much simpler matter if it wasn't
> being described as essential for keeping Fedora operable on the
> computers of the common folk.
>
> Of course, users who want more aggressive secureboot would be free to
> replace the keys in their system with ones which only sign bootloaders
> which are more thoroughly locked down…  but I don't see evidence of
> the demand. (can you point to some?)


It would appear that right now, it's a matter of a political
necessity, unforeseen by the general population, though vaguely
bugging the free software development community.

I would agree there's not much demonstrated demand, but if we wait til
the worst apprehensions come true, we will be at a disadvantage.  The
general population does not experience the problem that free software
developers can more readily anticipate.


>> I think for at least 9 months now the idea of a strictly pre-boot implementation of Secure Boot is possible, but meaningless to the point of "WTF, why bother?" with the effort required. It's like building a bridge that's 80% complete, and therefore 100% useless.
>
> And the kernel hands off control to a init/systemd which is unsigned—
> which can be rooted and exploit a vulnerable kernel to prevent
> updates.  It's like building a bridge that is _10%_ complete, and
> therefore 100% useless. :)
>
> … the amount of critical userspace code that runs before updates can
> be processed is enormous and the kernel and bootloader is just a tiny
> fraction of that.  Why not build the 100% bridge that actually
> provides a remotely secured platform? Because it's incompatible with
> software freedom.

I don't see this.  If you choose an authority and can put their keys
into your own box, then you're good until that authority is
compromised.  This, if I am tracking this correctly, is the
infrastructure part of the solution.  You just have to get out in
front with the trusted authority.  I would think that if FSF provided
keys, that would be pretty trustworthy, though for the following
reason I actually don't think they should be out front with this part,
because they would clearly be targetted, and we wouldn't want that to
happen until there was a developed market in trust authorities.  It
would not, of course, assure that all "content" and code could be
processed freely, but it would create the context in which we could
demonstrate that the authorities that provide palladiated "content"
and code are restricting people's capacity to compute.  Keep up
providing authorities that assure software freedom -- do the whack a
mole bit if necessary -- and that context will be the context that
demonstrates to the people at large that there are people out there
that have truly fully-functional computers and they want to have that
too.

This is not inconsistent with software freedom. You're going to have a
root key.  If it's your own, you can't do much unless you buy into the
englobulators' signing regime; if you want to do more, you have to
create some sort of collaborative context that uses a common trusted
key.  We might have lots of little groups like that, but they will not
be able to stand up against the political norms we can easily
anticipate being established if we do not come to terms with how to
make software freedom viable while using Secure Boot our own selves.
So to me that clearly indicates a *political* need for developers who
want to keep their freedom, to get out in front and *create* a market
in trusted authorities.  If your idea of software freedom is
decentralized in some sort of resolutely individualistic way, you'll
be locked out by the larger forces.  That's why it's necessary to get
out in front ad establish the infrastructure, and get people offering
lots of trust authorities, start trying to conceptualize that market
and how and whether it would be competitive.

This is the way I see the situation; I feel that I step a bit beyond
my expertise or comprehension as I describe it, so somebody please
tell me if my conception misses anything.  I defer to Jay usually for
this very reason.  So have at it: let me know what you see when you
see me explain this piece of the puzzle.  :-)


Seth

I will not address directly any particular point in this branch
of the thread, but I have some questions about what sort of
capabilities the UEFI will have in machines sold later this year:

1. What is the mechanism for remote revocation of signing keys?

2. In particular, will the UEFI be able to revoke, at the command
of Hardware Key Central, signing keys without a standard (style
of) kernel being booted?  That is, can the UEFI receive commands
over the Net using its own network capabilities?

3. If booting a standard style of kernel is required to revoke,
at the command of Hardware Key Central, signing keys, then the
standard kernel must be capable of receiving and interpreting
such commands, and also be capable of modifying the memory of the
UEFI hardware.  How will the Englobulators ensure that every
signed-by-Microsoft Red Hat kernel will take orders from Hardware
Key Central?  Note I assume here that Hardware Key Central is
controlled by the Englobulators.

These questions are asked so that I may better lay out some
actual security considerations in a later post.

I thank you Fedora UEFI team for reading this!

oo--JS.




> Central control is Microsoft's strength, not
> Fedora's.
-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux