> From: Dan Čermák [mailto:dan.cermak@xxxxxxxxxxxxxxxxxxx] > Sent: Sunday, December 26, 2021 7:10 AM > Ben Cotton <bcotton@xxxxxxxxxx> writes: > > *snip* > > > > > It will also make Fedora able to detect tampering of its components at > > a more privileged level, the kernel, without the interference of user > > space programs. Once tampering has been detected, the actions of the > > altered component are prevented before that component gets the chance > > to perform any action. Fedora could be configured to also allow the > > usage of components provided by the user, if he wishes to do so > > (DIGLIM has a tool to build custom digest lists). > > How would that look in practice? Will a user just get a message in the > journal? Hi Dan the most visible change will be a permission denied (if IMA/IPE were configured in enforcing mode, similarly to SELinux). Both mechanisms have also an audit feature, which will print information about the permission denied event in the journal. Loading of altered components could also be just recorded in the journal. In this case, the system will lose access to a TPM key (if it was sealed a PCR updated with software measurements). Users will notice a change only when there is interaction with another entity (during remote attestation). If the compromised system is a client, that client will not be able anymore to get access to the server performing client authentication. If the compromised system is a server, it won't be able to prove its identity to its clients anymore. I developed a library for the remote attestation part. You can find more information here: https://gitee.com/openeuler/attest-tools/blob/master/README.en.md I thought about creating another Fedora feature, for remote attestation, that depends on this one. But maybe it is better to focus on the acceptance of this one. > > == Upgrade/compatibility impact == > > The user should ensure that software (not updated) from the old > > distribution is packaged and the package header is signed, or he > > should create and sign a custom digest list for the software he wishes > > to use after the upgrade. > > Uhm, so locally/manually installed software (i.e. not signed by Fedora's > signkeys) will silently break when switching to F36? How about 3rd party > repositories? This is the main point of the feature. It aims to protect the user against untracked software spread in the disk, and to make him accept the software he wants to run. Most likely, initially this process will be manual (there is a tool to generate a custom digest list). In the future, DIGLIM can be extended (in user space) to recognize the integrity information provided by the software developer. There is work to load additional keys to the kernel: https://lore.kernel.org/linux-integrity/20211124044124.998170-1-eric.snowberg@xxxxxxxxxx/ Likely, a solution to this problem will be found. Alternatively, it will be possible to configure IMA to do the integrity check only for root processes. In this case, the user will be able to run all his software. Roberto HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Li Peng, Zhong Ronghua > Cheers, > > Dan > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxxxxxxxxxx > Do not reply to spam on the list, report it: https://pagure.io/fedora- > infrastructure _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
