Hi everyone
(note for the infrastructure mailing list: please check if the changes I'm proposing could be tested in the Fedora infrastructure, like Copr)
I made the first version of the rpm extension to sign fsverity digests with a GPG key. The patch set (with some bug fixes) is available here:
https://github.com/robertosassu/rpm/commits/fsverity-gpg-v1
I tested it locally with my own GPG key. I took an existing Fedora 34 package and signed it with rpmsign:
$ usr/bin/rpmsign --define "%_gpg_name testhost testhost@test.test" \ --define "%_file_signing_key _GPG_" \ --define "%_file_signing_cert _GPG_" \ --addsign --signverity tmux-3.1c-2.fc34.x86_64.rpm
I then checked that the package has now fsverity signatures:
$ usr/bin/rpm -qp tmux-3.1c-2.fc34.x86_64.rpm \ --queryformat '[%{RPMTAG_FILENAMES} %{RPMTAG_VERITYSIGNATURES}\n]' [...] /usr/bin/tmux iQHHBAABCgAxFiEEEiFa0dGZVYzTrIN+rxtXRMfK0McFAmHq0+4THHRlc3Rob3N0 QHRlc3QudGVzdAAKCRCvG1dEx8rQx81nC/42NW9xJx3rcTiR6/5oL55GPkan+OIq t2dW1clJUOrxOGVy/5JQTQf0MQXA7gzH1yPgcrskkahjSfWlp4pt7oOw3rukUyaO zVZxue4XE6XESYtolczK4VEhpc8lbm4hj0e4NCg/dKri/+L5wIdJvmqWNeCfl7uZ [...]
In a VM I tried to install the modified package. The root filesystem is ext4 and has the fsverity feature enabled.
The fsverity rpm plugin is also enabled and hasn't been modified to work with the new PGP signatures.
The kernel includes the patch set I recently sent to the kernel mailing lists to add support for PGP keys and signatures:
https://lore.kernel.org/linux-integrity/20220111180318.591029-1-roberto.sass...
and another patch that calls verify_pgp_signature() in fs/verity/signature.c.
The first installation attempt fails, due to the missing key in the .fs-verity keyring:
# usr/bin/rpm -Uhvi ../tmux-3.1c-2.fc34.x86_64.rpm --debug [...] D: Plugin: calling hook fsm_file_prepare in fsverity plugin D: applying signature: [...] D: failed to enable verity (errno 126) for /usr/bin/tmux;61ead62d
Then, I added the required GPG key to the .fs-verity keyring:
# cat /mnt/repos/linux/certs/pubring.gpg | keyctl padd asymmetric test %keyring:.fs-verity 76292211
The key is now loaded:
# keyctl show %keyring:.fs-verity Keyring 66741466 --a-swrv 0 0 keyring: .fs-verity 76292211 --als--v 0 0 _ asymmetric: test
I retried the tmux installation:
# usr/bin/rpm -Uhvi ../tmux-3.1c-2.fc34.x86_64.rpm --debug [...] D: Plugin: calling hook fsm_file_prepare in fsverity plugin D: applying signature: [...] D: fsverity enabled signature for: path /usr/bin/tmux;61ead713 dest /usr/bin/tmux
This time the installation is successful, which means that the PGP signature has been successfully verified.
Roberto
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Li Peng, Zhong Ronghua
On Fri, Jan 21, 2022 at 04:08:04PM +0000, Roberto Sassu via devel wrote:
Hi everyone
(note for the infrastructure mailing list: please check if the changes I'm proposing could be tested in the Fedora infrastructure, like Copr)
copr uses a different signing setup... so probibly won't work there.
We could perhaps work with you to try and get it in our staging env to test, but I am not sure how involved that might be. I guess the first step would be filing a infratructure ticket and explain what you would need to change/test.
So, question for the change owners:
This is not enabled by default, I assume you wish to enable it for something, can you expand on what you will use it for and what that helps you with?
Also, is there any plan to enable it by default? Is there some way this could be useful to all our users? or more of our users?
This change and the DIGLIM change both feel to me like we are spending time and effort enabling something that only helps a tiny fraction of our users. Is there some way this could be more generally useful to our users?
kevin
From: Kevin Fenzi [mailto:kevin@scrye.com] Sent: Tuesday, January 25, 2022 7:30 PM On Fri, Jan 21, 2022 at 04:08:04PM +0000, Roberto Sassu via devel wrote:
Hi everyone
(note for the infrastructure mailing list: please check if the changes I'm proposing could be tested in the Fedora infrastructure, like Copr)
copr uses a different signing setup... so probibly won't work there.
We could perhaps work with you to try and get it in our staging env to test, but I am not sure how involved that might be. I guess the first step would be filing a infratructure ticket and explain what you would need to change/test.
Thanks, Kevin. Will do.
So, question for the change owners:
This is not enabled by default, I assume you wish to enable it for something, can you expand on what you will use it for and what that helps you with?
Also, is there any plan to enable it by default? Is there some way this could be useful to all our users? or more of our users?
This change and the DIGLIM change both feel to me like we are spending time and effort enabling something that only helps a tiny fraction of our users. Is there some way this could be more generally useful to our users?
I guess not many would use the remote attestation capability offered by DIGLIM (sealing a TPM key to the software running in the machine). The two scenarios in which that could be used are:
- web servers or other kind of servers where you, as client, would like the guarantee that your data is processed only if the software running in the server is not compromised
- closed networks where you, as network administrator, would like the guarantee that your clients can access those networks only if their software is not compromised
Probably, the secure boot functionality at application level is much more appealing, and less invasive. It should have almost zero impact if the users use their system for web browsing or writing. Although it is unlikely to happen, this feature prevents arbitrary execution of software, even by root. The trust anchor will be the kernel, and one would not have to rely on the correct execution of the package manager (and on its verification of the package signature).
If the users often make changes on their system, but confined to their environment, DIGLIM could still be helpful, as the damage of running arbitrary software will be limited to the users environment (no arbitrary software execution as root).
If the users often make changes on their system, with high privileges, I agree that DIGLIM would simply cause too much overhead for the configuration (every time the users make a change, they have to whitelist their software).
Roberto
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Li Peng, Zhong Ronghua
On Wed, 2022-01-26 at 09:25 +0000, Roberto Sassu via devel wrote:
...snip
If the users often make changes on their system, with high privileges, I agree that DIGLIM would simply cause too much overhead for the configuration (every time the users make a change, they have to whitelist their software).
Yeah that will definitely be a problem in my use cases. You know, if I wanted to have something interfere with my work, like Windows, I would just install Windows.
Stephen
Roberto
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Li Peng, Zhong Ronghua _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
infrastructure@lists.fedoraproject.org
-
Kevin Fenzi -
Roberto Sassu -
Stephen Snow