You're saying: "Distributions would then have to ship an additional kernel that had lockdown disabled (it's not possible to just have a command line argument that disables it, because an attacker could simply pass that), and users would have to disable secure boot to boot that anyway."
If I understand your article, disabling UEFI secure boot automatically disables lockdown mode (and if not, why not?), so why do you need another kernel with lockdown disabled by default to be shipped? And you really think that a user is going to be able to distinguish between two official kernels, both shipped by the distributor? Why would an attacker not force that kernel to be booted when he gets control over the machine?
Having a command line parameter to disable lockdown would make it obvious both in the journald logs or in /proc/cmdline. Part of me thinks though that user friendliness is not your goal here, only providing some fuzzy feelings of "magic" security that can be withdrawn at any time if the user does "naughty" things.
You're not making much sense
If I understand your article, disabling UEFI secure boot automatically disables lockdown mode (and if not, why not?), so why do you need another kernel with lockdown disabled by default to be shipped? And you really think that a user is going to be able to distinguish between two official kernels, both shipped by the distributor? Why would an attacker not force that kernel to be booted when he gets control over the machine?
Having a command line parameter to disable lockdown would make it obvious both in the journald logs or in /proc/cmdline. Part of me thinks though that user friendliness is not your goal here, only providing some fuzzy feelings of "magic" security that can be withdrawn at any time if the user does "naughty" things.