> The command line problem here is a total red herring. If you've got a > measured kernel, you have a measured command line. (If not, you don't That would be the sensible approach, but it has some quite drastic ramifications. > have a measured kernel.) Dealing with the command line has nothing to > do with enforcing the ring0/uid0 boundary which is what this patch > series does. It has a huge relevance. You are signing blocks of code and loading them into your kernel. In case it's escaped your notice those blocks of code have behaviour which is considerably customisable by passing module arguments to them. In many cases they don't actually check those arguments. If I can set module paramters I already 0wn your box so many different ways its not even funny. > Right. As mentioned, we've been over all of this before. We cannot > change the meaning of capabilities (nor expand their coverage to > existing interfaces) without breaking userspace. Since we cannot break > userspace, we must create a different policy system that covers this > new thing we want to do and keeps the new policy distinctly separate. So you have everything checked twice all over the kernel and you guarantee that people will get it wrong. I don't see the point of putting a broken implementation in the kernel. If you want to do security do it *right* and do it once. You think every single person who adds a driver is going to muddle through two interfaces (and in future no doubt more if we don't fix it properly) and get it right each time ? The 'breaking userspace' argument is bullshit already. The whole *point* of the measured kernel is to break userspace. You are deliberately breaking a pile of functionality, much of it undersirable in order to achieve your measured system. The only "don't break" case that matters is if the measured stuff isn't in use. In those cases we don't need to break anything. 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
