On Oct 25, 2014, at 7:35 AM, Stefan Huchler <stefan.huchler(a)mail.de> wrote:
Chris Murphy <lists(a)colorremedies.com> writes:
I try to not answer to much, because I dont want to argue to much, I
just wanted a solution for my problem and this had nothing to do with
secure boot, but I give my 2 cents to it.
Indeed, it's completely on me that this segued into UEFI Secure Boot and is totally
off topic.
Did you really happen to see such a exploit in the wild that somebody
used kvm to start windows to hack a linux pc?
Doesn't matter whether you or I have seen it, the question itself it not relevant.
It's old news on BIOS/MBR systems. Rootkits for UEFI have existed in the wild for a
few years now, and proof of concepts for even longer which is why Secure Boot was created.
You have to believe ludicrous things to think Secure Boot was created for no good reason.
And much easier than kvm, is to use kexec to execute arbitrary code including a
compromised Windows kernel. Any compromised linux kernel module is a gateway to
compromising everything above including e.g. selinux, and user space anti-malware
mechanisms.
Not that Secure boot could
hinder that at every level, just on a bootstack level or something.
That is correct, but it is a prerequisite for being able to even trust userspace if kernel
space is already compromised then it's a problem.
Or
do you want to say to me, that it makes it impossible to change any
binaries on the system or in the ram? I am not so much into it, but I
doubt that.
It means a very high degree of likelihood that what the user wants to have booted has in
fact been booted, and not something else. And it should mean remaining concerns still are
userspace concerns which we're managing with selinux and sandboxing - which is a kind
of expectation that applications will continue to have bugs and vulnerabilities that might
be exploited and thus they need to be contained to minimize the kind of damage that can be
done if a system is compromised. But it's a huge big fat open ended mess if the system
is compromised right from the moment its booted because then the attacker can just inject
code to work around those containment attempts. Is selinux enabled? No but the user space
program is compromised and returns yes it is enabled and includes some bogus logging that
suggests on casual inspection that it's working.
So to solve a theoretical problem we create other problems users that
cant use Linux because of that garbage.
Please don't conjecture about things you don't actually know anything about while
you castigate the efforts of a large number of people who know better, and you benefit
from whether you recognize it or not.
But still its hard to hear that argument, that solving a theoretical
in
practise never happend (I would be amused if you give me a link or
something where it happend)
http://lmgtfy.com/?q=uefi+rootkit
Please stop asking other people to do basic research for you while you suggest in its
absence the risk is fabricated. What you're doing is a passive form of name calling.
problem for companies and hurting real users
that are new to linux, and even the pro linux users, are hurted because
they have to invest more time into maintaining this stuff.
This is a technology problem, we no longer ask users to compile their own applications
from scratch, they get packaged for their convenience. We don't show people the length
boot scroll, this is hidden by default. So if you're suggesting things are too
complicated, I agree, and we'll need to get better. But you appear to suggest the
threat is not real, the solution is fake, and we need to just bury our head in the sand in
exchange for ease of use at expense of security. And I think that's dangerous and a
huge disservice to any user, old or new, that such threats don't exist. We simply need
to do better mitigating them while limiting the complexity/involvement of the user in
enhancing security.
But secure boot is not even the main problem, if you redhat and co do
your job right and pay microsoft much money that they allow computers to
boot linux in the future
I wish this particular lie would die, yet here it is again. You're either a troll who
knows he's lying, or you're just ignorant. Either way, you're not forgiven
because the ignorance is due to just being lazy and depending on others to take up their
valuable time to combat foolish lies.
Neither Fedora Project nor Red Hat paid Microsoft money to allow computers to boot linux.
The money, i.e. $99, only ostensibly goes to Microsoft in order to have developer portal
access so that binaries can be submitted for signing with Microsoft's key. The money
actually goes to Verisign. And anyone can do this. Among several key parts of the Windows
8 hardware requirements for x86_64 is that Secure Boot must be something the user can
disable, and further the user can enroll their own keys with the firmware. No one paid
Microsoft to make that part of their hardware certification process. In fact you have no
guarantee at all that you can boot linux on x86_64 hardware unless it is Windows 8
certified.
(except smaller distros will not happen because
of this) even in a few years when there will be no secureboot off button
in bios anymore, or maybe even today on some models, I dont care to
much, or I have to eat it, lets say it that way.
Anyone can pay $99 to get their bootloader binary signed by Microsoft. Anyone can pay $0
and ask their users to go through some extra hoops to self-sign and register their own
keys with the firmware, and Fedora provides tools to do exactly this. And of course anyone
can just turn off Secure Boot if they so choose.
I just have more problems with this GPT things, I thought it would be a
good idea, or its more modern and has more features, but that u know
suddenly need 3 partitions as absolute minimum to get a bootable system
is just insane, I talk about GPT to not get that out of context again.
And the tools suck, sorry that its possible to have a gpt AND mbr
partition table is just retarded it should hinder you or at least warn
you to do that. fdisk should be able to see when there are gpt partition
and just refuse to work till you deleted the gpt table and so on.
New versions of fdisk work with both MBR and GPT partition schemes. parted has supported
both for some time. To me it seems simpler to understand one kind of partition with 128+
entries permitted, rather than primary vs extended vs logical vs the LVM rabbit hole as a
means of partitioning things. And also at least with GPT there's a backup header and
table, and I've had it come in handy.
and where is the mk-minimal-system-partitions command, I dont want to
remember how big this things are because its stuff for grub and has with
my data my linux nothing to do.
I am shure thats not your fault, but if the experinces outside your
grafical linux installer is so bad, its pretty logical that nobody wants
this except he gets payed to have shitty tools and hit his head for more
safety of a company (except in reality its only more theoretical
security).
Sorry if I did run into that to much, and maybe I mixed a bit at the end
security stuff from secureboot with gpt stuff in the heat of me arguing.
But at least maybe I gave you some critic on the linux tools the
implementation or somebody else thats above the general critics of the
technology and more about how tools should maybe be.
Well I'm not completely following either the complaint or the proposed solution other
than you like the old way. But the old way was once the new way so this idea of old way is
better than new is an old bad argument. It's understandable the new tools can be rough
around the edges, will have bugs, and need to get better.
Its just till now it was fdisk /dev/sda c enter enter w enter q enter
mkfs.ext4 ... rsync /mnt/old_hd/... enter grub-mkconfig grub-install
/dev/sda done...
you had something that boots.
now its so much more complicated at least when you use gpt. and you can
do so much more mistakes...
It's not as much more complicated as it is different. Yes you need an EFI System
partition to hold the bootloader. I guess that's a bit more complicated, but arguably
we always needed a partition for the bootloader. It doesn't really belong mixed in
with the filesystem, especially in the context of multiboot.
Chris Murphy