(+ Andy and Kees so they can respond to the thread) On 31 March 2018 at 12:20, David Howells <dhowells@xxxxxxxxxx> wrote: > James Morris <jmorris@xxxxxxxxx> wrote: > >> Are there any known coverage gaps now? > > I've covered all the ones I know about. > Andy (and Kees) responded to this without keeping all the cc's. Given that I share Andy's concern wrt the general nature of these patches, I will reiterate them here. First of all, in my experience, when introducing any kind of 'secure' mode, people will immediately assume that everything they use the system for will be more secure going forward, and so they are more likely to let their guard down, resulting in a less secure situation than we started out with. So I already argued for calling this a 'lockdown policy' which is a clearly communicated as a best effort attempt to make the system more robust against inadvertent modifications, and documenting/logging clearly what it actually *means*. The latter is especially important because many of these things are arch specific, and need to be implemented for each arch individually in order to take effect on them. Also, v4.17 lockdown will most likely be different from v4.18 lockdown. Furthermore, there is a fundamental deviation from common security sense here, where things like command line parameters and other lockdown specific tunables are blacklisted rather than whitelisted, and so rather than locking everything down and re-enabling only once what needs to be re-enabled for the system to work, we are now forever going to have to track a moving target, where it is someone's job to ensure that incoming changes don't regress lockdown mode on any of the architectures it supports. If the distros are shipping their kernels with these patches applied to adhere to some kind of requirements imposed by MicroSoft in order for them to be willing to sign shim images, can we please involve those into the discussion as well? It seems to me that this is a solution without a problem statement, and I would like to fully understand the problem before reasoning about the solution. -- Ard. -- 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
