https://fedoraproject.org/wiki/Changes/ANNOBIN-used-by-bodhi
= Annobin Used By Bodhi =
== Summary == Use the annocheck program from the annobin package to produce an analysis of the security hardening of a compiled package when reviewing a Bodhi update.
== Owner == * Name: Nick Clifton [https://fedoraproject.org/wiki/User:Nickc] * Email: nickc@redhat.com
== Detailed Description == The annobin package provides two components, a plugin for gcc that records details about how a program was compiled and an analyser that uses this information to produce a report on the security hardening status of the compiled program. Currently the plugin is being used as part of the build process for Fedora packages (when they are built using gcc), but the analysing program is not being run. This proposal is to have the analyser (called annocheck) run when creating information for review by the Bodhi update process, possibly allowing an update to be delayed until the security issues are addressed.
The analyser currently looks for the following items:
* Lazy binding must not have been enabled via the linker option "-z lazy". Instead the @option{-z now} option must have been used.
* The program must not have a stack in an executable region of memory.
* The relocations for the GOT table must be read only.
* No program segment should have all three of the read, write and execute permission bits set.
* There should be no relocations against executable code.
* The runpath information used to locate shared libraries at runtime must only include directories rooted at /usr.
* The program must have been compiled with the -fstack-protector-strong option enabled, and with -D_FORTIFY_SOURCE=2 specified. It must also have been compiled at at least optimisation level 2.
* Dynamic executables must have a dynamic segment.
* Shared libraries must have been compiled with -fPIC or-fPIE but not -static.
* Dynamic executables must have been compiled with -fPIE and linked with -pie.
* Program which use exception handling must have been compiled with -fexceptions enabled and with -D_GLIBCXX_ASSERTIONS specified.
* If available the -fstack-clash-protection must have been used.
* If available the -fcf-protection=full must have been used.
* For i686 binaries, the -mstackrealign option must have been specified.
* The program must have been compiled with the -D_FORTIFY_SOURCE=2 command line option specified.
* The program must have been compiled with at least -O2 optimisation enabled.
* The program must not have any relocations that are held in a writable section.
* For x86_64 binaries, check that -fcf-protection has been enabled.
Note - I do not know *how* to add a run of the annocheck program to the Bodhi process. This change request is about asking that such a thing be added.
== Benefit to Fedora ==
Establishing good security practices when building packages will help Fedora remain a front running Linux distribution. By providing a way to review the security hardening status of packages, this update will help to ensure that these practices continue.
Note - the intention is that if this change is successful, and useful, then a future change request would be made to include the security checking as part of the actual package build process, and to have packages fail to complete building if they do not pass the security checks.
== Scope == * Proposal owners: In theory there is very little that I can do personally. I do not have the knowledge to change the Bodhi process myself, so I will have to rely upon someone else to do that. I am familiar with the annobin package however, so any changes that are needed to it I will be happy to make.
* Other developers: Add an invocation of the annocheck program to the Bodhi build approval process and make its output available to reviewers. Annocheck can be invoked simply as "annocheck <filename>" although there are a set of command line options to extend and modify its behaviour. Annocheck understands the rpm file format, as well as shared and static libraries and executable binaries. It can also be helpful to provide annocheck with access to the debug information for a binary or rpm, if that has been placed into a separate file.
* Release engineering: https://pagure.io/fedora-ci/general/issue/78
No mass rebuild is required.
* Policies and guidelines: It is desirable that the packaging guidelines be updated to describe the security hardening features examined by annocheck. (If they are not already mentioned in the guidelines).
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact == This change should have no effect on upgrading Fedora, nor should it introduce any compatibility problems.
== How To Test == Submit a package for Bodhi review and see if the annocheck data is added to the page. No special hardware is needed for this test, but it might involve the use of a dummy package or a dummy instance of Bodhi in order to test the behaviour before going live.
== User Experience == This change should not be noticeable by users.
== Dependencies == No packages depend upon this change. This change does depend upon the annobin package.
== Contingency Plan == Back out any changes made to Bodhi.
* Blocks release? No releases are blocked by this change.
* Blocks product? No products are blocked by this change.
== Documentation == The watermark specification explains the technology underlying annobin: https://fedoraproject.org/wiki/Toolchain/Watermark#Proposed_Specification_fo...
The annobin package includes its own documentation. On a system where it is installed invoking "info annobin" should produce a searchable information structure.
== Release Notes == An update to the Fedora Release Notes should not be needed.
Hey Nick,
Is this change about stopping any builds which do not pass annocheck test from going to stable repository or just adding new check in there? If latter, I don't think it qualifies as a system-wide change.
On Wed, Oct 30, 2019 at 10:05 PM Ben Cotton bcotton@redhat.com wrote:
https://fedoraproject.org/wiki/Changes/ANNOBIN-used-by-bodhi
= Annobin Used By Bodhi =
== Summary == Use the annocheck program from the annobin package to produce an analysis of the security hardening of a compiled package when reviewing a Bodhi update.
== Owner ==
- Name: Nick Clifton [https://fedoraproject.org/wiki/User:Nickc]
- Email: nickc@redhat.com
== Detailed Description == The annobin package provides two components, a plugin for gcc that records details about how a program was compiled and an analyser that uses this information to produce a report on the security hardening status of the compiled program. Currently the plugin is being used as part of the build process for Fedora packages (when they are built using gcc), but the analysing program is not being run. This proposal is to have the analyser (called annocheck) run when creating information for review by the Bodhi update process, possibly allowing an update to be delayed until the security issues are addressed.
The analyser currently looks for the following items:
- Lazy binding must not have been enabled via the linker option "-z
lazy". Instead the @option{-z now} option must have been used.
The program must not have a stack in an executable region of memory.
The relocations for the GOT table must be read only.
No program segment should have all three of the read, write and
execute permission bits set.
There should be no relocations against executable code.
The runpath information used to locate shared libraries at runtime
must only include directories rooted at /usr.
- The program must have been compiled with the
-fstack-protector-strong option enabled, and with -D_FORTIFY_SOURCE=2 specified. It must also have been compiled at at least optimisation level 2.
Dynamic executables must have a dynamic segment.
Shared libraries must have been compiled with -fPIC or-fPIE but not -static.
Dynamic executables must have been compiled with -fPIE and linked with -pie.
Program which use exception handling must have been compiled with
-fexceptions enabled and with -D_GLIBCXX_ASSERTIONS specified.
If available the -fstack-clash-protection must have been used.
If available the -fcf-protection=full must have been used.
For i686 binaries, the -mstackrealign option must have been specified.
The program must have been compiled with the -D_FORTIFY_SOURCE=2
command line option specified.
The program must have been compiled with at least -O2 optimisation enabled.
The program must not have any relocations that are held in a writable section.
For x86_64 binaries, check that -fcf-protection has been enabled.
Note - I do not know *how* to add a run of the annocheck program to the Bodhi process. This change request is about asking that such a thing be added.
== Benefit to Fedora ==
Establishing good security practices when building packages will help Fedora remain a front running Linux distribution. By providing a way to review the security hardening status of packages, this update will help to ensure that these practices continue.
Note - the intention is that if this change is successful, and useful, then a future change request would be made to include the security checking as part of the actual package build process, and to have packages fail to complete building if they do not pass the security checks.
== Scope ==
- Proposal owners:
In theory there is very little that I can do personally. I do not have the knowledge to change the Bodhi process myself, so I will have to rely upon someone else to do that. I am familiar with the annobin package however, so any changes that are needed to it I will be happy to make.
- Other developers:
Add an invocation of the annocheck program to the Bodhi build approval process and make its output available to reviewers. Annocheck can be invoked simply as "annocheck <filename>" although there are a set of command line options to extend and modify its behaviour. Annocheck understands the rpm file format, as well as shared and static libraries and executable binaries. It can also be helpful to provide annocheck with access to the debug information for a binary or rpm, if that has been placed into a separate file.
- Release engineering: https://pagure.io/fedora-ci/general/issue/78
No mass rebuild is required.
- Policies and guidelines:
It is desirable that the packaging guidelines be updated to describe the security hardening features examined by annocheck. (If they are not already mentioned in the guidelines).
- Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact == This change should have no effect on upgrading Fedora, nor should it introduce any compatibility problems.
== How To Test == Submit a package for Bodhi review and see if the annocheck data is added to the page. No special hardware is needed for this test, but it might involve the use of a dummy package or a dummy instance of Bodhi in order to test the behaviour before going live.
== User Experience == This change should not be noticeable by users.
== Dependencies == No packages depend upon this change. This change does depend upon the annobin package.
== Contingency Plan == Back out any changes made to Bodhi.
- Blocks release?
No releases are blocked by this change.
- Blocks product?
No products are blocked by this change.
== Documentation == The watermark specification explains the technology underlying annobin: https://fedoraproject.org/wiki/Toolchain/Watermark#Proposed_Specification_fo...
The annobin package includes its own documentation. On a system where it is installed invoking "info annobin" should produce a searchable information structure.
== Release Notes == An update to the Fedora Release Notes should not be needed.
-- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis _______________________________________________ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-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-announce@lists.fedorapro...
On Wed, Oct 30, 2019 at 05:01:55PM -0400, Ben Cotton wrote:
Note - I do not know *how* to add a run of the annocheck program to the Bodhi process. This change request is about asking that such a thing be added.
I think the best approach to this would be turn it into a test that can be run in the CI and used in the gating process. The result would be only indirectly visible in bodhi (as part of the test results). No special support would be added in bodhi.
Essentially, you'd provide a standard test that various packages could use. Then it would be easier to override in specific packages to weed out false positives.
Zbyszek
On Wed, Oct 30, 2019 at 10:19:42PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Wed, Oct 30, 2019 at 05:01:55PM -0400, Ben Cotton wrote:
Note - I do not know *how* to add a run of the annocheck program to the Bodhi process. This change request is about asking that such a thing be added.
I think the best approach to this would be turn it into a test that can be run in the CI and used in the gating process. The result would be only indirectly visible in bodhi (as part of the test results). No special support would be added in bodhi.
That is correct. We will not make this kind of changes to bodhi. Fedora has grown a mechanism to integrate test results from different sources which can then be used to gate packages in bodhi and this would be the mechanism to use in this situation.
I encourage you to reach out to the CI folks (cf the CI mailing list) to see what is needed from you to implement your test. Once you have your test running on pull-request and bodhi udpates, you can invite anyone and everyone to use it to gate their packages via the gating.yaml file in their git repo.
Pierre
Hi,
Ben Cotton bcotton@redhat.com writes:
The annobin package provides two components, a plugin for gcc that records details about how a program was compiled and an analyser that uses this information to produce a report on the security hardening status of the compiled program. Currently the plugin is being used as part of the build process for Fedora packages (when they are built using gcc), but the analysing program is not being run. This proposal is to have the analyser (called annocheck) run when creating information for review by the Bodhi update process, possibly allowing an update to be delayed until the security issues are addressed.
I currently run annocheck manually on my builds, so I am a fan of this change.
But I think it's worth calling out one limitation: this currently mostly works with gcc. clang is a bit behind in implementing some of the features that annocheck looks at. With Fedora 30, annocheck would cleanly skip most of clang-produced binaries. With Fedora 31, clang seems to insert some of the meta-data that annocheck looks for, but doesn't quite implement to match the gcc standard. I have recently run into failures flagged by annocheck that I need to dig into on Fedora 31.
It is desirable that the packaging guidelines be updated to describe the security hardening features examined by annocheck. (If they are not already mentioned in the guidelines).
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_compiler_flags has some of this, but not all. It seems to me like annocheck is more strict than the current packaging guidelines.
Thanks, Omair
-- PGP Key: B157A9F0 (http://pgp.mit.edu/) Fingerprint = 9DB5 2F0B FD3E C239 E108 E7BD DF99 7AF8 B157 A9F0
* Omair Majid:
It is desirable that the packaging guidelines be updated to describe the security hardening features examined by annocheck. (If they are not already mentioned in the guidelines).
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_compiler_flags has some of this, but not all. It seems to me like annocheck is more strict than the current packaging guidelines.
annocheck verifies against the Fedora build flags defined in redhat-rpm-config and documented here:
https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/master/f/buildflags.md
The part of the Packaging Guidelines you quote has largely been obsoleted by the Harden All Packages change in Fedora 23, and subsequent changes in the flags are not reflected there, either.
Thanks, Florian
Following pingou's advice adding ci@fedoraproject.org
On Wed, Oct 30, 2019 at 10:03 PM Ben Cotton bcotton@redhat.com wrote:
(skipped)
Note - I do not know *how* to add a run of the annocheck program to the Bodhi process. This change request is about asking that such a thing be added.
In this form I think it doesn't qualify as Fedora Change, so let's see how we can rework it.
- Proposal owners:
In theory there is very little that I can do personally. I do not have the knowledge to change the Bodhi process myself, so I will have to rely upon someone else to do that. I am familiar with the annobin package however, so any changes that are needed to it I will be happy to make.
We have a similar check coming to Fedora Rawhide gating. It is called rpminspect [1]. Check also the talk from Flock 2019 [2]. Tim Flink and David Cantrell are driving it, and afaik it is close to being done: the Jenkins job is already up and running and we are hooking it into the gating framework.
If I understand correctly, the setup for annocheck should be very similar, so we can reuse most of the work done for rpminspect, with only the content of the test being different. There are several work items related to that: setup of a Jenkins job, update of a Jenkins which is needed to migrate to a new Fedora messaging infrastructure.
We can coordinate of that via Fedora CI SIG [3], next meeting is on November 4th [4] by the way.
Maybe we can make it a joint effort and file one change for both rpminspect and annocheck?
[1] https://github.com/rpminspect/rpminspect [2] https://www.youtube.com/watch?v=lPxC185PBeI [3] https://fedoraproject.org/wiki/SIGs/CI [4] https://apps.fedoraproject.org/calendar/SIGs/2019/11/4/#m9618
On Thursday, October 31, 2019 7:04:47 AM EDT Aleksandra Fedorova wrote:
Following pingou's advice adding ci@fedoraproject.org
On Wed, Oct 30, 2019 at 10:03 PM Ben Cotton bcotton@redhat.com wrote:
(skipped)
Note - I do not know *how* to add a run of the annocheck program to the Bodhi process. This change request is about asking that such a thing be added.
In this form I think it doesn't qualify as Fedora Change, so let's see how we can rework it.
- Proposal owners:
In theory there is very little that I can do personally. I do not have the knowledge to change the Bodhi process myself, so I will have to rely upon someone else to do that. I am familiar with the annobin package however, so any changes that are needed to it I will be happy to make.
We have a similar check coming to Fedora Rawhide gating. It is called rpminspect [1]. Check also the talk from Flock 2019 [2]. Tim Flink and David Cantrell are driving it, and afaik it is close to being done: the Jenkins job is already up and running and we are hooking it into the gating framework.
If I understand correctly, the setup for annocheck should be very similar, so we can reuse most of the work done for rpminspect, with only the content of the test being different. There are several work items related to that: setup of a Jenkins job, update of a Jenkins which is needed to migrate to a new Fedora messaging infrastructure.
We can coordinate of that via Fedora CI SIG [3], next meeting is on November 4th [4] by the way.
Maybe we can make it a joint effort and file one change for both rpminspect and annocheck?
And one tangential question...will rpmfusion and others be held to this new standard? Many of the multimedia parsers that round out the Fedora ecosystem come from that repository. They also tend to have a lot of CVE's. I've scanned a number of packages that handle untrusted content and the use of protection mechanisms are really not up to par with the rest of Fedora.
-Steve
[1] https://github.com/rpminspect/rpminspect [2] https://www.youtube.com/watch?v=lPxC185PBeI [3] https://fedoraproject.org/wiki/SIGs/CI [4] https://apps.fedoraproject.org/calendar/SIGs/2019/11/4/#m9618
-- Aleksandra Fedorova bookwar _______________________________________________ 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.or g
"BC" == Ben Cotton bcotton@redhat.com writes:
BC> Use the annocheck program from the annobin package to BC> produce an analysis of the security hardening of a compiled package BC> when reviewing a Bodhi update.
While I don't disagree with running annocheck at some point in the build process, _only_ doing things in bodhi can be problematic for packagers.
The issue is that you can build and test and have others test and be ready to submit an update, only to be stopped by some additional testing that you had no idea you needed to take extra steps to duplicate locally.
Personally I'd prefer to do this in a brp script. Those run near the end of the build process, can output things into the build log which can be checked easily (even by anything which can look at koji, which I suppose would include bodhi) and could, if it were desired, fail the build entirely, notifying packagers of policy violations as early as possible instead of after waiting for a real koji build and bodhi processing.
All this would take is a shell wrapper, a small tweak in redhat-rpm-config, and getting annocheck into the buildroot.
Things to note:
1. You need the annocheck (or rather the annobin-annocheck package) in the buildroot. It doesn't appear to have additional dependencies which aren't already in the buildroot and the package is minimal, so this probably isn't a huge issue.
2. It's easy to disable brp scripts, which can be good or bad depending on whether you want them to implement hard policy. But it is also easy to find packages which disable them by grepping specfiles, and if the script is written to always output something then you can just grep the build log for evidence that it ran.
3. People get rather annoyed if builds start failing because of additional policy checks. This is of course mitigated somewhat by #2 above. Generally what we've done in the past is add the checks in some advisory mode and then turn bad things into failures after a release.
- J<
-
Aleksandra Fedorova -
Ben Cotton -
Florian Weimer -
Igor Gnatenko -
Jason L Tibbitts III -
Omair Majid -
Pierre-Yves Chibon -
Steve Grubb -
Zbigniew Jędrzejewski-Szmek