> I have a set of patches that appear acceptable to the security > maintainer. I've rewritten them multiple times in response to various > levels of bikeshedding. They solve a real problem and are being shipped > by multiple distributions. And ? I've seen some of the other "extra" stuff distributions ship. Lots of it is hilariously bad. That really isn't a good argument for the code - for the feature yes. > What the rest of your mail is asking me to do is to rewrite capabilities > support entirely. Now, yes, I agree that capabilities are an awful > interface that's approximately impossible to use correctly and which > adds little security even if you do. But I reject the idea that > rewriting fundamental security infrastructure should be a prerequisite > for adding this functionality. Actually it's nothing of the sort. It's a proposal to do it. It's 90% a regexp task. I'm offering to go and do that bit. I am quite happy to do the capability crapfest fixing. It wants doing *anyway*. But if I got do that work, does it solve your problem ? I think it does but I'd like to be sure. > > > It needs to be possible for this policy to be imposed without userspace > > > being involved, so using selinux would mean baking it into the kernel > > > (along with an additional implementation for apparmor, and presumably > > > one for tomoyo as well). > > > > That's clearly false. You can load signed modules so you can load signed > > policies. Assuming you don't have an initial measured file system you > > need a kernel policy initially that protects you. If you have a measured > > file system you don't even need that, nor do you need to revoke RAWIO in > > kernel, you can do it before you switch into "measured and running > > un-measured code" mode - ie about the point you pivot root out of the > > initrd that loaded the measured policy. > > We can't rely on userspace choosing to load that policy. We don't have a > measured filesystem. The initrd is not signed (and nor can it be). The > kernel itself *must* impose policy. In your particularly implementation maybe you've got a weak setup where you don't measure down to your initrd. That's a *flaw* in your implementation. Don't inflict your limitations on others or on the future. EFI is only one (and not a very strong one at that) implementation of a 'secure' boot chain. A lot of other systems can not only propogate measurement and security assertions into their initrd they can propogate them into their rootfs (yes upgrades are .. exciting, but these kinds of users will live with that pain). Even in EFI you can make your kernel or loader check the initrd signature and the rootfs signature if you want. > Sure! Except then A Large Vendor's custom IPMI userspace stops working, > even on systems without Secure Boot, and then said Large Vendor wants to > have conference calls at times that are convenient for Japan and then > this is an issue that's going to cause $1 billion in lost sales and come > on, you've been there. You know that this isn't going to work. That's not an upstream problem (but with my work hat on I understand your position). Anyway they'll be running someones enterprise product which will have legacy enabled out of the wazoo so their customers 15 year old "we lost the code" blob that nobody can even remember what it does still works 8) > > If we are going to do a measured kernel then it needs to be done right, > > it needs to be properly abstracted so we don't add another one for > > Android, another one for Chrome, another one for ARM trustzone, another > > one for Intel SGX, and so on. > > The fact that you keep saying measured really does make me suspect that > you misunderstand the problem. There's no measurement involved, there's > simply an assertion that the firmware (which you're forced to trust) > chose, via some policy you may be unaware of, to trust the booted > kernel. You are currently using some of those interfaces for measuring to produce a notionally 'trusted' initial loaded environment. Correct me if I am wrong but your starting point is "I have a chain of measurement as far as the kernel I load". Without that I can just go into grub and 0wn you. There are multiple things you want to do in measured environments, stopping people sneakily loading new kernels is one of them. If you want to talk about "secure" that implies a whole load more than ring 0 hacks. It implies having a model where not only has J Random smart hacker gone over the code and hacked all the call points, but that someone has done some kind of formal review of it, used good security practices like whitelisting and thought very hard about the rest of the exposed surfaces. Otherwise its security theatre, it's marketing fluff. We've got lots of marketing security fluff in the kernel, we don't need more of it. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
