https://fedoraproject.org/wiki/Changes/DIGLIM
== Summary == Digest Lists Integrity Module (DIGLIM) provides a repository of file digests from authenticated sources, such as RPM headers, to be used by kernel services for remote attestation and/or secure boot at application level.
== Owner == * Name: [[User:robertosassu| Roberto Sassu]] * Email: roberto.sassu@huawei.com
== Detailed Description == Integrity Measurement Architecture (IMA), a kernel service for remote attestation and secure boot at application level, has been integrated in the kernel since a long time. However, two main barriers limited its wide adoption. First, it extends a Platform Control Register (PCR) of the Trusted Platform Module (TPM) in an unpredictable way (due to parallel execution of software), making it impossible to use that PCR for sealing policies of TPM keys. Second, it requires that a file signature is added to the package header for each file to be appraised.
Digest Lists Integrity Module (DIGLIM) takes a different approach. It allows IMA to extend a PCR in a predictable way or to verify the authenticity of files by querying an in-kernel repository of authenticated reference values, built from information already available in existing packages (FILEDIGESTS section of the RPM header, with signature in the RSAHEADER section). Data source authentication does not require additional key management. With support for PGP keys in the kernel, the official Fedora PGP keys can be imported to the builtin keyring of the kernel and used to verify the PGP signature of the RPM headers.
DIGLIM is not specifically tied to IMA. Since it is based on the hash table implementation of the kernel, it can store data of different types or be used by other kernel subsystems. It might for example store fsverity digests, to achieve the goal of another proposed [//fedoraproject.org/wiki/Changes/FsVerityRPM change] with less overhead (by adding to the RPM header digests instead of signatures). It might also be used by other kernel services, such as [//lore.kernel.org/linux-security-module/1634151995-16266-1-git-send-email-deven.desai@linux.microsoft.com/ Integrity Policy Enforcement (IPE)], a new LSM being proposed for inclusion in the upstream kernel.
A preliminary performance evaluation showed that DIGLIM does not introduce a significant overhead. A repository of executables and shared libraries digests, of a Fedora 33 minimal installation, occupies less than 800k of memory.
The new feature behaves as follows. A modified kernel with the DIGLIM patches will expose to user space an interface to add/remove file digests from the kernel hash table. A user space parser, executed by the kernel during early boot, parses RPM headers found in /etc/diglim in the initial ram disk (included with a custom dracut script) and uploads them to the kernel. When a file is accessed, IMA calculates the file digest and queries it with DIGLIM. If the digest is found, measurement is skipped and appraisal is successful. If the digest is not found, a measurement of the file is performed and appraisal fails. When packages are installed or removed, the kernel hash table is kept synchronized with a new rpm plugin.
== Feedback == DIGLIM has been proposed some time ago, and was previously known as IMA Digest Lists.
The original implementation was found to be too invasive, as both the management of the repository of reference values and the new measurement and appraisal mechanisms based on the query of the repository needed to coexist with the existing code. DIGLIM is now implemented as a standalone module, which includes the repository management part, and exposes a simple API so that IMA and other kernel services can use it to implement the query part (much simpler).
At the time IMA Digest Lists was published, the proposal of adding file signatures to the package header was deemed to be more mature and suitable for adoption. From [//pagure.io/fesco/issue/2547 previous] and [//lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/JE2HGLJMLEKUJW3YBP6MQJWP43CSTC57/ current] discussions, it seems that Linux distribution vendors are a bit reluctant to make such change, especially due to the increased size of the packages. DIGLIM just requires a modification of the kernel, rpm and dracut, and could work on old distribution versions once the modified packages are installed.
Another remote attestation-specific issue is that the approach of measuring only unknown software reduces the amount of information available to remote verifiers for the integrity evaluation of the system being attested. In particular, a measurement list made with the DIGLIM approach does not show which file have been actually accessed and when. This tradeoff was chosen to make the PCR value extended with software measurements predictable and to allow the usage of sealing policies based on that PCR.
== Benefit to Fedora == The main benefits of DIGLIM have been elaborated [//lore.kernel.org/linux-integrity/20210914163401.864635-1-roberto.sassu@huawei.com/ here].
Briefly summarizing: DIGLIM brings the benefits of kernel services for integrity detection (measurement) and protection (appraisal) to Linux distributions, and relieves the distributions from the burden of managing the integrity functionality.
More specifically, it will make a system running Fedora attestable without the need of using dedicated remote attestation protocols. In fact, the assertion that a system is running a specific set of software will be implicitly implied by the ability of that system to correctly respond to the other peer in the TLS handshake protocol. This could be achieved with widely available software such as the Apache web server, the tpm2 openssl engine and a browser. Also [//keylime.dev/ Keylime], a Red Hat-based solution for remote attestation, could make use of the proposed scheme.
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).
== Scope == * Proposal owners: ** Maintain the following patch sets for the Linux kernel, and possibly have them accepted in the upstream kernel: *** [//lore.kernel.org/linux-integrity/20210409114313.4073-1-roberto.sassu@huawei.com/ IMA execution policies] *** [//lore.kernel.org/linux-integrity/20210914163401.864635-1-roberto.sassu@huawei.com/ DIGLIM basic features] *** [//lore.kernel.org/linux-integrity/20210915163145.1046505-1-roberto.sassu@huawei.com/ DIGLIM advanced features] *** [//lore.kernel.org/linux-integrity/20210930115533.878169-1-roberto.sassu@huawei.com/ DIGLIM integration with IMA] *** [//lore.kernel.org/linux-integrity/20181112102423.30415-1-roberto.sassu@huawei.com/ PGP keys and signatures] *** Support for PGP appended signatures ** Port the [//gitee.com/src-openeuler/rpm/blob/master/Add-digest-list-plugin.patch digest_list rpm plugin] from openEuler to Fedora: ** Create dracut configuration file/module for copying RPM headers to the initial ram disk (optimization: copy only RPM headers related to files in the initial ram disk) ** Introduce [//gitee.com/openeuler/digest-list-tools/blob/master/scripts/setup_grub2 script]to enable IMA measurement/appraisal execution policies in the boot loader configuration:
* Other developers: ** Review the changes proposed above
* Release engineering: https://pagure.io/releng/issue/10473 ** Discuss with Release engineering team about the possibility of enabling IMA measurement and/or appraisal policies since first boot (a checkbox in Anaconda would cause the boot loader configuration to be updated to enable such policies) ** The feature might be enabled later by the user without any change required for the image generation
* Policies and guidelines: N/A
* Trademark approval: N/A
* Alignment with Objectives: Yes
== 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.
== How To Test == DIGLIM is already available for testing. A Fedora 34 kernel package with DIGLIM is available in this [//copr.fedorainfracloud.org/coprs/robertosassu/DIGLIM/ copr project].
The installation instructions have been published to the linux-integrity kernel mailing list [//lore.kernel.org/linux-integrity/48cd737c504d45208377daa27d625531@huawei.com/ here].
== User Experience == Both integrity detection and protection will be transparent for the user. For protection, the user will notice a change only if his actions (or of a malicious software on his behalf) are not in accordance with the integrity policy being enforced (e.g. the user executes an unknown binary).
== Dependencies ==
* kernel * rpm * dracut
The feature owner will be responsible to submit all the changes necessary and will not depend on other developers' work.
== Contingency Plan ==
* Contingency mechanism: remove provided patches from the packages * Contingency deadline: rebuilding the packages without the new patches can be done at any time * Blocks release? No
== Documentation ==
A comprehensive documentation can be found [//lore.kernel.org/linux-integrity/20210914163401.864635-1-roberto.sassu@huawei.com/ here].
== Release Notes ==
Release notes will be derived from the documentation.
Ben Cotton bcotton@redhat.com 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?
== 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?
Cheers,
Dan
From: Dan Čermák [mailto:dan.cermak@cgc-instruments.com] Sent: Sunday, December 26, 2021 7:10 AM Ben Cotton bcotton@redhat.com 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.snowber...
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@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
On Sunday, 26 December 2021 11:25:21 GMT Roberto Sassu via devel wrote:
From: Dan Čermák [mailto:dan.cermak@cgc-instruments.com] Sent: Sunday, December 26, 2021 7:10 AM Ben Cotton bcotton@redhat.com writes:
*snip*
== 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.
A concrete case:
I use Fedora, a third-party repository, and a private repository for my systems. The private repository is unsigned - it's just created via createrepo, and contains RPMs I've built with mock locally.
What do I need to do if this feature is accepted, in order to not see any impact? If I need to change any of the repositories I use and trust, can you point me to step-by-step instructions I need to follow?
On 26/12/2021 12:25, Roberto Sassu via devel wrote:
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.
And this feature will be disabled by 99% of Fedora users then, because the RPM Fusion repository is a must for the most of desktop users due to lack of modern audio/video decoders and NVIDIA drivers on Fedora.
On Sun, Dec 26, 2021 at 1:10 AM Dan Čermák dan.cermak@cgc-instruments.com wrote:
Ben Cotton bcotton@redhat.com 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?
== 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?
It wouldn't be the first time software has been deliberately broken by well-intended kernel security changes. Remember when systemd decided to cancel all backgrounded processes belong to a user when they logged out, breaking "screen" and "tux", with no record of killing the jobs whatsover? Fortunately, people screamed pretty hard about that one.
Nico Kadel-Garcia
Cheers,
Dan _______________________________________________ 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
Nico Kadel-Garcia wrote:
On Sun, Dec 26, 2021 at 1:10 AM Dan Čermák dan.cermak@cgc-instruments.com wrote:
Ben Cotton bcotton@redhat.com writes:
*snip*
== 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?
It wouldn't be the first time software has been deliberately broken by well-intended kernel security changes. Remember when systemd decided to cancel all backgrounded processes belong to a user when they logged out, breaking "screen" and "tux", with no record of killing the jobs whatsover? Fortunately, people screamed pretty hard about that one.
But being allowed to run custom or self-developed software is a core feature of Free Software. If that stops working in the name of "security", Fedora is no better than iOS (where Apple also claims the restrictions are for "security" purposes), and becomes entirely useless for me.
And the whole concept of "remote attestation" is inherently a Treacherous Computing (so-called "Trusted Computing") (mis)feature and as such entirely unacceptable to begin with.
This Change is absolutely unacceptable. If implemented as proposed (enabled by default), I will be forced to leave for another distribution (as a user, which however also implies that I will have to orphan all my packages).
Kevin Kofler
On Mon, Dec 27, 2021 at 05:50:25PM +0100, Kevin Kofler via devel wrote:
But being allowed to run custom or self-developed software is a core feature of Free Software. If that stops working in the name of "security", Fedora is no better than iOS (where Apple also claims the restrictions are for "security" purposes), and becomes entirely useless for me.
As I understand the proposal:
1. There is a mechanism for users to add their own digest lists, if they want. The change proposal could be a little more clear on how this would work.
2. The proposal calls for a checkbox in Anaconda to enable the feature. (We probably do not actually want a checkbox in Anaconda, though.) It also says "The feature might be enabled later by the user without any change required for the image generation" — which I think is primarily saying that the feature could be turned on without needing to remake the boot image, but which also seems to also say that it's not necessarily on by default.
Matthew Miller wrote:
- There is a mechanism for users to add their own digest lists, if they want. The change proposal could be a little more clear on how this would work.
There is no way I am going to jump through hoops to whitelist software I compiled myself, or installed from a third-party repository, out of a hardware-enforced vendor lock-in that attempts to deny me Freedom Zero (contradicting the "Freedom" in the "Four F's" of Fedora).
- The proposal calls for a checkbox in Anaconda to enable the feature. (We probably do not actually want a checkbox in Anaconda, though.) It also says "The feature might be enabled later by the user without any change required for the image generation" — which I think is primarily saying that the feature could be turned on without needing to remake the boot image, but which also seems to also say that it's not necessarily on by default.
Hopefully really only *by the user* and not, e.g., by the upgrade to a newer Fedora release.
But even off by default, I do not see how the "feature" implemented by this Change provides any value at all that does not contradict the very definition of Free Software.
Kevin Kofler
Il 28/12/21 04:28, Kevin Kofler via devel ha scritto:
Matthew Miller wrote:
- There is a mechanism for users to add their own digest lists, if they want. The change proposal could be a little more clear on how this would work.
There is no way I am going to jump through hoops to whitelist software I compiled myself, or installed from a third-party repository, out of a hardware-enforced vendor lock-in that attempts to deny me Freedom Zero (contradicting the "Freedom" in the "Four F's" of Fedora).
- The proposal calls for a checkbox in Anaconda to enable the feature. (We probably do not actually want a checkbox in Anaconda, though.) It also says "The feature might be enabled later by the user without any change required for the image generation" — which I think is primarily saying that the feature could be turned on without needing to remake the boot image, but which also seems to also say that it's not necessarily on by default.
Hopefully really only *by the user* and not, e.g., by the upgrade to a newer Fedora release.
But even off by default, I do not see how the "feature" implemented by this Change provides any value at all that does not contradict the very definition of Free Software.
Kevin Kofler
I do not see how this change goes against the definition of Free Software. It doesn't deny a user to install any software they want, it is about preventing unwanted/unsolicited/malevolent software from being installed without user (admin) approval.
From a workstation/desktop user perspective, this change sounds not really interesting, at least until there will be some robust integration with UI installers. And I personally appreciate it will be introduced as opt-in. But from an IT perspective running a server, I think it sounds good (I'm not IT manager myself). And since Fedora is RHEL playground...
Mattia
Mattia Verga via devel wrote:
I do not see how this change goes against the definition of Free Software. It doesn't deny a user to install any software they want, it is about preventing unwanted/unsolicited/malevolent software from being installed without user (admin) approval.
But there is the inherent assumption there that the set of software released by Fedora is identical to the set of software the user trusts. In practice, those sets will, sure, be overlapping (non-disjoint), but still distinct (non-identical). And I think they will differ sufficiently for it to be an issue.
Not only is there the issue of having to whitelist third-party or custom (second-party, i.e., installed by the local admin) software, but also not everything ever released by Fedora is necessarily safe to install either. E.g., an exploitable old version of a VNC server is most likely (and hopefully!) undesired on a company workstation, even the current version with no known vulnerabilities might not be wanted depending on the company policy.
The iOS-style centralized trust model simply does not work.
From a workstation/desktop user perspective, this change sounds not really interesting, at least until there will be some robust integration with UI installers. And I personally appreciate it will be introduced as opt-in. But from an IT perspective running a server, I think it sounds good (I'm not IT manager myself). And since Fedora is RHEL playground...
The question is how well this protects servers in practice. I guess it will stop exploits that drop executable binaries or shell scripts and attempt to run them (though, if even shell scripts need to be explicitly whitelisted, this is going to be a royal pain in the neck for system administrators), but it is not going to help against in-memory exploits of rightfully-installed server applications. Though I suppose those should be covered the existing protections such as NX, stack smashing protection, etc. (and also SELinux, if enabled with a policy for the server to be exploited actually present).
Kevin Kofler
On Tue, Dec 28, 2021 at 14:45:59 +0100, Kevin Kofler via devel devel@lists.fedoraproject.org wrote:
But there is the inherent assumption there that the set of software released by Fedora is identical to the set of software the user trusts. In practice, those sets will, sure, be overlapping (non-disjoint), but still distinct (non-identical). And I think they will differ sufficiently for it to be an issue.
I can tell you, I trust icecat a lot more than I trust firefox. But even that isn't black and white. This proposal divides software into good and not good categories. That really doesn't match how I use software.
On Tue, Dec 28, 2021 at 09:20:11AM -0600, Bruno Wolff III wrote:
On Tue, Dec 28, 2021 at 14:45:59 +0100, Kevin Kofler via devel devel@lists.fedoraproject.org wrote:
But there is the inherent assumption there that the set of software released by Fedora is identical to the set of software the user trusts. In practice, those sets will, sure, be overlapping (non-disjoint), but still distinct (non-identical). And I think they will differ sufficiently for it to be an issue.
I can tell you, I trust icecat a lot more than I trust firefox. But even that isn't black and white. This proposal divides software into good and not good categories. That really doesn't match how I use software.
This seems to presume DIGLIM is the only mechanism available. Admins running large fleets likely have other mechanisms that complement this, e.g. selective sync of repos with unapproved software excluded, enforcing minimum versions of packages to exclude versions known to have security vulnerabilities, etc.
If/when something like this gets shipped, I hope Fedora limits itself to shipping a policy that is the equivalent of SELinux's 'targeted' policy: protect the RPMs that Fedora ships from being tampered with, let users do whatever on top. With an option to turn it off completely or to enforce more strictly.
Best regards,
On 29/12/2021 21:53, Michel Alexandre Salim wrote:
If/when something like this gets shipped, I hope Fedora limits itself to shipping a policy that is the equivalent of SELinux's 'targeted' policy: protect the RPMs that Fedora ships from being tampered with, let users do whatever on top.
What about if the user wants to replace Fedora's version with another from mock/COPR?
This is a very common scenario. Most of Fedora packages can't be updated to the latest major version in stable releases due to Fedora Updates policy, and users install them from COPR.
From: Vitaly Zaitsev via devel [mailto:devel@lists.fedoraproject.org] Sent: Thursday, December 30, 2021 12:16 PM On 29/12/2021 21:53, Michel Alexandre Salim wrote:
If/when something like this gets shipped, I hope Fedora limits itself to shipping a policy that is the equivalent of SELinux's 'targeted' policy: protect the RPMs that Fedora ships from being tampered with, let users do whatever on top.
What about if the user wants to replace Fedora's version with another from mock/COPR?
I have a good example for that. I'm using myself a COPR repository to build the kernel package with the DIGLIM patches. That kernel also includes my own GPG key generated for me by COPR.
This has not been decided yet, but likely the Fedora kernel will contain the official Fedora keys, and the user will decide to add new keys (including those from COPR).
A simple way to find which keys you need will be from the RPM DB:
rpm -qa | grep gpg-pubkey-
Roberto
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Li Peng, Zhong Ronghua
On 30/12/2021 12:58, Roberto Sassu wrote:
This has not been decided yet, but likely the Fedora kernel will contain the official Fedora keys, and the user will decide to add new keys (including those from COPR).
1. What about self-built RPMs? I always build RPMs in mock and test them locally before submitting them to Koji as Fedora updates.
2. Such keys must be added/removed automatically with the corresponding COPR repositories.
On Fri, Dec 31, 2021 at 3:32 AM Vitaly Zaitsev via devel devel@lists.fedoraproject.org wrote:
On 30/12/2021 12:58, Roberto Sassu wrote:
This has not been decided yet, but likely the Fedora kernel will contain the official Fedora keys, and the user will decide to add new keys (including those from COPR).
- What about self-built RPMs? I always build RPMs in mock and test them
locally before submitting them to Koji as Fedora updates.
Sounds like, if this is enabled, they'll need a GPG key associated with their personal repository.
- Such keys must be added/removed automatically with the corresponding
COPR repositories.
Key management is one of the reasons GPG validation od deployed software has never really taken off.
On Sat, Jan 1, 2022 at 5:51 AM Vitaly Zaitsev via devel devel@lists.fedoraproject.org wrote:
On 31/12/2021 20:03, Nico Kadel-Garcia wrote:
Sounds like, if this is enabled, they'll need a GPG key associated with their personal repository.
Locally built packages are always unsigned.
They don't have to be, but yes, by default they are.
And note, you can already configure DNF to require GPG validation of local packages by setting localpkg_gpgcheck=1 in dnf.conf.
From: Neal Gompa [mailto:ngompa13@gmail.com] Sent: Saturday, January 1, 2022 3:47 PM On Sat, Jan 1, 2022 at 5:51 AM Vitaly Zaitsev via devel devel@lists.fedoraproject.org wrote:
On 31/12/2021 20:03, Nico Kadel-Garcia wrote:
Sounds like, if this is enabled, they'll need a GPG key associated with their personal repository.
Locally built packages are always unsigned.
They don't have to be, but yes, by default they are.
And note, you can already configure DNF to require GPG validation of local packages by setting localpkg_gpgcheck=1 in dnf.conf.
Hi everyone
first, Happy New Year!
I agree that if you are a developer, often installing new software for testing, this feature makes things harder.
If you are installing software in the main system and running it as root, yes, you would have to install your GPG key (or the certificate of your RSA key) in the kernel keyring. And also, you should use rpmsign to sign your RPMs before you install them (assuming that you want IMA appraisal and not just measurement).
If you are testing software as a regular user, then enforcing a policy only on root processes will not affect your work (you can test unsigned RPMs).
This feature will not block VMs, so also there you can test things without restriction. Currently, IMA does not support per container policy (it is under development), but in the future you would be able to test things in a container without restriction, and by having full enforcement on the root container.
Roberto
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Li Peng, Zhong Ronghua
Hi everyone
thanks for the comments. I try to answer in one email.
First, a clarification. Given that this feature is proposed for an open source distribution, its primary goal is to aid the users to satisfy their security needs, and let them decide how this will be done. It is not going to impose to users anything that they don't want to have. It will not be enabled by default in any case, even during an update to a newer Fedora version. It will let the users run anything they want to run.
Before talking about the changes in the workload when using third-party/private repositories, it seems to me that an important requirement is to not interfere with compiled applications, or customizations made by the user. A good compromise, as I mentioned, is to not check the software executed by regular users, but only for the critical processes executed as root. The damage of executing an untrusted binary will be (likely) confined in the user environment.
Reading the requirement of having third-party/private repositories (totally understandable), I realize that there must be a very clear documentation on how this case should be handled. The first point should be how to add the additional GPG keys to the kernel keyring, so that signature verification can be done. Since the RPM Fusion repository has the GPG keys (https://rpmfusion.org/keys), supporting the NVIDIA drivers or modern decoders should be possible. It could be even possible that a user installs his own GPG key (adequately protected), if he wants to sign customized software.
The second point, probably more complicated, is how to identify the files that should be added to the user-generated digest list. I implemented a simple solution to this problem, a tool scans the filesystem and creates a digest list with the files that are not in the digest lists already generated (including the RPM DB). This applies for anything that is not packaged. For the rest, the kernel will be automatically synchronized every time the package manager is executed (and at boot time) and it will be transparent for the user.
Just a brief note about remote attestation. I agree that we won't see soon a server we connect to with the browser proving that it is running the expected software configuration other than proving its identity. But in an enterprise network, this could be very useful. By periodically establishing a TLS connection with the nodes, you will immediately see if one node is compromised by seeing that that node is not able to respond in the handshake. I mentioned TLS because there is already a software (openssl-tpm2-engine) which takes care of the communication between openssl and the TPM. Something similar could be done for SSH.
Regarding the concern that DIGLIM is not in the upstream kernel, I understand. It went through several reviews, but a decision of including it was not made. Additional reviews, in the kernel mailing list, would certainly help. Also, the comments you made will help me to make DIGLIM better, by covering more use cases.
I believe that the quality of the patches is sufficiently good. I'm working on this feature for many years and a previous version of DIGLIM is already in production in our OS, openEuler. We gained a lot of experience, not only on the kernel part, but also on the complete lifecycle.
While DIGLIM could be downstream for just a Fedora version, in my opinion this would help to get more feedback from the users that could speed up the decision for upstream inclusion in the kernel.
If you are interested in the remote attestation part, made possible with DIGLIM, I give you few links:
Linux Security Summit Europe 2019 talk: https://youtu.be/mffdQgkvDNY
FutureTPM EU project final demo: https://vimeo.com/528251864/4c1d55abcd (video) https://futuretpm.eu/images/07-3-FutureTPM-Final-Review-Slides-WP6-Device-Ma... (slides)
Roberto
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Li Peng, Zhong Ronghua
On Tue, Dec 28, 2021 at 9:50 AM Roberto Sassu via devel devel@lists.fedoraproject.org wrote:
Hi everyone
thanks for the comments. I try to answer in one email.
First, a clarification. Given that this feature is proposed for an open source distribution, its primary goal is to aid the users to satisfy their security needs, and let them decide how this will be done. It is not going to impose to users anything that they don't want to have. It will not be enabled by default in any case, even during an update to a newer Fedora version. It will let the users run anything they want to run.
Before talking about the changes in the workload when using third-party/private repositories, it seems to me that an important requirement is to not interfere with compiled applications, or customizations made by the user. A good compromise, as I mentioned, is to not check the software executed by regular users, but only for the critical processes executed as root. The damage of executing an untrusted binary will be (likely) confined in the user environment.
Reading the requirement of having third-party/private repositories (totally understandable), I realize that there must be a very clear documentation on how this case should be handled. The first point should be how to add the additional GPG keys to the kernel keyring, so that signature verification can be done. Since the RPM Fusion repository has the GPG keys (https://rpmfusion.org/keys), supporting the NVIDIA drivers or modern decoders should be possible. It could be even possible that a user installs his own GPG key (adequately protected), if he wants to sign customized software.
The second point, probably more complicated, is how to identify the files that should be added to the user-generated digest list. I implemented a simple solution to this problem, a tool scans the filesystem and creates a digest list with the files that are not in the digest lists already generated (including the RPM DB). This applies for anything that is not packaged. For the rest, the kernel will be automatically synchronized every time the package manager is executed (and at boot time) and it will be transparent for the user.
Just a brief note about remote attestation. I agree that we won't see soon a server we connect to with the browser proving that it is running the expected software configuration other than proving its identity. But in an enterprise network, this could be very useful. By periodically establishing a TLS connection with the nodes, you will immediately see if one node is compromised by seeing that that node is not able to respond in the handshake. I mentioned TLS because there is already a software (openssl-tpm2-engine) which takes care of the communication between openssl and the TPM. Something similar could be done for SSH.
Regarding the concern that DIGLIM is not in the upstream kernel, I understand. It went through several reviews, but a decision of including it was not made. Additional reviews, in the kernel mailing list, would certainly help. Also, the comments you made will help me to make DIGLIM better, by covering more use cases.
I believe that the quality of the patches is sufficiently good. I'm working on this feature for many years and a previous version of DIGLIM is already in production in our OS, openEuler. We gained a lot of experience, not only on the kernel part, but also on the complete lifecycle.
While DIGLIM could be downstream for just a Fedora version, in my opinion this would help to get more feedback from the users that could speed up the decision for upstream inclusion in the kernel.
If you are interested in the remote attestation part, made possible with DIGLIM, I give you few links:
Linux Security Summit Europe 2019 talk: https://youtu.be/mffdQgkvDNY
FutureTPM EU project final demo: https://vimeo.com/528251864/4c1d55abcd (video) https://futuretpm.eu/images/07-3-FutureTPM-Final-Review-Slides-WP6-Device-Ma... (slides)
In general, Fedora does not include non-upstream functionality in its Linux kernel builds. This can be frustrating for development and cases where upstream requires downstream validation before upstream acceptance, but in this case, I recommend having a COPR build of the kernel with the patchset added.
It also looks like there's some userspace work that needs to be done too. It'd be good to have those patches reviewed by their respective upstreams sooner rather than later. For example, I haven't seen a PR proposed to RPM for the plugin.
I also agree that this feature is unlikely to affect people, as this feature will not be enabled by default. It would be extremely useful for people building Fedora-based appliances which need tamper protection for various reasons. And Fedora derivatives (like RHEL/CentOS, Amazon Linux, openEuler, etc.) can benefit from us having the functionality integrated even if we don't enable it by default.
Finally, I have trouble accessing gitee.com, can you put this stuff somewhere that is more accessible (like pagure.io, gitlab.com, or github.com)?
-- 真実はいつも一つ！/ Always, there's only one truth!
From: Neal Gompa [mailto:ngompa13@gmail.com] Sent: Tuesday, December 28, 2021 3:57 PM
[...]
In general, Fedora does not include non-upstream functionality in its Linux kernel builds. This can be frustrating for development and cases where upstream requires downstream validation before upstream acceptance, but in this case, I recommend having a COPR build of the kernel with the patchset added.
Here you can find my repository:
https://copr.fedorainfracloud.org/coprs/robertosassu/DIGLIM/
It is feature-complete, at least for the kernel part. If you install the package, you could see both IMA appraisal working on all files shipped with Fedora 34, and the deterministic IMA measurement list (with only the RPM headers, unless you execute something else).
The installation instructions are available here:
https://lore.kernel.org/linux-integrity/48cd737c504d45208377daa27d625531@hua...
I will provide more examples, how to add user-generated digest lists, based on our digest-list-tools, available here:
https://github.com/openeuler-mirror/digest-list-tools
It also looks like there's some userspace work that needs to be done too. It'd be good to have those patches reviewed by their respective upstreams sooner rather than later. For example, I haven't seen a PR proposed to RPM for the plugin.
Ok. Will do it, we already developed the code for openEuler.
I also agree that this feature is unlikely to affect people, as this feature will not be enabled by default. It would be extremely useful for people building Fedora-based appliances which need tamper protection for various reasons. And Fedora derivatives (like RHEL/CentOS, Amazon Linux, openEuler, etc.) can benefit from us having the functionality integrated even if we don't enable it by default.
Finally, I have trouble accessing gitee.com, can you put this stuff somewhere that is more accessible (like pagure.io, gitlab.com, or github.com)?
Sure. The README and the repository are also accessible here:
https://github.com/openeuler-mirror/attest-tools/blob/master/README.en.md
Roberto
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Li Peng, Zhong Ronghua
Hi,
I'm still reading the discussion, so just a short meta-comment on grammar: please don't use masculine forms to describe all Fedora users, we're not all guys…
On Tue, Dec 28, 2021 at 02:49:43PM +0000, Roberto Sassu via devel wrote:
It could be even possible that a user installs his own GPG key (adequately protected), if he wants to sign customized software.
…*their* own GPG key, if *they* want to to customized software…
Zbyszek
From: Zbigniew Jędrzejewski-Szmek [mailto:zbyszek@in.waw.pl] Sent: Wednesday, December 29, 2021 2:36 PM Hi,
I'm still reading the discussion, so just a short meta-comment on grammar: please don't use masculine forms to describe all Fedora users, we're not all guys…
On Tue, Dec 28, 2021 at 02:49:43PM +0000, Roberto Sassu via devel wrote:
It could be even possible that a user installs his own GPG key (adequately protected), if he wants to sign customized software.
…*their* own GPG key, if *they* want to to customized software…
Hi Zbyszek
thanks for pointing out. Will keep in mind for the next messages.
Roberto
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Li Peng, Zhong Ronghua
On Tue, Dec 28, 2021 at 4:35 AM Mattia Verga via devel devel@lists.fedoraproject.org wrote:
Il 28/12/21 04:28, Kevin Kofler via devel ha scritto:
Matthew Miller wrote:
- There is a mechanism for users to add their own digest lists, if they want. The change proposal could be a little more clear on how this would work.
There is no way I am going to jump through hoops to whitelist software I compiled myself, or installed from a third-party repository, out of a hardware-enforced vendor lock-in that attempts to deny me Freedom Zero (contradicting the "Freedom" in the "Four F's" of Fedora).
- The proposal calls for a checkbox in Anaconda to enable the feature. (We probably do not actually want a checkbox in Anaconda, though.) It also says "The feature might be enabled later by the user without any change required for the image generation" — which I think is primarily saying that the feature could be turned on without needing to remake the boot image, but which also seems to also say that it's not necessarily on by default.
Hopefully really only *by the user* and not, e.g., by the upgrade to a newer Fedora release.
But even off by default, I do not see how the "feature" implemented by this Change provides any value at all that does not contradict the very definition of Free Software.
Kevin KoflerI do not see how this change goes against the definition of Free Software. It doesn't deny a user to install any software they want, it is about preventing unwanted/unsolicited/malevolent software from being installed without user (admin) approval.
This looks like pure DRM. While there are security benefits to controlling access to data or to executables, doing so deep in the kernel takes away too much desirable freedom.
Nico Kadel-Garcia
On 12/28/21 16:45, Nico Kadel-Garcia wrote:
On Tue, Dec 28, 2021 at 4:35 AM Mattia Verga via devel devel@lists.fedoraproject.org wrote:
Il 28/12/21 04:28, Kevin Kofler via devel ha scritto:
But even off by default, I do not see how the "feature" implemented by this Change provides any value at all that does not contradict the very definition of Free Software.
Kevin KoflerI do not see how this change goes against the definition of Free Software. It doesn't deny a user to install any software they want, it is about preventing unwanted/unsolicited/malevolent software from being installed without user (admin) approval.
This looks like pure DRM. While there are security benefits to controlling access to data or to executables, doing so deep in the kernel takes away too much desirable freedom.
How is this taking away any freedom? You, as the owner of the computer, are free to enable or disable or reconfigure this security system as you please. No one is forcing you to use it. Why is it bad that it's implemented in the kernel? If it wasn't, it probably wouldn't be very useful.
On Tue, Dec 28, 2021 at 8:07 PM Samuel Sieb samuel@sieb.net wrote:
On 12/28/21 16:45, Nico Kadel-Garcia wrote:
On Tue, Dec 28, 2021 at 4:35 AM Mattia Verga via devel devel@lists.fedoraproject.org wrote:
Il 28/12/21 04:28, Kevin Kofler via devel ha scritto:
But even off by default, I do not see how the "feature" implemented by this Change provides any value at all that does not contradict the very definition of Free Software.
Kevin KoflerI do not see how this change goes against the definition of Free Software. It doesn't deny a user to install any software they want, it is about preventing unwanted/unsolicited/malevolent software from being installed without user (admin) approval.
This looks like pure DRM. While there are security benefits to controlling access to data or to executables, doing so deep in the kernel takes away too much desirable freedom.
How is this taking away any freedom? You, as the owner of the computer, are free to enable or disable or reconfigure this security system as you please. No one is forcing you to use it. Why is it bad that it's implemented in the kernel? If it wasn't, it probably wouldn't be very useful.
From one of the patches:
It accomplishes this task by storing reference values coming from software vendors and by reporting whether or not the digest of file content or metadata calculated by IMA (or EVM) is found among those values.
That has no use but digital rights management.
From: Nico Kadel-Garcia [mailto:nkadel@gmail.com] Sent: Wednesday, December 29, 2021 10:29 AM
[...]
From one of the patches:
It accomplishes this task by storing reference values coming fromsoftware vendors and by reporting whether or not the digest of file content or metadata calculated by IMA (or EVM) is found among those values.
That has no use but digital rights management.
Hi Nico
I give some clarifications.
The kernel won't enforce any policy unless you define it. Without loading a policy, there will be no change in your user experience.
I mentioned in the patches software vendors, as they would be the primary source of digest lists, easy to obtain. However, as an advanced user, you would be able to effectively use DIGLIM, even if you build your OS from scratch, by creating a digest list of the binaries you built.
This will be possible because you will have the ability to load your own GPG (or RSA) keys to the kernel to verify data source authenticity of the digest lists.
This applies if you want to enforce an IMA appraisal policy, which denies access to the files if file verification fails. If you want to enforce an IMA measurement policy instead, access to the files will be always granted, regardless of whether the digest lists are signed or not. IMA, in this case, will simply record the execution of unknown files, in addition to the digest lists you generated.
The IMA measurement list remains in your system, unless you decide that your system should be remotely attested by a remote verifier.
Roberto
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Li Peng, Zhong Ronghua
On Wed, Dec 29, 2021 at 5:42 AM Roberto Sassu via devel devel@lists.fedoraproject.org wrote:
From: Nico Kadel-Garcia [mailto:nkadel@gmail.com] Sent: Wednesday, December 29, 2021 10:29 AM
[...]
From one of the patches:
It accomplishes this task by storing reference values coming fromsoftware vendors and by reporting whether or not the digest of file content or metadata calculated by IMA (or EVM) is found among those values.
That has no use but digital rights management.
Hi Nico
I give some clarifications.
You've been very clear. To wit:
This applies if you want to enforce an IMA appraisal policy, which denies access to the files if file verification fails. I
That is also spelled "DRM", The idea that only code approved by a third party is permitted access to specific files violates the core principles of "free software". Putting the code in the kernel makes it more awkward for ordinary users to access the data and software on their own computers.
This will be possible because you will have the ability to load your own GPG (or RSA) keys to the kernel to verify data source authenticity of the digest lists.
There is no need to do this in the kernel. It can happen in userland.
This applies if you want to enforce an IMA appraisal policy, which denies access to the files if file verification fails. If you
Replace the word "IMA" with DRM everywhere to understand the end goal of such features. I'm sorry if I seem a bit vehement about this. We saw this attempted with Palladium or "Trusted Computing" for boot loaders, and it wasted a lot of time for features that were defeated pretty easily in the end by virtualization.
want to enforce an IMA measurement policy instead, access to the files will be always granted, regardless of whether the digest lists are signed or not. IMA, in this case, will simply record the execution of unknown files, in addition to the digest lists you generated.
The IMA measurement list remains in your system, unless you decide that your system should be remotely attested by a remote verifier.
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
On Wed, Dec 29, 2021 at 6:06 AM Nico Kadel-Garcia nkadel@gmail.com wrote:
On Wed, Dec 29, 2021 at 5:42 AM Roberto Sassu via devel devel@lists.fedoraproject.org wrote:
From: Nico Kadel-Garcia [mailto:nkadel@gmail.com] Sent: Wednesday, December 29, 2021 10:29 AM
[...]
From one of the patches:
It accomplishes this task by storing reference values coming fromsoftware vendors and by reporting whether or not the digest of file content or metadata calculated by IMA (or EVM) is found among those values.
That has no use but digital rights management.
Hi Nico
I give some clarifications.
You've been very clear. To wit:
This applies if you want to enforce an IMA appraisal policy, which denies access to the files if file verification fails. I
That is also spelled "DRM", The idea that only code approved by a third party is permitted access to specific files violates the core principles of "free software". Putting the code in the kernel makes it more awkward for ordinary users to access the data and software on their own computers.
This will be possible because you will have the ability to load your own GPG (or RSA) keys to the kernel to verify data source authenticity of the digest lists.
There is no need to do this in the kernel. It can happen in userland.
This applies if you want to enforce an IMA appraisal policy, which denies access to the files if file verification fails. If you
Replace the word "IMA" with DRM everywhere to understand the end goal of such features. I'm sorry if I seem a bit vehement about this. We saw this attempted with Palladium or "Trusted Computing" for boot loaders, and it wasted a lot of time for features that were defeated pretty easily in the end by virtualization.
Were they really? TPM devices *are* commonly used today to support attestation and multi-factor encryption and authentication mechanisms. In many ways, the trusted computing initiative was a success. And even virtualization is used for implementing trusted computing in some platforms.
With Windows 11, they're *mandatory*. Corporate policies now effectively *require* TPM-based mechanisms *in addition* to classical password or token-based multi-factor authentication.
The difference between IMA/verity and DRM is that the former is under the system owner's control (in this case, *you*), and the latter is *not*.
While Palladium as a whole hasn't *yet* made it, huge chunks of it has. Verified and measured boot mechanisms exist in Windows and macOS, remote and local attestation for integrity exist for Windows, and so on. Some of these features exist in Linux, but not all just yet.
There is a ton of value in user-controlled versions of this capability. And again, none of this is on by default, it's up to *you* to turn it on.
On Wed, Dec 29, 2021 at 6:39 AM Neal Gompa ngompa13@gmail.com wrote:
On Wed, Dec 29, 2021 at 6:06 AM Nico Kadel-Garcia nkadel@gmail.com wrote:
On Wed, Dec 29, 2021 at 5:42 AM Roberto Sassu via devel devel@lists.fedoraproject.org wrote:
From: Nico Kadel-Garcia [mailto:nkadel@gmail.com] Sent: Wednesday, December 29, 2021 10:29 AM
[...]
From one of the patches:
It accomplishes this task by storing reference values coming fromsoftware vendors and by reporting whether or not the digest of file content or metadata calculated by IMA (or EVM) is found among those values.
That has no use but digital rights management.
Hi Nico
I give some clarifications.
You've been very clear. To wit:
This applies if you want to enforce an IMA appraisal policy, which denies access to the files if file verification fails. I
That is also spelled "DRM", The idea that only code approved by a third party is permitted access to specific files violates the core principles of "free software". Putting the code in the kernel makes it more awkward for ordinary users to access the data and software on their own computers.
This will be possible because you will have the ability to load your own GPG (or RSA) keys to the kernel to verify data source authenticity of the digest lists.
There is no need to do this in the kernel. It can happen in userland.
This applies if you want to enforce an IMA appraisal policy, which denies access to the files if file verification fails. If you
Replace the word "IMA" with DRM everywhere to understand the end goal of such features. I'm sorry if I seem a bit vehement about this. We saw this attempted with Palladium or "Trusted Computing" for boot loaders, and it wasted a lot of time for features that were defeated pretty easily in the end by virtualization.
Were they really? TPM devices *are* commonly used today to support attestation and multi-factor encryption and authentication mechanisms. In many ways, the trusted computing initiative was a success. And even virtualization is used for implementing trusted computing in some platforms.
With Windows 11, they're *mandatory*. Corporate policies now effectively *require* TPM-based mechanisms *in addition* to classical password or token-based multi-factor authentication.
As often occurs with DRM. it's proven burdensome and there are numerous published workarounds, including those published by Microsoft.
Can you point to a particular multi-factor authentication technology that uses TPM? I'd not seen that in any server based setups, though I could believe it exists for portable devices which support less development. It's a problem partly because TPM puts private escrow keys in the centralized hands, and the root keys to revoke other keys in manufacturer's hands. The key management, and signature authority management, is a problem. I'd be concerned at yet another attempt to re-invent the security wheel, and secrete the wheel itself away in the kernel without direct visibility to the user running or writing the software.
The difference between IMA/verity and DRM is that the former is under the system owner's control (in this case, *you*), and the latter is *not*.
Since IMA is oriented to third party vendor keys, according to its own documentation, I don't see how this would be. It would be easier, and more visible, for signature validation and verification to occur in userspace. There are old tools that attempted to provide such validation for system files, such as "chkrootkit". and for which I've provided up-to-date bundling.
The work of signing and validating one's own data or software files is so large, I don't see the benefit of embedding it in the kernel except to enforce it for DRM use.
While Palladium as a whole hasn't *yet* made it, huge chunks of it has. Verified and measured boot mechanisms exist in Windows and macOS, remote and local attestation for integrity exist for Windows, and so on. Some of these features exist in Linux, but not all just yet.
Nor should they, precisely for "free software" reasons. Palladium was an attempt to provide a hardware verified, vendor signed stack from boot to kernel to software to data files, all under the authority of third-party generated signatures which could be revoked, at whim, by a more root level authority, and which could be revoked or even turned over from escrow at whim with no published procedure for when and how such keys would be turned over. I'm concerned that these third-part keys will suffer similar vulnerabilities.
There is a ton of value in user-controlled versions of this capability. And again, none of this is on by default, it's up to *you* to turn it on.
Then why bother pursuing it in the kernel? Why not provide these tools in userland, for optional activation? I hope you understand my deep suspicion: this sounds like a replay of inefficiently and inconsistently applied Trusted Computing features, and would seem to provide only another hurdle.
From: Nico Kadel-Garcia [mailto:nkadel@gmail.com] Sent: Wednesday, December 29, 2021 2:06 PM
[...]
With Windows 11, they're *mandatory*. Corporate policies now effectively *require* TPM-based mechanisms *in addition* to classical password or token-based multi-factor authentication.
As often occurs with DRM. it's proven burdensome and there are numerous published workarounds, including those published by Microsoft.
Can you point to a particular multi-factor authentication technology that uses TPM? I'd not seen that in any server based setups, though I could believe it exists for portable devices which support less development. It's a problem partly because TPM puts private escrow keys in the centralized hands, and the root keys to revoke other keys in manufacturer's hands. The key management, and signature authority management, is a problem. I'd be concerned at yet another attempt to re-invent the security wheel, and secrete the wheel itself away in the kernel without direct visibility to the user running or writing the software.
The TPM has a fundamental advantage, compared to other mechanisms. It is tamperproof, it often receives high-grade certifications, and it is one of the few components that you could rely on to protect your sensitive data in the event your host becomes compromised.
The fact that the TPM might be used for DRM does not preclude its usage for the users themselves. The TPM technology is not meant to secrete the wheel, but rather the opposite. For example, it might help to detect tampering of audit logs by attackers trying to cover their tracks.
The TPM has a very simple logic: record a security-relevant event before it happens, or do/release something if the system is in the condition I have myself defined.
The TPM might not be even required if you like to enforce an IMA appraisal policy. The built-in and secondary keyrings in the kernel will act as your trust anchor.
The difference between IMA/verity and DRM is that the former is under the system owner's control (in this case, *you*), and the latter is *not*.
Since IMA is oriented to third party vendor keys, according to its own documentation, I don't see how this would be. It would be easier, and more visible, for signature validation and verification to occur in userspace. There are old tools that attempted to provide such validation for system files, such as "chkrootkit". and for which I've provided up-to-date bundling.
It would be a design problem. You cannot put a component at the same privilege level of the components you are defending against.
The work of signing and validating one's own data or software files is so large, I don't see the benefit of embedding it in the kernel except to enforce it for DRM use.
While Palladium as a whole hasn't *yet* made it, huge chunks of it has. Verified and measured boot mechanisms exist in Windows and macOS, remote and local attestation for integrity exist for Windows, and so on. Some of these features exist in Linux, but not all just yet.
Nor should they, precisely for "free software" reasons. Palladium was an attempt to provide a hardware verified, vendor signed stack from boot to kernel to software to data files, all under the authority of third-party generated signatures which could be revoked, at whim, by a more root level authority, and which could be revoked or even turned over from escrow at whim with no published procedure for when and how such keys would be turned over. I'm concerned that these third-part keys will suffer similar vulnerabilities.
For IMA appraisal, there will be no keys in the kernel other than the ones your package manager uses to verify the integrity of the packages you install. Plus your own keys, if you wish. That would be sufficient to run any free software.
Roberto
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Li Peng, Zhong Ronghua
On 29/12/2021 15:20, Roberto Sassu via devel wrote:
The TPM has a fundamental advantage, compared to other mechanisms. It is tamperproof, it often receives high-grade certifications, and it is one of the few components that you could rely on to protect your sensitive data in the event your host becomes compromised.
https://arstechnica.com/gadgets/2021/08/how-to-go-from-stolen-pc-to-network-...
From: Vitaly Zaitsev via devel [mailto:devel@lists.fedoraproject.org] Sent: Thursday, December 30, 2021 12:18 PM On 29/12/2021 15:20, Roberto Sassu via devel wrote:
The TPM has a fundamental advantage, compared to other mechanisms. It is tamperproof, it often receives high-grade certifications, and it is one of the few components that you could rely on to protect your sensitive data in the event your host becomes compromised.
https://arstechnica.com/gadgets/2021/08/how-to-go-from-stolen-pc-to- network-intrusion-in-30-minutes/
If I understood the article correctly, the communication was spoofed due to not using the encrypted session feature of the TPM. The TPM also supports protection against tampering of the communication with the HMAC session.
Roberto
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Li Peng, Zhong Ronghua
On 29/12/2021 12:38, Neal Gompa wrote:
Were they really? TPM devices*are* commonly used today to support attestation and multi-factor encryption and authentication mechanisms. In many ways, the trusted computing initiative was a success. And even virtualization is used for implementing trusted computing in some platforms.
All hardware TPM implementations are proprietary. We can't trust them.
On Wed, Dec 29, 2021 at 7:39 AM Vitaly Zaitsev via devel devel@lists.fedoraproject.org wrote:
On 29/12/2021 12:38, Neal Gompa wrote:
Were they really? TPM devices*are* commonly used today to support attestation and multi-factor encryption and authentication mechanisms. In many ways, the trusted computing initiative was a success. And even virtualization is used for implementing trusted computing in some platforms.
All hardware TPM implementations are proprietary. We can't trust them.
CPU is proprietary, the firmware is proprietary. Guess we can't trust our computers?
On Thu, Dec 30, 2021 at 12:19:14 +0100, Vitaly Zaitsev via devel devel@lists.fedoraproject.org wrote:
On 30/12/2021 09:21, Chris Murphy wrote:
CPU is proprietary, the firmware is proprietary. Guess we can't trust our computers?
RISC-V.
RISC-V isn't the answer. It is an ISA (with varients), not a computer. A RISC-V based computer has the same issues as other computers.
Computers can be trusted to some extent, because useful, hard to detect misexecution is hard outside of some special instructions (such as random number generators).
You can purchase computers today without proprietary firmware in key areas. (Essentially you can limit proprietary firmware to denial of service attacks.) Look into Raptor Computering Services Blackbird or Talos 2 power 9 based systems if you are interested. These are not cheap consumer machines; so they aren't for everyone.
You can go lower down the stack and use free computer implementations. For example Microwatt is a power ISA implementation for FPGAs. You still have to worry about trusting FPGAs, but you can do more about that than you can with proprietary computers. Bunny Huang has written about trusting FPGAs as part of his precursor project.
On Wed, 2021-12-29 at 06:38 -0500, Neal Gompa wrote:
With Windows 11, they're *mandatory*. Corporate policies now effectively *require* TPM-based mechanisms *in addition* to classical password or token-based multi-factor authentication.
This certainly is not any reason to adopt this for Fedora. So far in my life with TPM, it has been an annoyance that I find refreshing not to have to even contemplate with my Fedora Linux installation. I see no benefit for the Fedora Community and the Fedora Project it supports to follow the lead of the proprietary driven objectives. The only obvious one that comes to mind is the recent announcements of it's inclusion on traditionally proprietary OS vendor supplied hardware. This wreaks of "for profit" motivation.
Just my opinion on what I am reading here in the comments.
Regards, Stephen Snow
On Wed, Dec 29, 2021 at 11:03 AM Stephen Snow s40w5s@gmail.com wrote:
On Wed, 2021-12-29 at 06:38 -0500, Neal Gompa wrote:
With Windows 11, they're *mandatory*. Corporate policies now effectively *require* TPM-based mechanisms *in addition* to classical password or token-based multi-factor authentication.
This certainly is not any reason to adopt this for Fedora. So far in my life with TPM, it has been an annoyance that I find refreshing not to have to even contemplate with my Fedora Linux installation. I see no benefit for the Fedora Community and the Fedora Project it supports to follow the lead of the proprietary driven objectives. The only obvious one that comes to mind is the recent announcements of it's inclusion on traditionally proprietary OS vendor supplied hardware. This wreaks of "for profit" motivation.
Just my opinion on what I am reading here in the comments.
To be fully transparent, the reason I mentioned that stuff is that having the capability to do these things in Fedora Linux is key for growth and adoption in more circles. At no point do I want to have these features implemented in such a way that the user doesn't have the capability to control and self-authenticate their whole system. If we ever want Fedora Linux to displace Windows or macOS, we *need* to be able to satisfy people's security requirements, including so-called "zero trust" architectures.
But none of that has much to do with this Change, since this is about making it possible for a user to configure their system to enforce the integrity of the system based on RPM database information. As users of Fedora Linux systems, we *already* control the RPM database and the RPM signature trust directly, so *if* you turn it on, all it does is decrease the risk of external tampering.
On Wed, Dec 29, 2021 at 1:35 PM Neal Gompa ngompa13@gmail.com wrote:
On Wed, Dec 29, 2021 at 11:03 AM Stephen Snow s40w5s@gmail.com wrote:
On Wed, 2021-12-29 at 06:38 -0500, Neal Gompa wrote:
With Windows 11, they're *mandatory*. Corporate policies now effectively *require* TPM-based mechanisms *in addition* to classical password or token-based multi-factor authentication.
This certainly is not any reason to adopt this for Fedora. So far in my life with TPM, it has been an annoyance that I find refreshing not to have to even contemplate with my Fedora Linux installation. I see no benefit for the Fedora Community and the Fedora Project it supports to follow the lead of the proprietary driven objectives. The only obvious one that comes to mind is the recent announcements of it's inclusion on traditionally proprietary OS vendor supplied hardware. This wreaks of "for profit" motivation.
Just my opinion on what I am reading here in the comments.
To be fully transparent, the reason I mentioned that stuff is that having the capability to do these things in Fedora Linux is key for growth and adoption in more circles. At no point do I want to have these features implemented in such a way that the user doesn't have the capability to control and self-authenticate their whole system. If we ever want Fedora Linux to displace Windows or macOS, we *need* to be able to satisfy people's security requirements, including so-called "zero trust" architectures.
But none of that has much to do with this Change, since this is about making it possible for a user to configure their system to enforce the integrity of the system based on RPM database information. As users of Fedora Linux systems, we *already* control the RPM database and the RPM signature trust directly, so *if* you turn it on, all it does is decrease the risk of external tampering.
I'm staring at the introduction letter at: https://lore.kernel.org/linux-integrity/20210914163401.864635-1-roberto.sass... RPM headers are a *possible* use. I'd expect this to be used, very quickly, for other signed metadata for less benign uses.
Hi Kevin,
On Mon, Dec 27, 2021, at 11:50 AM, Kevin Kofler via devel wrote:
But being allowed to run custom or self-developed software is a core feature of Free Software. If that stops working in the name of "security", Fedora is no better than iOS (where Apple also claims the restrictions are for "security" purposes), and becomes entirely useless for me.
This blog entry I did a while ago touches on this: https://blog.verbum.org/2019/12/23/starting-from-open-and-foss/
I am obviously speaking for myself there, but I know at least some others on the Fedora CoreOS team agree.
It's funny because I have had to near-constantly battle the concept that Fedora CoreOS is somehow out to "restrict" people. Opinionated? Yes. But you can still replace the kernel, build from source, etc.
As the blog says, I think the only sane thing to do with file/partition integrity systems like this is to make them supported by Fedora to deploy for custom builds. Now there's a whole huge topic here that it's *really hard* to make a system that is both e.g. an ISO you can stick in and install easily *and* offer the whole toolbox of build (and CI!) tools as a "product" to users.
But anyways, it's good that you raise this point and concern, but there's no reason for you to worry.
Hi everyone
I recently sent to the kernel mailing lists a patch set to support PGP keys and signatures.
Other than allowing the appraisal of RPM headers without changes to the building infrastructure, it would also simplify key management for the use cases requiring file or fsverity signatures (no need for a secondary key).
This is the link of the patch set:
https://lore.kernel.org/linux-integrity/20220111180318.591029-1-roberto.sass...
One point of the discussion was if there is the need to support PGP in the kernel, or if a distribution should adapt its key management to be compatible with key types currently available in the kernel.
It would be great if you could comment on this patch set, from the perspective of people managing a Linux distribution. Also, any thought related to the patch set would be appreciated.
Thanks
Roberto
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Li Peng, Zhong Ronghua
From: Roberto Sassu Sent: Tuesday, January 18, 2022 3:36 PM Hi everyone
I recently sent to the kernel mailing lists a patch set to support PGP keys and signatures.
Other than allowing the appraisal of RPM headers without changes to the building infrastructure, it would also simplify key management for the use cases requiring file or fsverity signatures (no need for a secondary key).
This is the link of the patch set:
https://lore.kernel.org/linux-integrity/20220111180318.591029-1- roberto.sassu@huawei.com/
One point of the discussion was if there is the need to support PGP in the kernel, or if a distribution should adapt its key management to be compatible with key types currently available in the kernel.
I have a question related to this. Is the private key used to sign kernel modules available also when other packages are built?
Thanks
Roberto
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Li Peng, Zhong Ronghua
It would be great if you could comment on this patch set, from the perspective of people managing a Linux distribution. Also, any thought related to the patch set would be appreciated.
Thanks
Roberto
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Li Peng, Zhong Ronghua
On Wed, Jan 19, 2022 at 11:34:28AM +0000, Roberto Sassu via devel wrote:
From: Roberto Sassu Sent: Tuesday, January 18, 2022 3:36 PM Hi everyone
I recently sent to the kernel mailing lists a patch set to support PGP keys and signatures.
Other than allowing the appraisal of RPM headers without changes to the building infrastructure, it would also simplify key management for the use cases requiring file or fsverity signatures (no need for a secondary key).
This is the link of the patch set:
https://lore.kernel.org/linux-integrity/20220111180318.591029-1- roberto.sassu@huawei.com/
One point of the discussion was if there is the need to support PGP in the kernel, or if a distribution should adapt its key management to be compatible with key types currently available in the kernel.
I have a question related to this. Is the private key used to sign kernel modules available also when other packages are built?
Nope. My understanding is that this is only available during that kernel build and then disguarded. (But you could perhaps ask on fedora's kernel list about it for more info).
kevin
Hi everyone
I have very exciting news to share.
Given the difficulty to have the DIGLIM kernel patches accepted, I checked if I could achieve the same goals with an eBPF program.
I focused only on the functionality side, it is probably required some support from the kernel to have the same security guarantees of an LSM integrated in the kernel.
But, at least for the functionality part, I would say that thanks to the very extensive support from eBPF, I managed to almost match what I provided with the kernel patches (at least for appraisal, not for measurement).
This is the repo with the code:
https://github.com/robertosassu/diglim-ebpf
and the Copr project with binary packages:
https://copr.fedorainfracloud.org/coprs/robertosassu/DIGLIM-eBPF/
Unfortunately, due to a feature introduced only recently (allow sleepable programs to use the inode map), it will work only with Fedora 36. Probably, commit 0fe4b381a59e ("bpf: Allow bpf_local_storage to be used by sleepable programs) applied to the kernel 5.16 would be sufficient to use DIGLIM eBPF also in Fedora 35.
Unlike the previous version of DIGLIM, this one does not have any dependency (I just had to add rpmplugin.h in the rpm-devel package).
It can be configured with two simple commands (please do it in a testing VM):
# dnf copr enable robertosassu/DIGLIM-eBPF # diglim_setup.sh install --default
After reboot, the kernel will refuse to execute anything that is not in a package. Updating a package or installing new ones is supported, DIGLIM eBPF takes care of loading the new reference values.
Adding custom software is also possible, as shown with the following commands:
# ./script.sh -bash: ./script.sh: /bin/bash: bad interpreter: Operation not permitted # compact_gen -d /etc/digest_lists -i script.sh # diglim_user_client -o add -p /etc/digest_lists/0-file_list-compact-script.sh Digest list command successful # ./script.sh Hello world!
I know it is too late for Fedora 36, but I hope you could consider this version for Fedora 37. In the meantime, I will work on the security guarantees (signature verification of the digest lists, avoid unplugging of the LSM).
Any comment or suggestion is very appreciated!
Thanks
Roberto
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Li Peng, Zhong Ronghua
On Fri, Feb 18, 2022 at 4:27 PM Roberto Sassu via devel devel@lists.fedoraproject.org wrote:
Hi everyone
I have very exciting news to share.
Given the difficulty to have the DIGLIM kernel patches accepted, I checked if I could achieve the same goals with an eBPF program.
I focused only on the functionality side, it is probably required some support from the kernel to have the same security guarantees of an LSM integrated in the kernel.
But, at least for the functionality part, I would say that thanks to the very extensive support from eBPF, I managed to almost match what I provided with the kernel patches (at least for appraisal, not for measurement).
This is the repo with the code:
https://github.com/robertosassu/diglim-ebpf
and the Copr project with binary packages:
https://copr.fedorainfracloud.org/coprs/robertosassu/DIGLIM-eBPF/
Unfortunately, due to a feature introduced only recently (allow sleepable programs to use the inode map), it will work only with Fedora 36. Probably, commit 0fe4b381a59e ("bpf: Allow bpf_local_storage to be used by sleepable programs) applied to the kernel 5.16 would be sufficient to use DIGLIM eBPF also in Fedora 35.
Unlike the previous version of DIGLIM, this one does not have any dependency (I just had to add rpmplugin.h in the rpm-devel package).
It can be configured with two simple commands (please do it in a testing VM):
# dnf copr enable robertosassu/DIGLIM-eBPF # diglim_setup.sh install --default
After reboot, the kernel will refuse to execute anything that is not in a package. Updating a package or installing new ones is supported, DIGLIM eBPF takes care of loading the new reference values.
Adding custom software is also possible, as shown with the following commands:
# ./script.sh -bash: ./script.sh: /bin/bash: bad interpreter: Operation not permitted # compact_gen -d /etc/digest_lists -i script.sh # diglim_user_client -o add -p /etc/digest_lists/0-file_list-compact-script.sh Digest list command successful # ./script.sh Hello world!
I know it is too late for Fedora 36, but I hope you could consider this version for Fedora 37. In the meantime, I will work on the security guarantees (signature verification of the digest lists, avoid unplugging of the LSM).
Any comment or suggestion is very appreciated!
Thanks
Roberto
I seem to remember discussions about eBPF programs having certain limitations (related to kernel Lockdown patches and Secure Boot). Has this changed? Is running eBPF programs in stock Fedora (with Secure Boot enabled) possible now?
Fabio
(Secure Boot is concerned only with verifying the trustworthiness of the bootloader. From https://man7.org/linux/man-pages/man7/kernel_lockdown.7.html:
The Kernel Lockdown feature is designed to prevent both direct and indirect access to a running kernel image, attempting to protect against unauthorized modification of the kernel image and to prevent access to security and cryptographic data located in kernel memory, whilst still permitting driver modules to be loaded.
eBPF does not require loading additional kernel modules, perhaps you were thinking of systemtap?, nor does it need to modify the kernel image.)
To verify this works on current stable, you can try:
# hostnamectl | rg -i cpe CPE OS Name: cpe:/o:fedoraproject:fedora:35
# bootctl | rg -i secure.*boot systemd-boot not installed in ESP. Secure Boot: enabled
# cat /sys/kernel/security/lockdown none [integrity] confidentiality
# rpm -q bcc-tools bcc-tools-0.21.0-1.fc35.x86_64
# rpm -ql bcc-tools | rg bitesize /usr/share/bcc/tools/bitesize /usr/share/bcc/tools/doc/bitesize_example.txt /usr/share/man/man8/bcc-bitesize.8.gz
# /usr/share/bcc/tools/bitesize Tracing block I/O... Hit Ctrl-C to end. ^C Process Name = dmcrypt_write/2 Kbytes : count distribution 0 -> 1 : 0 | | 2 -> 3 : 0 | | 4 -> 7 : 195 |********** | 8 -> 15 : 42 |** | 16 -> 31 : 756 |****************************************| 32 -> 63 : 166 |******** | 64 -> 127 : 24 |* | 128 -> 255 : 5 | | 256 -> 511 : 99 |***** | ...
The bcc-tools package is a collection of eBPF programs ( https://github.com/iovisor/bcc).
Alternatively, the much simpler https://gist.github.com/lizrice/47ad44a15cce912502f8667a403f5649#file-hello_... (requires python3-bcc):
# cat << 'EOF' > hi.py #!/usr/bin/python from bcc import BPF
prog = """ int hello(void *ctx) { bpf_trace_printk("Hello world\n"); return 0; } """
b = BPF(text=prog) clone = b.get_syscall_fnname("clone") b.attach_kprobe(event=clone, fn_name="hello") b.trace_print()
EOF
# strace -e bpf ./hi.py
Hope that helps.
On Fri, Feb 18, 2022 at 6:50 PM Fabio Valentini decathorpe@gmail.com wrote:
On Fri, Feb 18, 2022 at 4:27 PM Roberto Sassu via devel devel@lists.fedoraproject.org wrote:
Hi everyone
I have very exciting news to share.
Given the difficulty to have the DIGLIM kernel patches accepted, I checked if I could achieve the same goals with an eBPF program.
I focused only on the functionality side, it is probably required some support from the kernel to have the same security guarantees of an LSM integrated in the kernel.
But, at least for the functionality part, I would say that thanks to the very extensive support from eBPF, I managed to almost match what I provided with the kernel patches (at least for appraisal, not for measurement).
This is the repo with the code:
https://github.com/robertosassu/diglim-ebpf
and the Copr project with binary packages:
https://copr.fedorainfracloud.org/coprs/robertosassu/DIGLIM-eBPF/
Unfortunately, due to a feature introduced only recently (allow sleepable programs to use the inode map), it will work only with Fedora 36. Probably, commit 0fe4b381a59e ("bpf: Allow bpf_local_storage to be used by sleepable programs) applied to the kernel 5.16 would be sufficient to use DIGLIM eBPF also in Fedora 35.
Unlike the previous version of DIGLIM, this one does not have any dependency (I just had to add rpmplugin.h in the rpm-devel package).
It can be configured with two simple commands (please do it in a testing VM):
# dnf copr enable robertosassu/DIGLIM-eBPF # diglim_setup.sh install --default
After reboot, the kernel will refuse to execute anything that is not in a package. Updating a package or installing new ones is supported, DIGLIM eBPF takes care of loading the new reference values.
Adding custom software is also possible, as shown with the following commands:
# ./script.sh -bash: ./script.sh: /bin/bash: bad interpreter: Operation not permitted # compact_gen -d /etc/digest_lists -i script.sh # diglim_user_client -o add -p
/etc/digest_lists/0-file_list-compact-script.sh
Digest list command successful # ./script.sh Hello world!
I know it is too late for Fedora 36, but I hope you could consider this version for Fedora 37. In the meantime, I will work on the security guarantees (signature verification of the digest lists, avoid unplugging of the LSM).
Any comment or suggestion is very appreciated!
Thanks
Roberto
I seem to remember discussions about eBPF programs having certain limitations (related to kernel Lockdown patches and Secure Boot). Has this changed? Is running eBPF programs in stock Fedora (with Secure Boot enabled) possible now?
Fabio _______________________________________________ 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
From: David Sastre [mailto:d.sastre.medina@gmail.com] Sent: Saturday, February 19, 2022 11:56 PM (Secure Boot is concerned only with verifying the trustworthiness of the bootloader. From https://man7.org/linux/man-pages/man7/kernel_lockdown.7.html: The Kernel Lockdown feature is designed to prevent both direct and indirect access to a running kernel image, attempting to protect against unauthorized modification of the kernel image and to prevent access to security and cryptographic data located in kernel memory, whilst still permitting driver modules to be loaded. eBPF does not require loading additional kernel modules, perhaps you were thinking of systemtap?, nor does it need to modify the kernel image.)
Thanks David.
If I remember correctly, there could be some limitations if the Lockdown LSM is in confidentiality mode. By default in Fedora it is in integrity mode.
I tried to run my eBPF in a system with secure boot enabled and it seems to work (there are some issues with how gnome-shell uses mmap(), I will fix them).
Roberto
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Li Peng, Zhong Ronghua
To verify this works on current stable, you can try:
# hostnamectl | rg -i cpe CPE OS Name: cpe:/o:fedoraproject:fedora:35
# bootctl | rg -i secure.*boot systemd-boot not installed in ESP. Secure Boot: enabled
# cat /sys/kernel/security/lockdown none [integrity] confidentiality
# rpm -q bcc-tools bcc-tools-0.21.0-1.fc35.x86_64
# rpm -ql bcc-tools | rg bitesize /usr/share/bcc/tools/bitesize /usr/share/bcc/tools/doc/bitesize_example.txt /usr/share/man/man8/bcc-bitesize.8.gz
# /usr/share/bcc/tools/bitesize Tracing block I/O... Hit Ctrl-C to end. ^C Process Name = dmcrypt_write/2 Kbytes : count distribution 0 -> 1 : 0 | | 2 -> 3 : 0 | | 4 -> 7 : 195 |********** | 8 -> 15 : 42 |** | 16 -> 31 : 756 |****************************************| 32 -> 63 : 166 |******** | 64 -> 127 : 24 |* | 128 -> 255 : 5 | | 256 -> 511 : 99 |***** | ...
The bcc-tools package is a collection of eBPF programs (https://github.com/iovisor/bcc).
Alternatively, the much simpler https://gist.github.com/lizrice/47ad44a15cce912502f8667a403f5649#file- hello_world-py
(requires python3-bcc):
# cat << 'EOF' > hi.py #!/usr/bin/python from bcc import BPF
prog = """ int hello(void *ctx) { bpf_trace_printk("Hello world\n"); return 0; } """
b = BPF(text=prog) clone = b.get_syscall_fnname("clone") b.attach_kprobe(event=clone, fn_name="hello") b.trace_print()
EOF
# strace -e bpf ./hi.py
Hope that helps.
On Fri, Feb 18, 2022 at 6:50 PM Fabio Valentini <decathorpe@gmail.com mailto:decathorpe@gmail.com > wrote:
On Fri, Feb 18, 2022 at 4:27 PM Roberto Sassu via devel <devel@lists.fedoraproject.org mailto:devel@lists.fedoraproject.org
wrote:
Hi everyone
I have very exciting news to share.
Given the difficulty to have the DIGLIM kernel patches accepted, I checked if I could achieve the same goals with an eBPF program.
I focused only on the functionality side, it is probably required some support from the kernel to have the same security guarantees of an LSM integrated in the kernel.
But, at least for the functionality part, I would say that thanks to the very extensive support from eBPF, I managed to almost match what I provided with the kernel patches (at least for appraisal, not for measurement).
This is the repo with the code:
https://github.com/robertosassu/diglim-ebpf
and the Copr project with binary packages:
https://copr.fedorainfracloud.org/coprs/robertosassu/DIGLIM-eBPF/
Unfortunately, due to a feature introduced only recently (allow sleepable programs to use the inode map), it will work only with Fedora 36. Probably, commit 0fe4b381a59e ("bpf: Allow bpf_local_storage to be used by sleepable programs) applied to the kernel 5.16 would be sufficient to use DIGLIM eBPF also in Fedora 35.
Unlike the previous version of DIGLIM, this one does not have any dependency (I just had to add rpmplugin.h in the rpm-devel package).
It can be configured with two simple commands (please do it in a testing VM):
# dnf copr enable robertosassu/DIGLIM-eBPF # diglim_setup.sh install --default
After reboot, the kernel will refuse to execute anything that is not in a package. Updating a package or installing new ones is supported, DIGLIM eBPF takes care of loading the new reference values.
Adding custom software is also possible, as shown with the following commands:
# ./script.sh -bash: ./script.sh: /bin/bash: bad interpreter: Operation not permitted # compact_gen -d /etc/digest_lists -i script.sh # diglim_user_client -o add -p /etc/digest_lists/0-file_list-compact-
script.sh
Digest list command successful # ./script.sh Hello world!
I know it is too late for Fedora 36, but I hope you could consider this version for Fedora 37. In the meantime, I will work on the security guarantees (signature verification of the digest lists, avoid unplugging of the LSM).
Any comment or suggestion is very appreciated!
Thanks
Roberto
I seem to remember discussions about eBPF programs having certain limitations (related to kernel Lockdown patches and Secure Boot). Has this changed? Is running eBPF programs in stock Fedora (with Secure Boot enabled) possible now?
Fabio _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org mailto:devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org mailto: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
From: Roberto Sassu via devel [mailto:devel@lists.fedoraproject.org] Sent: Friday, February 18, 2022 4:27 PM
[...]
Unlike the previous version of DIGLIM, this one does not have any dependency (I just had to add rpmplugin.h in the rpm-devel package).
It can be configured with two simple commands (please do it in a testing VM):
# dnf copr enable robertosassu/DIGLIM-eBPF
Sorry, forgot to add:
# dnf install diglim-ebpf
# diglim_setup.sh install --default
Roberto
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Li Peng, Zhong Ronghua
On Mon, Dec 27, 2021 at 08:18:17AM -0500, Nico Kadel-Garcia wrote:
On Sun, Dec 26, 2021 at 1:10 AM Dan Čermák dan.cermak@cgc-instruments.com wrote:
It wouldn't be the first time software has been deliberately broken by well-intended kernel security changes. Remember when systemd decided to cancel all backgrounded processes belong to a user when they logged out, breaking "screen" and "tux", with no record of killing the jobs whatsover? Fortunately, people screamed pretty hard about that one.
Not arguing either way, but just to clarify, systemd is not part of the kernel.
Best regards,
On Thu, 2021-12-16 at 17:27 -0500, Ben Cotton wrote:
== Scope ==
- Proposal owners:
** Maintain the following patch sets for the Linux kernel, and possibly have them accepted in the upstream kernel: *** [//lore.kernel.org/linux-integrity/20210409114313.4073-1-roberto.sassu@huawei.com/ IMA execution policies] *** [//lore.kernel.org/linux-integrity/20210914163401.864635-1-roberto.sassu@huawei.com/ DIGLIM basic features] *** [//lore.kernel.org/linux-integrity/20210915163145.1046505-1-roberto.sassu@huawei.com/ DIGLIM advanced features] *** [//lore.kernel.org/linux-integrity/20210930115533.878169-1-roberto.sassu@huawei.com/ DIGLIM integration with IMA] *** [//lore.kernel.org/linux-integrity/20181112102423.30415-1-roberto.sassu@huawei.com/ PGP keys and signatures]
For me this seems like kind of a non-starter unless these are merged upstream. I do not think it makes sense for Fedora to carry these patches downstream long-term. If this is a good implementation of a good feature, it should be merged upstream. If it isn't, we shouldn't carry it downstream.
On Mon, Dec 27 2021 at 11:04:01 PM -0800, Adam Williamson adamwill@fedoraproject.org wrote:
For me this seems like kind of a non-starter unless these are merged upstream. I do not think it makes sense for Fedora to carry these patches downstream long-term. If this is a good implementation of a good feature, it should be merged upstream. If it isn't, we shouldn't carry it downstream.
Yeah let's start by getting the code upstream, that would be step one before proposing a Fedora change proposal.
On Tue, Dec 28, 2021 at 9:44 AM Michael Catanzaro mcatanzaro@gnome.org wrote:
On Mon, Dec 27 2021 at 11:04:01 PM -0800, Adam Williamson adamwill@fedoraproject.org wrote:
For me this seems like kind of a non-starter unless these are merged upstream. I do not think it makes sense for Fedora to carry these patches downstream long-term. If this is a good implementation of a good feature, it should be merged upstream. If it isn't, we shouldn't carry it downstream.
Yeah let's start by getting the code upstream, that would be step one before proposing a Fedora change proposal.
I'm fine with the Change proposal being made, as it gives us a holistic view of things. We can always pre-condition it on the code being upstreamed and then proceed with the rest of the enablement.
On Thu, Dec 16, 2021 at 17:27:29 -0500, Ben Cotton bcotton@redhat.com wrote:
https://fedoraproject.org/wiki/Changes/DIGLIM
More specifically, it will make a system running Fedora attestable without the need of using dedicated remote attestation protocols. In fact, the assertion that a system is running a specific set of software will be implicitly implied by the ability of that system to correctly respond to the other peer in the TLS handshake protocol. This could be achieved with widely available software such as the Apache web server, the tpm2 openssl engine and a browser. Also [//keylime.dev/ Keylime], a Red Hat-based solution for remote attestation, could make use of the proposed scheme.
This doesn't seem very useful for the vast majority of people. The software set is going to change pretty often via updates and it will vary from user to user based on what they have installed. It might make sense in a case where you have a lot of machines you want to ensure are set up identically.
I mostly interact with my machines remotely via ssh, not tls. ssh provides a way to attest I am connecting to the expected machine already. Tampering is prevented by encrypting the disk.
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).
Does this work with code that is run by an interpreter? If not, it doesn't seem to make sense to not check interpreted code, while making users jump through hoops to run compiled code.
Having to sign code to run it is going to be way too much work for many Fedora users. I think doing test builds of packages would be a nightmare since the "make" (or similar system) for packages is not going to be setup to stop part way through and sign code.
As far as I can tell, the threat model this is trying to protect against is not one that I care about.
Threats that I think would find worth addressing, if it can be done practically, are evil maid attacks (both capturing the disk encryption password during boot and my password when logging in locally) and being able to easily run software that is limited to just some of my rights, instead of all of them. SELinux can help with the latter, but it isn't easy to set up custom sandboxes for software.
Ben Cotton wrote:
** Maintain the following patch sets for the Linux kernel, and possibly have them accepted in the upstream kernel:
[//lore.kernel.org/linux-integrity/20210409114313.4073-1-
roberto.sassu@huawei.com/
IMA execution policies] *** [//lore.kernel.org/linux-integrity/20210914163401.864635-1-
roberto.sassu@huawei.com/
DIGLIM basic features] *** [//lore.kernel.org/linux-integrity/20210915163145.1046505-1-
roberto.sassu@huawei.com/
DIGLIM advanced features] *** [//lore.kernel.org/linux-integrity/20210930115533.878169-1-
roberto.sassu@huawei.com/
DIGLIM integration with IMA] *** [//lore.kernel.org/linux-integrity/20181112102423.30415-1-
roberto.sassu@huawei.com/
PGP keys and signatures]
Can we trust the security code submitted by a Huawei employee to not contain hidden government-developed backdoors? (Basically the same question as for the existing NSA SELinux code…)
Kevin Kofler
On Tue, Dec 28 2021 at 02:51:35 PM +0100, Kevin Kofler via devel devel@lists.fedoraproject.org wrote:
Can we trust the security code submitted by a Huawei employee to not contain hidden government-developed backdoors? (Basically the same question as for the existing NSA SELinux code…)
I'm going to suggest we evaluate the proposal based on its technical merits only.
On Tue, Dec 28, 2021 at 14:51:35 +0100, Kevin Kofler via devel devel@lists.fedoraproject.org wrote:
Can we trust the security code submitted by a Huawei employee to not contain hidden government-developed backdoors? (Basically the same question as for the existing NSA SELinux code…)
I think that same question could be asked of all of us. I don't see that his contributions need extra scrutiny because he claims to work for Huawei. Though they might because they are security related.
The gist of the proposal is described thus:
The new feature behaves as follows. A modified kernel with the DIGLIM patches will expose to user space an interface to add/remove file digests from the kernel hash table. A user space parser, executed by the kernel during early boot, parses RPM headers found in /etc/diglim in the initial ram disk (included with a custom dracut script) and uploads them to the kernel. When a file is accessed, IMA calculates the file digest and queries it with DIGLIM. If the digest is found, measurement is skipped and appraisal is successful. If the digest is not found, a measurement of the file is performed and appraisal fails. When packages are installed or removed, the kernel hash table is kept synchronized with a new rpm plugin.
This description is … short.
A user space parser, executed by the kernel during early boot
Is it really executed by the kernel? This description makes it sound like a special old-hotplug-helper-style program that is spawned directly by the kernel.
parses RPM headers found in /etc/diglim in the initial ram disk
In general we try not to stuff more things in /etc, especially when there is no reason to. Why doesn't the helper just read files from /var/lib/rpm (or whatever %_dbpath du jour)?
This opens a bigger design question: the implementation seems to be closely tied to a very specific boot sequence implementation: grub2 + dracut. Unfortunately this is made even more opaque by the text description which uses generic terms like "boot loader configuration" when talking about a script which is intimately tied to some obsolete imperative grub2 installation mechanism.
It would be much better if instead the helper to upload the hashes to the kernel would be a generic tool that can be called whenever and from whatever environment. _Then_ you can add a dracut module to call it in the initrd, but that part should be a trivial wrapper, with all the "business logic" contained in the generic helper.
This will make testing easier, and not preclude systems without an initrd.
When a file is accessed, IMA calculates the file digest and queries it with DIGLIM
All files? What does "accessed" mean exactly in this context?
When packages are installed or removed, the kernel hash table is kept synchronized with a new rpm plugin.
Does this mean that old hashes are removed from the kernel after a package has been upgraded?
Are there any race conditions: e.g. when a new version of a package is installed, at what point in time are the new hashes uploaded? Something may be executed concurrently with the package upgrade, which would mean that the new hashes would need to be uploaded before any files land on disk.
And vice versa, if a file is opened, and later executed with fexecve(2), and concurrently the package is upgraded between those two steps, will the execution fail?
Zbyszek
From: Zbigniew Jędrzejewski-Szmek [mailto:zbyszek@in.waw.pl] Sent: Thursday, December 30, 2021 1:02 PM The gist of the proposal is described thus:
The new feature behaves as follows. A modified kernel with the DIGLIM patches will expose to user space an interface to add/remove file digests from the kernel hash table. A user space parser, executed by the kernel during early boot, parses RPM headers found in /etc/diglim in the initial ram disk (included with a custom dracut script) and uploads them to the kernel. When a file is accessed, IMA calculates the file digest and queries it with DIGLIM. If the digest is found, measurement is skipped and appraisal is successful. If the digest is not found, a measurement of the file is performed and appraisal fails. When packages are installed or removed, the kernel hash table is kept synchronized with a new rpm plugin.
This description is … short.
I saw you asked more questions below. I will answer there.
A user space parser, executed by the kernel during early boot
Is it really executed by the kernel? This description makes it sound like a special old-hotplug-helper-style program that is spawned directly by the kernel.
Yes, it must be executed before init, otherwise the kernel would refuse to execute it. And probably, it must be executed earlier than now, as I'm seeing that the kmod binary is being executed (with the same mechanism, user-mode helper) before the digest lists are uploaded to the kernel.
The reason for the kernel denying any operation enforced by the IMA policy would be that there are no file signatures for appraisal. The digests loaded by the helper are used instead. For the same reason, the digest of the helper itself must be in the native format understood by the kernel (the process of generation and signing is done in kernel.spec), and the kernel must scan /etc/diglim to load the native digest list before the helper is executed.
parses RPM headers found in /etc/diglim in the initial ram disk
In general we try not to stuff more things in /etc, especially when there is no reason to. Why doesn't the helper just read files from /var/lib/rpm (or whatever %_dbpath du jour)?
The RPM DB cannot be loaded as it is. The kernel accepts a file format similar to kernel modules, with appended signatures (I added support for PGP appended signatures in IMA). Each RPM header, together with its signature, must be written individually in a file.
Also files in other formats can be added to the same directory (for example the user-generated digest lists).
If there is a better place than /etc, it would be fine for me to move the directory to a new location.
This opens a bigger design question: the implementation seems to be closely tied to a very specific boot sequence implementation: grub2 + dracut. Unfortunately this is made even more opaque by the text description which uses generic terms like "boot loader configuration" when talking about a script which is intimately tied to some obsolete imperative grub2 installation mechanism.
Ok, sorry for the confusion. We just need to add few parameters to the kernel command line, and include the digest lists in the initial ram disk. For now, I'm excluding the implementation of a custom script to select only the digest lists required for accessing files in the initial ram disk.
It would be much better if instead the helper to upload the hashes to the kernel would be a generic tool that can be called whenever and from whatever environment. _Then_ you can add a dracut module to call it in the initrd, but that part should be a trivial wrapper, with all the "business logic" contained in the generic helper.
Too late.
Also it cannot be a generic tool. First it is statically linked, to avoid depending on shared libraries for which a native digest list must be generated. At least with a static binary, only one file should be considered.
Second, I had to develop an ad-hoc LSM to protect the helper against the other root processes. The problem is that an attacker might be able to tamper with the memory of the helper containing the digests extracted from RPMs, before the digests are uploaded to the kernel. Anything that the helper accesses must be inspected by IMA to provide the guarantee that the helper was not tampered.
This will make testing easier, and not preclude systems without an initrd.
When a file is accessed, IMA calculates the file digest and queries it with
DIGLIM
All files? What does "accessed" mean exactly in this context?
IMA selects the files to analyze depending on a policy. That policy allows the usage of different criteria: inode UID/GID, process UID/EUID, LSM label, etc. IMA does this selection at the time a file is executed, mmapped, opened, or read from the kernel.
DIGLIM is invoked only whenever IMA selected a file, and IMA decides what to do with the file depending on the result of the query (other than the action specified in the policy).
When packages are installed or removed, the kernel hash table is kept synchronized with a new rpm plugin.
Does this mean that old hashes are removed from the kernel after a package has been upgraded?
Yes, the old digests are removed. However, files in use could be still used, as the result of the last integrity evaluation is stored in the IMA cache. For cached results, DIGLIM is not invoked again.
Are there any race conditions: e.g. when a new version of a package is installed, at what point in time are the new hashes uploaded? Something may be executed concurrently with the package upgrade, which would mean that the new hashes would need to be uploaded before any files land on disk.
Yes, we encountered this problem when we implemented the solution in openEuler. One of the problems was that we loaded the digests too late, and that prevented the RPM installation scripts to work. After some iterations, we seem to have found the right solution (will try to complete the rpm plugin soon).
And vice versa, if a file is opened, and later executed with fexecve(2), and concurrently the package is upgraded between those two steps, will the execution fail?
We are handling concurrency with RCU. It depends if IMA, calling the DIGLIM lookup function, sees the old or the new version of the pointers in the hash table.
Roberto
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Li Peng, Zhong Ronghua
On Thu, Dec 30, 2021 at 01:04:29PM +0000, Roberto Sassu via devel wrote:
From: Zbigniew Jędrzejewski-Szmek [mailto:zbyszek@in.waw.pl] Sent: Thursday, December 30, 2021 1:02 PM The gist of the proposal is described thus:
The new feature behaves as follows. A modified kernel with the DIGLIM patches will expose to user space an interface to add/remove file digests from the kernel hash table. A user space parser, executed by the kernel during early boot, parses RPM headers found in /etc/diglim in the initial ram disk (included with a custom dracut script) and uploads them to the kernel. When a file is accessed, IMA calculates the file digest and queries it with DIGLIM. If the digest is found, measurement is skipped and appraisal is successful. If the digest is not found, a measurement of the file is performed and appraisal fails. When packages are installed or removed, the kernel hash table is kept synchronized with a new rpm plugin.
This description is … short.
I saw you asked more questions below. I will answer there.
A user space parser, executed by the kernel during early boot
Is it really executed by the kernel? This description makes it sound like a special old-hotplug-helper-style program that is spawned directly by the kernel.
Yes, it must be executed before init, otherwise the kernel would refuse to execute it. And probably, it must be executed earlier than now, as I'm seeing that the kmod binary is being executed (with the same mechanism, user-mode helper) before the digest lists are uploaded to the kernel.
Normally ima policy would be loaded by systemd if /etc/ima/ima-policy is found… How does the loading of the digests relate to the loading of the ima policy?
The reason for the kernel denying any operation enforced by the IMA policy would be that there are no file signatures for appraisal. The digests loaded by the helper are used instead. For the same reason, the digest of the helper itself must be in the native format understood by the kernel (the process of generation and signing is done in kernel.spec), and the kernel must scan /etc/diglim to load the native digest list before the helper is executed.
parses RPM headers found in /etc/diglim in the initial ram disk
In general we try not to stuff more things in /etc, especially when there is no reason to. Why doesn't the helper just read files from /var/lib/rpm (or whatever %_dbpath du jour)?
The RPM DB cannot be loaded as it is. The kernel accepts a file format similar to kernel modules, with appended signatures (I added support for PGP appended signatures in IMA). Each RPM header, together with its signature, must be written individually in a file.
Also files in other formats can be added to the same directory (for example the user-generated digest lists).
If there is a better place than /etc, it would be fine for me to move the directory to a new location.
Normally such files would go somewhere in /usr. In this case it makes sense put them next to the rpmdb files. If users are allowed to add more files, then those files provided by the admin should be in /etc.
This opens a bigger design question: the implementation seems to be closely tied to a very specific boot sequence implementation: grub2 + dracut. Unfortunately this is made even more opaque by the text description which uses generic terms like "boot loader configuration" when talking about a script which is intimately tied to some obsolete imperative grub2 installation mechanism.
Ok, sorry for the confusion. We just need to add few parameters to the kernel command line, and include the digest lists in the initial ram disk. For now, I'm excluding the implementation of a custom script to select only the digest lists required for accessing files in the initial ram disk.
Hmm, so how does this work wrt. to transition to the host system? The system has many more files from more packages, and those packages are in different versions.
It would be much better if instead the helper to upload the hashes to the kernel would be a generic tool that can be called whenever and from whatever environment. _Then_ you can add a dracut module to call it in the initrd, but that part should be a trivial wrapper, with all the "business logic" contained in the generic helper.
Too late.
Also it cannot be a generic tool. First it is statically linked, to avoid depending on shared libraries for which a native digest list must be generated. At least with a static binary, only one file should be considered.
Second, I had to develop an ad-hoc LSM to protect the helper against the other root processes. The problem is that an attacker might be able to tamper with the memory of the helper containing the digests extracted from RPMs, before the digests are uploaded to the kernel. Anything that the helper accesses must be inspected by IMA to provide the guarantee that the helper was not tampered.
OK, it sounds like I should read the patches now. Thank you for all the answers. I'll be back with more questions ;)
Zbyszek
On Do, 30.12.21 13:04, Fedora Development ML (devel@lists.fedoraproject.org) wrote:
From: Zbigniew Jędrzejewski-Szmek [mailto:zbyszek@in.waw.pl] Sent: Thursday, December 30, 2021 1:02 PM The gist of the proposal is described thus:
The new feature behaves as follows. A modified kernel with the DIGLIM patches will expose to user space an interface to add/remove file digests from the kernel hash table. A user space parser, executed by the kernel during early boot, parses RPM headers found in /etc/diglim in the initial ram disk (included with a custom dracut script) and uploads them to the kernel. When a file is accessed, IMA calculates the file digest and queries it with DIGLIM. If the digest is found, measurement is skipped and appraisal is successful. If the digest is not found, a measurement of the file is performed and appraisal fails. When packages are installed or removed, the kernel hash table is kept synchronized with a new rpm plugin.
This description is … short.
I saw you asked more questions below. I will answer there.
A user space parser, executed by the kernel during early boot
Is it really executed by the kernel? This description makes it sound like a special old-hotplug-helper-style program that is spawned directly by the kernel.
Yes, it must be executed before init, otherwise the kernel would refuse to execute it. And probably, it must be executed earlier than now, as I'm seeing that the kmod binary is being executed (with the same mechanism, user-mode helper) before the digest lists are uploaded to the kernel.
Wouldn't it make more sense to push the digest lists into the kernel by simpler means, before any userspace runs? e.g. just pick it up from some fixed path in the file system, directly from the kernel, like the firmware is picked up, or the ACPI DSDT tables are picked up. That way you can just compile the digest lists trivially into a cpio you pass as extra initrd to the kernel, and things will just work without "uploading", without happing any intermediary userspace process around that needs to run to upload anything... They'd be available from the first moment on, from kernel code, without any userspace interfering.
Static linking is a mess. User-mode helper is an atrocity: no new kernel callouts should be introduced these days, that bypass userspace service management, that are not properly sorted into a cgroup and so on. It all sounds to me as if this *really* isn't thought to the end, and should not be adopted this way...
Lennart
-- Lennart Poettering, Berlin
From: Lennart Poettering [mailto:mzerqung@0pointer.de] Sent: Monday, January 3, 2022 1:33 PM On Do, 30.12.21 13:04, Fedora Development ML (devel@lists.fedoraproject.org) wrote:
From: Zbigniew Jędrzejewski-Szmek [mailto:zbyszek@in.waw.pl] Sent: Thursday, December 30, 2021 1:02 PM The gist of the proposal is described thus:
The new feature behaves as follows. A modified kernel with the DIGLIM patches will expose to user space an interface to add/remove file digests from the kernel hash table. A user space parser, executed by the kernel during early boot, parses RPM headers found in /etc/diglim in the initial ram disk (included with a custom dracut script) and uploads them to the kernel. When a file is accessed, IMA calculates the file digest and queries it with DIGLIM. If the digest is found, measurement is skipped and appraisal is successful. If the digest is not found, a measurement of the file is performed and appraisal fails. When packages are installed or removed, the kernel hash table is kept synchronized with a new rpm plugin.
This description is … short.
I saw you asked more questions below. I will answer there.
A user space parser, executed by the kernel during early boot
Is it really executed by the kernel? This description makes it sound like a special old-hotplug-helper-style program that is spawned directly by the kernel.
Yes, it must be executed before init, otherwise the kernel would refuse to execute it. And probably, it must be executed earlier than now, as I'm seeing that the kmod binary is being executed (with the same mechanism, user-mode helper) before the digest lists are uploaded to the kernel.
Wouldn't it make more sense to push the digest lists into the kernel by simpler means, before any userspace runs? e.g. just pick it up from some fixed path in the file system, directly from the kernel, like the firmware is picked up, or the ACPI DSDT tables are picked up. That way you can just compile the digest lists trivially into a cpio you pass as extra initrd to the kernel, and things will just work without "uploading", without happing any intermediary userspace process around that needs to run to upload anything... They'd be available from the first moment on, from kernel code, without any userspace interfering.
Definitely yes. It partially works that way: there is a loader in the kernel, called when rootfs becomes available, which get a fixed path from the kernel configuration and loads any digest list that is in the directory.
That would work if all digest lists are supported by the kernel. The first version worked that way, I developed a simple parser of RPM headers, so that the kernel could process then without having an additional user space process. Much better in term of protection: no interference with other user space processes that should be handled with an ad-hoc LSM, no time to measure time to use race condition.
However, it was pointed out by Matthew Garrett that this approach is not scalable. Whenever a new digest list format is introduced, a new parser should be added to the kernel, with the risks associated.
Before proposing this fine-tuned protection you saw in the last iteration of the patches, we considered to generate a digest list in the native format for each package we build (currently openEuler works that way), and to inject it in the package (without changing existing spec files).
That approach worked at the cost of modifying the rpm source code to pass the list of files being built and their digest to an external digest list generator, which returned the digest list. The RPM header was then modified to include the generated digest list. That removed the need for an additional user space parser, as everything could be handled by the kernel, but the complexity of the solution and the fact that it requires a mass rebuild suggested that we should abandon this approach in favor of more complexity at digest list loading time.
I kept the current proposal simple for easier understanding, but a possible application of this user space loading could be that digest lists could be used for metadata protection too (including the SELinux labels). EVM would query digest lists in the same way IMA does (there is still the problem of unpredictable UIDs/GIDs that need to be solved). The role of the user space parser would be to calculate metadata digests (by querying libselinux, which would read file contexts), and to upload them to the kernel.
Static linking is a mess. User-mode helper is an atrocity: no new kernel callouts should be introduced these days, that bypass userspace service management, that are not properly sorted into a cgroup and so on. It all sounds to me as if this *really* isn't thought to the end, and should not be adopted this way...
Dynamic linking would be possible, but I'm not sure it would be easier. Now, although this is a system-wide change, I consider this approach self-contained: everything is needed to bootstrap DIGLIM is contained in the kernel-tools-diglim package. With dynamic linking, you also have to take care of all shared libraries. Since the parser is not yet functional (the kernel is in enforcing mode), you need to generate a digest list in the native format (in the spec file) for every shared library you want to load.
I liked the fact that, once you have the modified kernel with the appropriate GPG keys, and kernel-tools-diglim, you are able to run IMA appraisal without additional effort for its management.
Regarding how the user space parser is executed, I would consider alternative proposals. Maybe running the parser as the init process and switching to systemd after the digest lists are loaded?
Thanks
Roberto
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Li Peng, Zhong Ronghua
On Mo, 03.01.22 13:07, Roberto Sassu (roberto.sassu@huawei.com) wrote:
That would work if all digest lists are supported by the kernel. The first version worked that way, I developed a simple parser of RPM headers, so that the kernel could process then without having an additional user space process. Much better in term of protection: no interference with other user space processes that should be handled with an ad-hoc LSM, no time to measure time to use race condition.
Why would you need to convert the digests on-the-fly? Can't you instead convert in an "offline" fashion, i.e. convert the RPM data into a kernel-understood digest list, and then wrap that in a cpio for use in an initrd? I mean, given the digests are only updated whenever RPM updates are done it sound like something perfectly doable in an "offline" fashion, i.e. convert at the moment of RPM update, and then just stick the covnerted format?
Lennart
-- Lennart Poettering, Berlin
From: Lennart Poettering [mailto:mzerqung@0pointer.de] Sent: Monday, January 3, 2022 2:34 PM On Mo, 03.01.22 13:07, Roberto Sassu (roberto.sassu@huawei.com) wrote:
That would work if all digest lists are supported by the kernel. The first version worked that way, I developed a simple parser of RPM headers, so that the kernel could process then without having an additional user space process. Much better in term of protection: no interference with other user space processes that should be handled with an ad-hoc LSM, no time to measure time to use race condition.
Why would you need to convert the digests on-the-fly? Can't you instead convert in an "offline" fashion, i.e. convert the RPM data into a kernel-understood digest list, and then wrap that in a cpio for use in an initrd? I mean, given the digests are only updated whenever RPM updates are done it sound like something perfectly doable in an "offline" fashion, i.e. convert at the moment of RPM update, and then just stick the covnerted format?
IMA appraisal would fail. Currently, it succeeds because the GPG keys used to sign RPM headers are in the kernel keyring, and each RPM header has a PGP appended signature (similar to the PKCS#7 of kernel modules).
It could be possible to use HMAC to protect digest lists locally generated. However, it adds a dependency on EVM and require very strong measures to avoid that the whole mechanism is circumvented: the HMAC key should be stored in hardware in the TPM, should be sealed to a system that does not let the user calculate HMACs of arbitrary files.
Roberto
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Li Peng, Zhong Ronghua
Hi everyone
in the FESCo meeting yesterday, Zbigniew asked what is the relationship between this feature and https://fedoraproject.org/wiki/Changes/FsVerityRPM. I try to explain here.
Both features aim at providing reference values, i.e. values of software fingerprint certified by the software vendor, in order to enforce an integrity policy.
The main difference between the features is the granularity at which the vendor certifies the software fingerprints. DIGLIM adopts the current scheme of RPMs, and verifies with one signature all the files contained in the RPM. Since this data format is not suitable for use by the Linux kernel, for enforcing the integrity policy, DIGLIM extracts the digests and adds them in a hash table stored in kernel memory. Enforcement (it would be better to say security decision) is achieved by doing a lookup in the hash table.
The main advantage is that DIGLIM can achieve its objective, providing reference values, without any change to existing RPMs. It could support fsverity digests, in addition to file digests, to achieve the same objective of the FsVerityRPM feature. This would require introducing a new RPM header section similar to RPMTAG_FILEDIGESTS.
The FsVerityRPM feature, on the other hand, similarly to the IMA file signature approach, re-signs all (or the desired subset of) files, and adds the signatures in a dedicated section of the RPM header, with increased size overhead.
The advantage of FsVerityRPM and the IMA file signatures approach is that the data format is already suitable for enforcement by fsverity and IMA.
Roberto
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Li Peng, Zhong Ronghua
On 1/4/22 10:41, Roberto Sassu via devel wrote:
Hi everyone
in the FESCo meeting yesterday, Zbigniew asked what is the relationship between this feature and https://fedoraproject.org/wiki/Changes/FsVerityRPM. I try to explain here.
Both features aim at providing reference values, i.e. values of software fingerprint certified by the software vendor, in order to enforce an integrity policy.
The main difference between the features is the granularity at which the vendor certifies the software fingerprints. DIGLIM adopts the current scheme of RPMs, and verifies with one signature all the files contained in the RPM. Since this data format is not suitable for use by the Linux kernel, for enforcing the integrity policy, DIGLIM extracts the digests and adds them in a hash table stored in kernel memory. Enforcement (it would be better to say security decision) is achieved by doing a lookup in the hash table.
The main advantage is that DIGLIM can achieve its objective, providing reference values, without any change to existing RPMs. It could support fsverity digests, in addition to file digests, to achieve the same objective of the FsVerityRPM feature. This would require introducing a new RPM header section similar to RPMTAG_FILEDIGESTS.
The FsVerityRPM feature, on the other hand, similarly to the IMA file signature approach, re-signs all (or the desired subset of) files, and adds the signatures in a dedicated section of the RPM header, with increased size overhead.
The advantage of FsVerityRPM and the IMA file signatures approach is that the data format is already suitable for enforcement by fsverity and IMA.
I haven't looked at the details at all, but from a rpm POV birds-eye perspective: applauds for the approach!
Besides not bloating up RPMs with seriously expensive per-file data, this side-steps the other issues associated with both IMA and fs-verity: both require separate signing steps for the file signatures which is a non-trivial cost and complexity, and unlike those the file hashes are covered (and thus protected) by normal rpm-level signatures too.
- Panu -
From: Panu Matilainen [mailto:pmatilai@redhat.com] Sent: Tuesday, January 4, 2022 12:27 PM On 1/4/22 10:41, Roberto Sassu via devel wrote:
Hi everyone
in the FESCo meeting yesterday, Zbigniew asked what is the relationship between this feature and https://fedoraproject.org/wiki/Changes/FsVerityRPM. I try to explain here.
Both features aim at providing reference values, i.e. values of software fingerprint certified by the software vendor, in order to enforce an integrity policy.
The main difference between the features is the granularity at which the vendor certifies the software fingerprints. DIGLIM adopts the current scheme of RPMs, and verifies with one signature all the files contained in the RPM. Since this data format is not suitable for use by the Linux kernel, for enforcing the integrity policy, DIGLIM extracts the digests and adds them in a hash table stored in kernel memory. Enforcement (it would be better to say security decision) is achieved by doing a lookup in the hash table.
The main advantage is that DIGLIM can achieve its objective, providing reference values, without any change to existing RPMs. It could support fsverity digests, in addition to file digests, to achieve the same objective of the FsVerityRPM feature. This would require introducing a new RPM header section similar to RPMTAG_FILEDIGESTS.
The FsVerityRPM feature, on the other hand, similarly to the IMA file signature approach, re-signs all (or the desired subset of) files, and adds the signatures in a dedicated section of the RPM header, with increased size overhead.
The advantage of FsVerityRPM and the IMA file signatures approach is that the data format is already suitable for enforcement by fsverity and IMA.
I haven't looked at the details at all, but from a rpm POV birds-eye perspective: applauds for the approach!
Thanks Panu! I appreciate it.
Roberto
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Li Peng, Zhong Ronghua
Besides not bloating up RPMs with seriously expensive per-file data, this side-steps the other issues associated with both IMA and fs-verity: both require separate signing steps for the file signatures which is a non-trivial cost and complexity, and unlike those the file hashes are covered (and thus protected) by normal rpm-level signatures too.
- Panu -
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
Could this feature work with 3rd party kernel modules, in a UEFI Secure Boot (and thus kernel lockdown) context?
Workstation working group is tracking this problem as https://pagure.io/fedora-workstation/issue/155
If DIGLIM could be used for this use case, I further wonder whether it's possible to have multiple signatures for different portions of a kernel module? The purpose, is so NVIDIA can sign their proprietary binary blob (because it's theirs, no one else's, and therefore they should sign it). Next,either (a) Fedora (b) RPM Fusion (c) the user, can sign the remainder of the kernel module (the parts that are open source anyway). It's an open question who could or should sign NVIDIA's key, to narrowly indicate trust. And also a mechanism for revoking that trust without breaking everything else.
-- Chris Murphy
From: Chris Murphy [mailto:lists@colorremedies.com] Sent: Thursday, January 6, 2022 9:34 PM Could this feature work with 3rd party kernel modules, in a UEFI Secure Boot (and thus kernel lockdown) context?
It could be possible to create a digest list of third-party kernel modules. However, in the current implementation, DIGLIM is not used as an alternative for kernel module verification. Theoretically it is possible, you could extract the digests of kernel modules from the signed RPM header and use those digests for verification.
However, the trust problem remains. If your kernel does not trust the PGP key of the repository providing third-party modules, the kernel would refuse to access the RPM header. The user has to trust the additional key.
Whether it is better to trust an external repository to adequately protect the private key used for signing, or to keep the private key in the system that would load the third-party kernel modules is a difficult decision, and probably each user would like to make that decision.
Personally, I would find something like this acceptable. Currently, Fedora vouches for the source code of the packages that it provides, for building the source code correctly, and for adequately protecting the private key used to sign the packages.
Fedora could provide an additional repository for which it does not vouch for what the software does on the system, but only that the source is reliable (e.g. the software is made by NVIDIA) and that the software is coming from that source.
The key used to sign those packages could be embedded in the kernel (so that there are no problems verifying it from the boot loaded), but disabled by default. That key can be loaded upon user request (e.g. through an option in the kernel command line).
In my opinion, the guarantees provided by such solution are much higher than using external repositories or having the private key in the same system that is going to use the third-party kernel modules.
Workstation working group is tracking this problem as https://pagure.io/fedora-workstation/issue/155
If DIGLIM could be used for this use case, I further wonder whether it's possible to have multiple signatures for different portions of a kernel module? The purpose, is so NVIDIA can sign their proprietary binary blob (because it's theirs, no one else's, and therefore they should sign it). Next,either (a) Fedora (b) RPM Fusion (c) the user, can sign the remainder of the kernel module (the parts that are open source anyway). It's an open question who could or should sign NVIDIA's key, to narrowly indicate trust. And also a mechanism for revoking that trust without breaking everything else.
The DIGLIM approach would be to have an additional user space parser that takes the NVIDIA blob as an input (it must be signed with a key that the kernel trusts) and that does some calculations to determine what the digest of the built kernel module will be. The additional parser will then upload the digest to the kernel. The real process of building the kernel module can be done in an untrusted way in user space.
I don't see it too much viable. The complexity of the parser doing the calculations will be very high (maybe it needs to have logic from gcc).
The main point is how to guarantee that the transformation from the NVIDIA blob to the kernel module is done right. To guarantee that for the local system, it would be necessary to enforce a heavy integrity policy (not only on the executables, but also on all the inputs used for the transformation). It is much easier if users trust a building infrastructure to do that.
Roberto
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Li Peng, Zhong Ronghua
devel@lists.stg.fedoraproject.org
-
Adam Williamson -
Ben Cotton -
Bruno Wolff III -
Chris Murphy -
Colin Walters -
Dan Čermák -
David Sastre -
Fabio Valentini -
Kevin Fenzi -
Kevin Kofler -
Lennart Poettering -
Matthew Miller -
Mattia Verga -
Michael Catanzaro -
Michel Alexandre Salim -
Neal Gompa -
Nico Kadel-Garcia -
Panu Matilainen -
Roberto Sassu -
Samuel Sieb -
Simon Farnsworth -
Stephen Snow -
Vitaly Zaitsev -
Zbigniew Jędrzejewski-Szmek