On Fri, 28 Oct 2022 10:46:54 +0200 Maurizio Avogadro <mav...@gmail.com> wrote: > Il 27/10/22 21:56, Siddh Raman Pant ha scritto: > > I used libsecret (which is used as backend by the Python program named > > keyring), > > with the keyring being stored as root (isn't visible outside root in > > seahorse). > > Can you tell why that may be a bad idea? > > It can be a nice solution but I admit I totally ignore how this works and > many > questions arose on my mind: how is the keyring first created? Is the keyring > password protected? How is the keyring password asked? Does this work in a > su-ed/sudo-ed text only console? What happens when issuing this command in a > root console, and what would be the output: > > # keyring get uefi mok > > When talking of Gnome/KDE keyrings my head goes to X11/Wayland, and I prefer > not to run graphical applications as root to avoid making the whole process > more complex and therefore potentially more prone to security issues. >
Yeah now I see, it's not a good one for headless environment. OOTB it currently shows a password prompt in GUI for unlocking the keyring (it is protected). You can have a look at the following for headless behaviour: https://github.com/jaraco/keyring/#using-keyring-on-headless-linux-systems Anyways, keyring here is immaterial. You could `read -s` the MOK key passphrase. It was just a convenience. > > [...] > > I won't really want to store password in plaintext... > > Agreed, but remember that current dkms is designed to create new MOK key > _without_ a password, it doesn't currently even support using a password > protected MOK key: this is even less secure. > The whole secure boot support is still looking to get a stable shape and I > wouldn't deploy it in a production environment yet; in the meanwhile, while > experimenting it, I can live with a root only readable file containing the > clear-text password. I agree, it is not what ideally should have been there. Regardless, if you want, you can store your password in the bash script. > > > [...] > > What I pointed out was setting sign_file to a bash script. It would solve > > this > > issue too, as the correct path to the actual sign_file binary could be used > > in > > the bash script / handler. dkms would call the bash script with its > > arguments, > > and the script will call the correct binary (passing the arguments to it), > > as > > $kernelver variable would be available to the script. > > Yours is indeed a possible solution until the issues will be fixed on the > dkms > side IMO: I used a bash sign-file script too at first; but this is actually a > workaround, and looking abstractly at the issue I think that if dkms is > supposed to manage module signing, a fix have to be introduced there. Agreed fully. I just pointed out a way if someone is stuck. I was stuck too, and I personally was also browsing the internet (esp. forums and mailing list like this one) in order to fix my machine and get drivers like nvidia to be loaded. Since I managed to get something up, even though hacky, I decided I should also post it up on the places I was finding/browsing for a solution, so it may help others for the time being before it is actually fixed. It also serves as another data point that dkms currently doesn't have support for KBUILD_SIGN_PIN. > > Also, v3.0.6-4 seems to have the fallback you mentioned. Refer: > > https://salsa.debian.org/debian/dkms/-/blob/debian/3.0.6-4/dkms.in#L870 > > That's not a fallback: when running a Debian distro the * case will never be > executed. In current master tree the * case has been removed and a check has > been added after the case block to set a fallback path if the sign-file > executable wasn't found [1]. Noted. Thanks for correcting me. > > > [...] > > Attached here the patch to dkms I'm currently using to make module signing > work. Thanks, Siddh
