Re: Suggestion: Use a unified kernel image by default in the future.
Would pre-building the initrds mean all users have to use the same partition layout. If that happened, than many people dual boot setups will not work ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
That attack is a real thing, its called a mitm, but things use https now, so you would need a malicious CA. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
If it is really compromised, then you have to assume anything the vm sends you is fake. As far as the owner of guest knows, there could not even a a real vm, only a ssh shell that looks like it. In a real situation, the guest owner would send the host owner a "starting disk" or ISO. Then the host would tell the trusted cpu to boot a iso that sends the signature to the host, and also boot a modified iso in a normal hypervisor, and emulate the trusted part of the cpu. When the normal hypervisor vm wants the signature, the signature of vm1 is returned. The system in the normal hypervisor could also just lie to any connections outside the host system, so even if it knows its backdoored, it still test the guest owner its not. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
Also, whats stops the owner of the machine to run the vm in a normal hypervisor, then modify it so any attempts to check if it is "trusted" will always look real. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
It should be possible to load sd-boot directly, it picks up any kernel in /boot/EFI/linux for me. Try loading sd-boot directly from ovmf, skipping grub. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
How can you know if this interface is not emulated, and you never talk to the real cpu. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
> Like what? I know there are some efi implementations that need pcie_ports=compat. I also know that sometimes you need intel_iommu or amd_iommu=off. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
> level of tweaking then it's probably totally OK to just turn >of Secureboot, at which point you can change it freely. The user having choice and the user having secure shouldn't be mutually exclusive. Also, if users have "special" hardware, shouldn't they also have security. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
I think using credentials for the rootfs is not very useful, the user already enters the LUKS password on boot. Also, if the encryption keys are not stored locally, then they have no use, an attacker can just get them from the external storage. Many users also would not like needing an attestation service to boot either. If the encryption keys need to only be revealed on a trusted boot, then it should be stored in the tpm. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
> My expectation would be that by default we'd just use the GPT auto discovery stuff Existing Fedora installations do not follow the GPT auto discovery spec. Also, I think the existing system for the root device can still work, it is passed in the command line, not the initrd. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
With virtual machines, nothing can actually be verified completely, the host running the vm can, 1) Modify the firmware to intercept anything the attacker wants, or 2) directly intercept things at the cpu level. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
Even if initrds are (somehow) signed, the kernel command line can still be modified, like adding `init=/usr/bin/bash`. Also, if everything is signed by fedora, then the user can not modify the command line. There is a lot of hardware that needs command line modifications to boot. Also, fedora would have to revoke signatures for every vulnerable kernel, or there is no real security. If those kernels signatures are revoked, then they wont boot even when they are the currently installed kernel and should be able to boot. If there is a way for a fedora signed kernel image to load a locally signed command line, then this would work much better. > However I think the initrd should be built on fedora infra > and signed with fedora keys by default. What about when the user has a custom kernel module, would there be a way for the user to use it. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
The entire purpose of a unified kernel image is to have the initrd bundled, so it can be signed. systemd-boot also supports s multiple initrds. If there was a way to sign the initrd and command line locally, and sign have fedora sign the kernel, then there shouldn't have to be a huge initrd. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
> The Flathub remote is available to users who opt-in to enabling > third-party software repositories in either GNOME Initial Setup or > GNOME Software. A lot of flatpaks in Flathub have debatable quality, and are closed source. If we could wait until flathub separates open-source and proprietary repos, the open-source one could be unfiltered, and the proprietary one could have a blacklist for very bad packages. I think it would be better if there could be some sort of warning in GNOME software, so maintainers could mark certain packages as unsafe or low-quality. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
Also, can it be fixed so adding the --uefi flag to dracut works with the default generation scripots ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
A key on an encrypted disk can still prevent evil maid attacks, though an attacker with local access can still compromise the system. In the current system, an attacker with permissions required to read kernel memory can just ask the shim to boot their modified kernel. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
It would be stored with permissions for only root to read it, and you disk should be encrypted, or none of this matters. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
If the system owner wanted to, they could use their own firmware/ comprimise firmware, then fake the firmware version to something new, the vm could not even be interacting with the cpu at all. Also, if the keys are in the cpu, then the keys can be extracted. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
> How big is the demand for this kind of lockdown? It can help users security, but most users have no idea what this is. Software should be secure by itself, without users needing extra effort. > As a since-last-century Linux user, I'm choosing Fedora > exactly to NOT have all this signing/trusted boot > complications on my systems and I do not see a reason > to turn Fedora into Android (or, worse, iOS). This will not turn fedora even remotely similar to iOS or Android. You still completely control userspace, and can modify the kernel if you want, you just need to run the command to resign the kernel. You can also easily disable, and have no impact to the rest of the system, other than reduced security. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
Akmods can automatically sign kernel modules, its just a few commands and then every version will be signed. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
Secure boot itself, when used right, actually helps your privacy. Microsoft doesn't require oems to allow the keys to be changed, so it sometimes prevents your freedom, but when implemented right, it can stop evil maid attacks. Also, even when you cant remove Microsoft keys, you can still use the shim. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
The latest akmods version can automatically sign kernel modules, it could even be enabled by default. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
This is a good idea, but some users might want to modify or need to modify the command line to boot, if it was signed using fedoras key, then you cant do that. Also some users dont like keeping their trust in fedora and would like to modify their kernel freely. Also, though the private key is something attackers want, if they can read or write the private key, then they can just as easily modify systemd, and get root, or install ssh with their own keys, at that point secure boot will not help you. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
This could be for a later fedora version if it doesnt work. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Suggestion: Use a unified kernel image by default in the future.
Use unified kernel images by default for new releases. This can allow for the local installation to sign the kernel and the initrd, so the boot chain can be verified until after the uefi. Currently, the initrd can be modified by attackers, so even if the / partition is encrypted, the systems data can be read on the next boot. If the kernel image, which includes the command line, and the initrd, is signed then it is harder to comprimise the system. The system can still be comprimised if the uefi is modified. If this was used, then the kernel could no longer be signed in the package by the fedora infrastructure. To still support secure boot, the kernel image would have to be signed be key stored on disk on every update. If the disk is encrypted, the private key can still be protected from attackers. On installation, or update for existing installs, a public/private keypair would be generated, and trusted by the shim. This has a few problems, if the root user is hacked, then the kernel can be tampered with. But this is not a very big problem because if the root user is hacked, then for example systemd can be changed, secure boot will not protect you. It will also mean that if the user want to modify the kernel command line or initrd, they have to regenerate the entire kernel image. This can also break some users install, if they use a non-default boot process, or have a buggy uefi implementation. For non-uefi architectures, this change could be ignored. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
