Re: *countable infinities only

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

On Thu, May 31, 2012 at 12:11 PM, Gerry Reno <greno@xxxxxxxxxxx> wrote:
> This is a monopolistic attack disguised as a security effort.
> The highly restrictive technological approach that has been taken needs to be challenged in the courts.
> I'd rather see Microsoft users have to attach a dongle to their system to get the "security" that they need.

My understanding is that some of the relevant legal minds believe that
Microsoft's "you can disable it" concession forecloses the possibility
of a successful legal attack on this— the law may care about the
anti-competativeness of this stuff, but not so much as to care about a
$99 signing key or some minor install time hurdle. (and the fact that
fedora is willing to plan this probably justifies this position).

It was arguably a strategic error to blow the whistle in advance and
give Microsoft time to compromise. Their first attempt was much more
likely to have created a civil cause of action as well as to have run
afoul on antitrust grounds.   But I can hardly blame anyone for
trying.  Hindsight 20/20 and all that.

On Thu, May 31, 2012 at 12:13 PM, Miloslav Trmač <mitr@xxxxxxxx> wrote:
> That is just untrue.  SecureBoot can be used to make sure you only run
> the software you intended to run, which is impossible without
> SecureBoot (e.g. this cannot be done with a TPM).  The idea is solid,

I don't think this is fair.

SecureBoot doesn't protect you from someone with access to the
hardware (they can disable secureboot).  And if your kernel is secure
than userspace malware can also not change your boot environment.
If your kernel is _not_ secure then the malware will just modify the
first piece of unsigned userspace code (e.g. systemd) so that it
executes the kernel exploit at startup before updates have a chance to
run, and the kernel rootkit will prevent the updates.

So unless you take the route of signing everything (with the according
loss of software freedom, and a lot of runtime overhead) this actually
doesn't buy you a lot.

Microsoft's competitive advantage is that they lose little by locking
down everything and will potentially get more security as a result.
Fedora's pas competitive advantage was that it provided its users with
the freedom to change the whole system with low friction— something
MSFT's business model can't allow.   By playing along we legitimize
their advantages and weaken our own.  And in practice, since we won't
accept a full lock down (nor, hopefully would the licenses permit it),
Fedora will mostly not enjoy the security benefit.

On Thu, May 31, 2012 at 12:20 PM, Basil Mohamed Gohar
<basilgohar@xxxxxxxxxxxxxx> wrote:
> Ah, yes, but then you also won't be able to run Fedora, under the
> currently proposed solution.  Oops!  See how slick the slope is?

They could if they replace the key while removing the MSFT one, or
disable secure boot at the same time.
devel mailing list

[Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Legacy Announce]     [Home]     [Fedora Tools]     [Fedora PHP Devel]     [Kernel List]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Big List of Linux Books]     [Gimp]     [Yosemite News]

Add to Google Powered by Linux