3 ms·
Who will be the CA? Is there any reason why Linux vendors can't sign their mainstream releases? Cost? I'm sure it won't help if you want to boot a custom kern
by jeza 15y ago
Who will be the CA? Is there any reason why Linux vendors can't sign their mainstream releases? Cost?
I'm sure it won't help if you want to boot a custom kernel or similar, though presumedly in that case you'd be capable of changing the BIOS settings.
- keeperofdakeys 15y agoIn practise, this wouldn't work. You would need one certificate for linux for practicably reasons, so you distribute this to the distro makers. All of a sudden anyone who wants to make a custom kernel can't, what's worse is that many distro makers might not be trusted enough to keep it secret. Why not make a certificate that anyone can use? Then malware authors can use it, and secure boot would have no purpose. This is why it isn't practical to try to use linux with secure boot, and the option to disable it must be their for linux to work.
- nitrogen 15y agoI don't think your conclusion that secure boot is impractical with Linux follows from the evidence you've given. I can think of some steps to make it work: 1. Display in large type with an unskippable timeout the name, vendor, and logo of the OS before boot (embed these in the cert). If the "anything goes" cert is in use, the metadata will say "third party OS signed on yyyy-mm-dd" or similar with a warning logo. 2. Require confirmation at the UEFI level of any change in the OS certificate. 3. Require mobo vendors to allow self-signed certificates to be generated, but only from within UEFI.
- keeperofdakeys 15y ago1. Most users don't read warnings, most would go next no matter wat. They would see a timeout as extra annoying. Also this would mean malware would come up with the same certificate as custom linux, which isn't any more 'secure', so you may as well have it disabled. 2. Again, users will just go 'okay'. Here we don't really care about power users, they will probably not buy things with the bios option disabled, this is about general users who go 'let's try this linux thing'. In fact, those users might be ones to click cancel at the first sign of trouble. 3. This could be hard for non-power users, at least a bios option isn't as hard as generating a certificate, and signing something.
- nitrogen 15y agoI still think you're giving up too quickly. It doesn't so much matter if some users are deliberately careless enough to install boot loader malware by hand despite all the certificate signing steps and ugly warnings involved. It is also beneficial to protect a Linux system from the same kind of pre-boot malware. It seems as though you're saying since we can't get it 100% perfect, we shouldn't do it at all. I'm saying don't let perfect be the enemy of the good. If secure boot is going to exist at all, I think we'd be far better off if both Linux and Windows can take advantage of it, with control of the hardware in the hands of the users (or their IT department).
- jeza 15y agoWell to be fair, you could open it up for everyone to use if there were an independent CA. Add some basic security checks before you're key can be trusted and the ability to revoke keys and it should prevent malware. The later might be harder to implement as it would need to be updated.
- keeperofdakeys 15y agoThe problem is, as an individual who wants to compile his own kernel, how would I pass security checks? Any malware author could do the same. Also, a CA doesn't really work because once Secure Boot systems are distributed, you can't revoke a CA or keys.
- zokier 15y agoThere is no indication that there will be any CA. Actually that's one of the points raised by Linux foundation. They advocated that an independent CA would be founded. Currently some people believe that OEMs will include Microsofts certificates directly, so basically that would make MS the CA. Or alternatively OEMs themselves would be the CAs. As for why Linux vendors can't sign their OSses, I think there is some issues with anti-tivoization clause in GPLv3. Also, Linux vendors would need to coordinate with each OEM individually, which would be rather unpractical.
- regularfry 15y agoThe kernel's GPL2 - doesn't that make the anti-tivo clause moot in this instance?