On 14 February 2018 at 12:52, Benjamin Drung
<benjamin.dr...@profitbricks.com> wrote:
> Hi,
> I am exploring the possibility to store SSH and other keys in UEFI
> variables for systems that do not have persistent storage. These
> systems boot via network and need individual SSH keys which ideally
> should not be distributed via network.
> The plan is to write a small daemon that starts at boot and gets the
> SSH keys from EFI variables to individualize the system with SSH keys.
> I plan to release the code as free software. Simple proof-of-concept
> code:
> mount -t efivarfs none /sys/firmware/efi/efivars
> for key in ssh_host_dsa_key ssh_host_ecdsa_key ssh_host_rsa_key; do
>   dd ibs=1 skip=4 
> if=/sys/firmware/efi/efivars/${key}-89df11f4-38e6-473e-ab43-b4406b76fba9 
> of=/etc/ssh/$key
> done
> I am not the first person having the idea to use UEFI variables to
> store keys:
> https://www.usenix.org/conference/srecon17asia/program/presentation/korgachin
> There is one problem: The keys should be readable only by root. When
> mounting efivarfs, all variables have the permission 644 which makes
> them readable by all users. I have different ideas how to solve it:
> 1) Hard-code a list of GUIDs that should be only readable by root in
> the kernel module. These modules would also be not set to immutable.
> 2) Instead of hard-coding GUIDs, add a kernel module parameter to
> specify the GUIDs. Maybe have a default list in the kernel module.
> 3) Add a mount option to specify the protected GUIDs.
> Feedback is welcome.

I'd consider a patch that makes the permissions a mount option for
efivarfs, applying to all variables. The reason is that these
variables shouldn't have been world readable in the first place, and I
am reluctant to make this overly complex.

On the other hand, you should realize that UEFI was never designed to
keep secrets, and so whether it is a good idea to put secrets in UEFI
variables to begin with is dubious IMHO.
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to