On Oct 25, 2014, at 7:35 AM, Stefan Huchler <stefan.huchler@xxxxxxx> wrote: > Chris Murphy <lists@xxxxxxxxxxxxxxxxx> 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 -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
