On 6/3/23 15:46, Jiri Slaby wrote:
is there a way for me to disable the lockdown?
Disable Secure Boot.
Company laptop... Secure Boot is supposed to be enabled. It is political; meaningless, but necessary. It allows me to run TW on the corp laptop. Having a signed kernel is fine. What the kernel does from there has worked well in the past. It has basically just given me full access to the machine. A couple of years ago, I needed to access a few files from a HDD that came from an old system that ran VXWorks. I found an old out-of-tree module for VxFat, modified it to work with whatever kernel I was running, and loaded it. It was simple. It worked (well enough - there were some odd phantom files in there, but it still did the trick). No need to worry about signing etc., and no need to compile my own complete kernel. More recently, I was poking around at a proprietary PCIe 'thing' I found, and I was doing roughly the same thing by modifying a module that was close (though, to be honest, this was done under CentOS 7 and without secure boot, but it is a valid use case for TW nonetheless). This change gets in the way. Can OBS build an out-of-tree module against TW now, or will it fail to build? Can I add a repo or something so that it signs it for me with the SuSE key? For me, having the kernel enforce more actual security is a step too far. On this laptop, I only need the political illusion of security. As it is, I disable all CPU side-channel mitigation. I am not saying it is a bad thing though. Because Leap can be used as a 'proving ground' for POCs that will run on SLES (at least, I use it for that because it is easy to move to SLES if it goes prod), I feel it is very important that all security settings are in Leap and enforced the same way as SLES. Obviously, this would also be important on a Kube node, or a MicroOS used as life-support for KVM. In this case, although you have physical security, and politics sure still seems to come into it more than real security outcomes, there are real concerns (though without encrypted data at rest, this is still silly). Also, because Tumbleweed is more of a superset of everything, it should be AVAILABLE in Tumbleweed. IMHO, it should not be ENFORCED in tumbleweed though. The very idea of enforcing locking anything down seems to be against the entire point of Tumbleweed. What was the motivation for enforcing this on TW?
I'm not sure, but I think this was suggested to do the trick: mokutil --disable-validation
I REALLY hope this works. If it does, you have just solved everything for me. The world is OK again! I am a little worried because there is "No manual entry for mokutil" But.. I am in a crazy mood.. so.. I ran it as stated. It asked for a password. I gave it one. It asked for it again. It dropped me back to a prompt. I wonder what I just did. Does this make everything back to normal? I wonder if I can just compile a module and load it now after a reboot... if it reboots! If this works, maybe we can this as a tick-box in YaST (yast bootloader), and maybe we can call it "Very trusted boot support". -- Ben