Re: F37 Change: Signed RPM Contents (System-Wide Change proposal)
On Fri, Apr 08, 2022 at 08:54:02PM +0200, Vitaly Zaitsev via devel wrote: > On 08/04/2022 19:30, Kevin Fenzi wrote: > > We actually had IMA signing all up and running last year from jan 15th > > to jan 22nd. As luck would have it, there was a chromium build in that > > time: > > Now try with texlive. Unfortunately, there wasn't a texlive build in that period. It is currently disabled and I'm not going to enable production until/unless this change is approved or at least until after f36 is out the door. Perhaps Peter has a test env to test signing particular builds? kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Signed RPM Contents (System-Wide Change proposal)
On 01/04/2022 15:33, Ben Cotton wrote: We want to add signatures to individual files that are part of shipped RPMs. Can you try signing the breeze-icon-theme and distribution-gpg-keys packages and post %time output? -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Signed RPM Contents (System-Wide Change proposal)
On 08/04/2022 19:30, Kevin Fenzi wrote: We actually had IMA signing all up and running last year from jan 15th to jan 22nd. As luck would have it, there was a chromium build in that time: Now try with texlive. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Signed RPM Contents (System-Wide Change proposal)
On Fri, Apr 08, 2022 at 12:20:00AM +0200, Fabio Valentini wrote: > On Thu, Apr 7, 2022 at 11:51 PM Peter Robinson wrote: > > > > > > There are plenty of things in an RPM build that already inherently take > > > > O(N) time in the number of files or the total size of the files, even > > > > ignoring %build and %install. > > > > > > Yes, but signing is an extremely slow process. Rebuilding the texlive > > > package during the Mass rebuild slows down Koji for several hours. > > > > Why do you classify that slow down being due to signing? The signing > > process is actually out of band to koji and happens in a completely > > different queue to the mass rebuild. The texlive package is large, as > > are things like libreoffice but that's not due to the signing process. > > Right, package signing doesn't happen in koji itself, but those > signing servers still have limited throughput. > That's why merging builds into rawhide after a mass rebuild takes forever. > > However, I'd still like to have an answer to my original question: > Will the time it takes to build, sign, and submit a package noticably > increase? And if so, by how much? > > It would be really unfortunate if the delay between "your build was > successful" to "your build is now available for other builds" or "your > build is finally in a compose" gets any longer. I think the answer to this is... no and no appreciable amount. We actually had IMA signing all up and running last year from jan 15th to jan 22nd. As luck would have it, there was a chromium build in that time: Thu Jan 21 03:24:24 2021 chromium-88.0.4324.96-1.fc34 tagged into f34-signing-pending by bodhi Thu Jan 21 03:25:49 2021 chromium-88.0.4324.96-1.fc34 untagged from f34-signing-pending by autopen So, about 2minutes to sign. A recent one: Wed Mar 30 09:23:39 2022 chromium-99.0.4844.84-1.fc34 tagged into f34-signing-pending by bodhi Wed Mar 30 09:26:26 2022 chromium-99.0.4844.84-1.fc34 untagged from f34-signing-pending by autopen About 3min... so I think the ima signing was not much of a factor. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Signed RPM Contents (System-Wide Change proposal)
On 07/04/2022 23:50, Peter Robinson wrote: Why do you classify that slow down being due to signing? Because all build packages are stuck in the "signing pending" status. You can't do anything with them until the sign process is complete. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Signed RPM Contents (System-Wide Change proposal)
Hi On Thu, Apr 7, 2022 at 5:33 PM Matthew Miller wrote: > > I don't think we should characterize the Changes process in this way. > Fedora > is a place for experimentation, and if a proposal is rejected, it is > totally > appropriate to adjust that proposal based on feedback and re-submit. > Partly, I think this confusion is because the change process doesn't differentiate at the status or summary level between rejected: we don't think this is ever going to happen vs rejected: this looks like a good idea but the timeline doesn't look great, break it down and go slower vs rejected: we don't think this is fully baked yet or we want to get some more clarity, come back after you have the answers. Rahul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Signed RPM Contents (System-Wide Change proposal)
On Thu, Apr 7, 2022 at 11:51 PM Peter Robinson wrote: > > > > There are plenty of things in an RPM build that already inherently take > > > O(N) time in the number of files or the total size of the files, even > > > ignoring %build and %install. > > > > Yes, but signing is an extremely slow process. Rebuilding the texlive > > package during the Mass rebuild slows down Koji for several hours. > > Why do you classify that slow down being due to signing? The signing > process is actually out of band to koji and happens in a completely > different queue to the mass rebuild. The texlive package is large, as > are things like libreoffice but that's not due to the signing process. Right, package signing doesn't happen in koji itself, but those signing servers still have limited throughput. That's why merging builds into rawhide after a mass rebuild takes forever. However, I'd still like to have an answer to my original question: Will the time it takes to build, sign, and submit a package noticably increase? And if so, by how much? It would be really unfortunate if the delay between "your build was successful" to "your build is now available for other builds" or "your build is finally in a compose" gets any longer. Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Signed RPM Contents (System-Wide Change proposal)
> > There are plenty of things in an RPM build that already inherently take > > O(N) time in the number of files or the total size of the files, even > > ignoring %build and %install. > > Yes, but signing is an extremely slow process. Rebuilding the texlive > package during the Mass rebuild slows down Koji for several hours. Why do you classify that slow down being due to signing? The signing process is actually out of band to koji and happens in a completely different queue to the mass rebuild. The texlive package is large, as are things like libreoffice but that's not due to the signing process. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Signed RPM Contents (System-Wide Change proposal)
On Sun, Apr 03, 2022 at 12:03:58PM +0200, Vitaly Zaitsev via devel wrote: > >We want to add signatures to individual files that are part of shipped RPMs. > Third attempt to push it through again? It was already rejected by FESCo. I don't think we should characterize the Changes process in this way. Fedora is a place for experimentation, and if a proposal is rejected, it is totally appropriate to adjust that proposal based on feedback and re-submit. There's no limit on submiting an updated Change a third or fourth time (or more!) unless FESCo clearly notes that there is general matter of policy. And even then, as a project, we should give ourselves the flexibility to re-visit. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Signed RPM Contents (System-Wide Change proposal)
On 05/04/2022 13:12, Ben Beasley wrote: There are plenty of things in an RPM build that already inherently take O(N) time in the number of files or the total size of the files, even ignoring %build and %install. Yes, but signing is an extremely slow process. Rebuilding the texlive package during the Mass rebuild slows down Koji for several hours. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Signed RPM Contents (System-Wide Change proposal)
I have no idea whether or not this Change would add significantly to package build times in practice. It’s a good question. I think answering it would require benchmarks rather than asymptotic reasoning, though. There are plenty of things in an RPM build that already inherently take O(N) time in the number of files or the total size of the files, even ignoring %build and %install. Consider that a typical BRP (Buildroot Policy) script starts with: find "$RPM_BUILD_ROOT" -type f -print0 | … and that the entire file contents of each RPM must be compressed. On 4/5/22 04:26, Vitaly Zaitsev via devel wrote: On 04/04/2022 12:34, Fabio Valentini wrote: I wonder, does this have measurable effect on the time it takes to build a package? O(1) -> O(N), where N is the number of files in the RPM package. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Signed RPM Contents (System-Wide Change proposal)
On 04/04/2022 12:34, Fabio Valentini wrote: I wonder, does this have measurable effect on the time it takes to build a package? O(1) -> O(N), where N is the number of files in the RPM package. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Signed RPM Contents (System-Wide Change proposal)
Dne 04. 04. 22 v 10:29 Peter Robinson napsal(a): How will this key be distributed on the distro filesystem or on the web? The pub keys will be both, I've added a paragraph to the detailed description. Please add it as TYPE 61 DNS record as well: https://github.com/xsuchy/distribution-gpg-keys/#storing-keys-in-dns All Fedoras keys are already there. Miroslav ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Signed RPM Contents (System-Wide Change proposal)
> == Detailed Description == > > During signing builds, the files in it will be signed with IMA signatures. > These signatures will be made with a key that's kept by the Fedora > Infrastructure team, and installed on the sign vaults. I wonder, does this have measurable effect on the time it takes to build a package? That could make the package signing service (sigul? robosignatory?) a new bottleneck for package builds ... There are packages that contain lots of small files, so I think it's safe to assume that signing them would take longer than it does now. But how much longer? Do you have an estimate? Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Signed RPM Contents (System-Wide Change proposal)
> > == How To Test == > > You can verify that a signature has been put in place by looking at > > the extended attribute by running: `getfattr -d -m security.ima > > /usr/bin/bash` (change `/usr/bin/bash` with the file to check). > > Can one easily query the RPM archive for the signature blob for any > given file it contains? > > > > The signatures can be tested “in vitro” by running `evmctl ima_verify > > --key publiccert.der -v myfile.txt`. > > [...] > > The full system could be tested by enrolling the Fedora IMA key [...] > > How will this key be distributed on the distro filesystem or on the web? The pub keys will be both, I've added a paragraph to the detailed description. > Will it be signed by an already trusted CA? > > > - FChE > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Signed RPM Contents (System-Wide Change proposal)
On Sun, Apr 3, 2022 at 11:04 AM Vitaly Zaitsev via devel wrote: > > On 01/04/2022 15:33, Ben Cotton wrote: > > We want to add signatures to individual files that are part of shipped RPMs. > > Third attempt to push it through again? It was already rejected by FESCo. Actually only the second attempt, it was accepted last time but then due to a bug in RHEL it was dropped. Please get your facts right. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Signed RPM Contents (System-Wide Change proposal)
On 01/04/2022 15:33, Ben Cotton wrote: We want to add signatures to individual files that are part of shipped RPMs. Third attempt to push it through again? It was already rejected by FESCo. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Signed RPM Contents (System-Wide Change proposal)
> [...] > == How To Test == > You can verify that a signature has been put in place by looking at > the extended attribute by running: `getfattr -d -m security.ima > /usr/bin/bash` (change `/usr/bin/bash` with the file to check). Can one easily query the RPM archive for the signature blob for any given file it contains? > The signatures can be tested “in vitro” by running `evmctl ima_verify > --key publiccert.der -v myfile.txt`. > [...] > The full system could be tested by enrolling the Fedora IMA key [...] How will this key be distributed on the distro filesystem or on the web? Will it be signed by an already trusted CA? - FChE ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
F37 Change: Signed RPM Contents (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/Signed_RPM_Contents == Summary == We want to add signatures to individual files that are part of shipped RPMs. These signatures will use the Linux IMA (Integrity Measurement Architecture) scheme, which means they can be used to enforce runtime policies to ensure execution of only trusted files. == Owner == * Name: [[User:Pbrobinson| Peter Robinson]] * Email: pbrobin...@gmail.com * Name: [[User:Puiterwijk| Patrick Uiterwijk]] * Email: puiterw...@redhat.com == Detailed Description == During signing builds, the files in it will be signed with IMA signatures. These signatures will be made with a key that's kept by the Fedora Infrastructure team, and installed on the sign vaults. These signature can then be used with the Linux Integrity Measurement Architecture (IMA) kernel subsystem to verify files on execution based on a policy. The IMA subsystem is described on [https://sourceforge.net/p/linux-ima/wiki/Home/ the project page]. IMA allows users to extend the trust of their system to the OS and processes. It allows the users, if they so wish, to set polices to ensure their machine and their resources are used the way they intended it to be not about restricting the use for the average Fedora user. Like all security pieces IMA doesn't solve the whole security problem with a single option, it's not intended to, but that does not mean it doesn't provide additional value and tools for Fedora users to protect their systems. To quote a section of [https://lwn.net/Articles/753276/ an LWN article]: The goals of the integrity subsystem are to detect files that have been altered, either accidentally or maliciously, by comparing a measurement of the current file contents with that of a stored "good" value; it can then enforce various file integrity policies (e.g. no access or no execution). IMA is three separate pieces: measurement, which calculates a hash of file contents; appraisal, which verifies file signatures made using the measured hashes; and audit, which records hashes and other information in the audit logs. There is also the extended verification module (EVM), which targets the measurement and protection of the file metadata, though that is not included in what she would be presenting. It is important to note that IMA does not protect against attacks on objects in memory, it can only be used to thwart attacks that change files. The intention here is not to ship a default policies for users but rather have sample policies that users can modify and use themselves. The Fedora IoT Edition intends to have sample policies and documentation for a number of IoT and Edge use cases. This means that they can configure a policy based on which the kernel will determine whether to verify (or measure) files before opening them. You could for example make a policy that appraises (verifies) all files that are executed by root: `appraise uid=1000 appraise_type=imasig`. Note explicitly that we do not intend to install a default policy as part of this change, and users will need to deploy their own policy before anything is measured or appraised. This means that after this is done, users will have the option to enable a policy and have that be enforced, but there will be nothing automatic. We will, however, document various example policies people can adapt to their needs. By default, the signatures will not be deployed to the file system. That will only be done once rpm-plugin-ima is installed. After that, RPM will put the signatures on the "security.ima" extended attribute on the files. == Feedback == === RPM Size === One of the main concerns that have been voiced is the RPM size, both on disk (mirrors) and on an installed system. For this comparison, I have cached all the RPMs installed in a Fedora Rawhide 20210118.n.1 default Server install (server netinstall disk, and then no changes to the group selection). After creating two copies of that data, one with just resigned (to exclude rpm size difference resulting from different key lengths), and one resigned with IMA file signatures inserted, I then installed two blank VMs by using the standard virt-manager settings, changing only the name and the system type to "EFI". This is using a prime256v1 file signing key. This is the same key format supported by the Fedora signing system. Binary RPMs on disk Resigned: 462524 (452M) Resigned+IMA: 467812 (457M) This comes down to a 1.1% increase on size of the binary RPMs. Installed size On installation of two different VMs, one with the resigned RPMs, and one with the resigned+ima RPMs, the `/usr` directory size does not change at all (both are exactly 1417064 bytes). The size of the rpmdb increases from 22952 to 28416 bytes, a 20% increase. This is on an install size of 1.7GB in total, so this 5MB increase is a 0.3% size increase on the final installed system. Note that both of those VMs did not have rpm-plugins-ima installed, which means the
F37 Change: Signed RPM Contents (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/Signed_RPM_Contents == Summary == We want to add signatures to individual files that are part of shipped RPMs. These signatures will use the Linux IMA (Integrity Measurement Architecture) scheme, which means they can be used to enforce runtime policies to ensure execution of only trusted files. == Owner == * Name: [[User:Pbrobinson| Peter Robinson]] * Email: pbrobin...@gmail.com * Name: [[User:Puiterwijk| Patrick Uiterwijk]] * Email: puiterw...@redhat.com == Detailed Description == During signing builds, the files in it will be signed with IMA signatures. These signatures will be made with a key that's kept by the Fedora Infrastructure team, and installed on the sign vaults. These signature can then be used with the Linux Integrity Measurement Architecture (IMA) kernel subsystem to verify files on execution based on a policy. The IMA subsystem is described on [https://sourceforge.net/p/linux-ima/wiki/Home/ the project page]. IMA allows users to extend the trust of their system to the OS and processes. It allows the users, if they so wish, to set polices to ensure their machine and their resources are used the way they intended it to be not about restricting the use for the average Fedora user. Like all security pieces IMA doesn't solve the whole security problem with a single option, it's not intended to, but that does not mean it doesn't provide additional value and tools for Fedora users to protect their systems. To quote a section of [https://lwn.net/Articles/753276/ an LWN article]: The goals of the integrity subsystem are to detect files that have been altered, either accidentally or maliciously, by comparing a measurement of the current file contents with that of a stored "good" value; it can then enforce various file integrity policies (e.g. no access or no execution). IMA is three separate pieces: measurement, which calculates a hash of file contents; appraisal, which verifies file signatures made using the measured hashes; and audit, which records hashes and other information in the audit logs. There is also the extended verification module (EVM), which targets the measurement and protection of the file metadata, though that is not included in what she would be presenting. It is important to note that IMA does not protect against attacks on objects in memory, it can only be used to thwart attacks that change files. The intention here is not to ship a default policies for users but rather have sample policies that users can modify and use themselves. The Fedora IoT Edition intends to have sample policies and documentation for a number of IoT and Edge use cases. This means that they can configure a policy based on which the kernel will determine whether to verify (or measure) files before opening them. You could for example make a policy that appraises (verifies) all files that are executed by root: `appraise uid=1000 appraise_type=imasig`. Note explicitly that we do not intend to install a default policy as part of this change, and users will need to deploy their own policy before anything is measured or appraised. This means that after this is done, users will have the option to enable a policy and have that be enforced, but there will be nothing automatic. We will, however, document various example policies people can adapt to their needs. By default, the signatures will not be deployed to the file system. That will only be done once rpm-plugin-ima is installed. After that, RPM will put the signatures on the "security.ima" extended attribute on the files. == Feedback == === RPM Size === One of the main concerns that have been voiced is the RPM size, both on disk (mirrors) and on an installed system. For this comparison, I have cached all the RPMs installed in a Fedora Rawhide 20210118.n.1 default Server install (server netinstall disk, and then no changes to the group selection). After creating two copies of that data, one with just resigned (to exclude rpm size difference resulting from different key lengths), and one resigned with IMA file signatures inserted, I then installed two blank VMs by using the standard virt-manager settings, changing only the name and the system type to "EFI". This is using a prime256v1 file signing key. This is the same key format supported by the Fedora signing system. Binary RPMs on disk Resigned: 462524 (452M) Resigned+IMA: 467812 (457M) This comes down to a 1.1% increase on size of the binary RPMs. Installed size On installation of two different VMs, one with the resigned RPMs, and one with the resigned+ima RPMs, the `/usr` directory size does not change at all (both are exactly 1417064 bytes). The size of the rpmdb increases from 22952 to 28416 bytes, a 20% increase. This is on an install size of 1.7GB in total, so this 5MB increase is a 0.3% size increase on the final installed system. Note that both of those VMs did not have rpm-plugins-ima installed, which means the