On Tue, 2020-01-21 at 14:13 -0500, Mimi Zohar wrote: > On Tue, 2020-01-21 at 09:34 -0800, James Bottomley wrote: > > On Tue, 2020-01-21 at 09:13 -0800, Lakshmi Ramasubramanian wrote: > > > Enabling IMA and ASYMMETRIC_PUBLIC_KEY_SUBTYPE configs will > > > automatically enable the IMA hook to measure asymmetric keys. > > > Keys created or updated early in the boot process are queued up > > > whether or not a custom IMA policy is provided. Although the > > > queued keys will be freed if a custom IMA policy is not loaded > > > within 5 minutes, it could still cause significant performance > > > impact on smaller systems. > > > > What exactly do you expect distributions to do with this? I can > > tell you that most of them will take the default option, so this > > gets set to N and you may as well not have got the patches upstream > > because you won't be able to use them in any distro with this > > setting. > > > > > This patch turns the config IMA_MEASURE_ASYMMETRIC_KEYS off by > > > default. Since a custom IMA policy that defines key measurement > > > is required to measure keys, systems that require key measurement > > > can enable this config option in addition to providing a custom > > > IMA policy. > > > > Well, no they can't ... it's rather rare nowadays for people to > > build their own kernels. The vast majority of Linux consumers take > > what the distros give them. Think carefully before you decide a > > config option is the solution to this problem. > > James, up until now IMA could be configured, but there wouldn't be > any performance penalty for enabling IMA until a policy was loaded. > With IMA and asymmetric keys enabled, whether or not an IMA policy > is loaded, certificates will be queued. > > My concern is: > - changing the expected behavior In general config options for this are a really bad idea because if the tools only cope with one setting, no-one should ever use the other and if they work with everything there's no need for the option. > - really small devices/sensors being able to queue certificates seems like the answer to this one would be don't queue. I realise it's after the submit design, but what about measuring when the key is added if there's a policy otherwise measure the keyring when the policy is added ... that way no queueing. > This change permits disabling queueing certificates. Whether the > default should be "disabled" is a separate question. I'm open to > comments/suggestions. I'm just giving the general rule of thumb for boolean config options. If it's default Y there likely shouldn't be a config option and if it's default N the feature should likely not be in the kernel at all.
