On Sat, Jun 2, 2012 at 5:26 PM, drago01 <drago01@xxxxxxxxx> wrote: > On Sat, Jun 2, 2012 at 11:14 PM, Gregory Maxwell <gmaxwell@xxxxxxxxx> wrote: >> I think regressing to the installs >> being somewhat easier than ten yearsish ago is still a better place to >> be than the cryptographic lockdown. > > I disagree and once again it is not a lockdown as people who care > enough can disable it, while having it enabled by default makes things > easier for a large set of (potential) users. You can disable the lockdown on iOS devices too—and the lawfulness of this activity is well established in the US. I understand that when the Copyright Office hit its periodic review for that particular DMCA exemption Apple didn't even fight it this time. It is still a lockdown even if there is some complicated procedure to disable it—you can't argue this both ways. Either it's an inconsequential restriction because it's so easy to disable, or it's a practical problem for people installing the OS. And what happens when OEMs leave out the option, which isn't even required by the UEFI spec itself, and Microsoft fails to enforce that particular requirement? "Not our fault"? > And if we have the choice between "make it easier to modify every part > of the OS" vs. "make it easier to instal the OS in the first place" > ... no one thinking rationally would opt for the former. If it were so simple we'd never have free software at all, because it was always easier to continue using whatever commercial offering came bundled with your system. In this case it's "make it easier to install" vs. "preserve an ecosystem of cooperating publishers, keep software freedom as a top-line priority, keep it easy to modify every part, and don't put Red Hat in the business of defending semi-tivoization against license enforcement by free software authors". > Besides installation and modification aside it does provide another > additional value ... which is added security which is a welcome > addition in some environments. There is no additional security provided by the feature as so far described—only security theater. So I can't modify the kernel or bootloader, great—but the kernel wouldn't have let me do that in the first place unless it had an exploit. So I just put my rootkit inside systemd so that it executes the kernel exploit right after reboot, and the exploited kernel now silently keeps updates from being applied. This has hardly made any attacks more difficult at all. You don't get security benefits from this without a much more elaborate and fragile system, or without mandating the signing of a much larger portion of the software stack so that updates can run before any unsigned code (and even then only after the horse has left the barn: the attacker has stolen your data and wiped the system before reboot). If you want to improve the security of Fedora, there are a great many things that can be done which don't have sticky compromises and which would provide greater actual security. Moreover, I can find no feature requests for this functionality. (Instead the internet is flooded by people asking how to turn off the security facilities Fedora already has, people on the IRC channel reflexively tell people to disable SELinux even when doing so isn't required, etc.) -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
