td-agent-bit won't install on RHEL 8 / FIPS #3617
Comments
|
I opened issue at packaging repo. How about v1.7.9 package ? I also tested curl package as a reference. RHEL8 article: https://access.redhat.com/articles/3642912#disabled-in-the-fips-policy-in-addition-to-the-default-policy-5 |
|
Thanks for looking into this. I am not sure if I should be responding here or in fluent/fluent-bit-packaging#21. However, I just tried this again on a clean machine, now that 1.7.9-1 is out. The short version is that I have the same result. On a machine that was built from scratch (no prior attempts at installing), I followed the instructions at https://docs.fluentbit.io/manual/installation/linux/redhat-centos. I did a dnf install of td-agent-bit with similar results: I then tried to just download the rpm and install that: But, that did not install and complained about no digest as well. It wasn't until I disabled with --nodigest that I got it to install: I looked into the links you provided, but I can't disable the FIPS policies. The redhat page is mostly describing what is changed when you enable FIPS and some common items you need to address if you use things outside the FIPS requirements. The other I am a bit confused if it is the same issue or not. I do see using the command you specified |
|
I just reread my comment and this line stuck out: I am not sure if that is an issue or not? --Update: Maybe not? Perhaps it is just saying the public key is there? |
|
@justchris1 Thank you for testing. I also tested This is curl output. |
|
As a point of reference, the td-agent repo does sign the td-agent package correctly, if that helps narrow it down. I am a bit uncertain why there are two different repo's maintained, to be honest. To clarify, neither repo signs its meta-data (repo_gpgcheck=1 fails for td-agent-bit that is tracked in #3618, but perhaps I should close and reopen that in the packaging project as I was unaware it existed separately when I opened the issue), but that is a separate issue. Also, any idea why TD is signing the td-agent as: |
|
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days. |
|
This issue remain unaddressed. I am unsure why it would be automatically closed? |
|
@justchris1 I just had this same issue today on a new install of RHEL 8. The fix per Red Hat was:
Hopefully that fixes your issues. My next problem is that in doesn't look like TD keeps the previous releases in their yum repo and I need to install |
@JungleGenius Thanks for the note. That workaround did work and I appreciate you noting it. However, there is no way I will be able to get that through cybersecurity as a deviation. TD needs to properly package and sign their code. Security and integrity of their distributions is really important! Also - thanks for the note on the lack of keeping even recent old versions around in their repos. I will have to come up with an approach for that too. |
|
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days. |
|
This issue remain unaddressed. I am unsure why it would be automatically closed? |
|
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days. |
|
I am amazed that there are 455 open issues when the system seems to designed to close issues that haven't been fixed. Never I have seen a project with so much automation and determination to close unresolved issues. This is still a problem because no one has fixed it! |
|
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days. |
|
This is still a problem because no one has fixed it! |
|
Is there any ETA on this issue? We are also experiencing this problem and resorted to installation with |
|
I'm actually looking at sorting this on #3753 which is more general improvements to the release process and will include the GPG signing once fully complete. @JungleGenius the old RPMs are all still there but just not indexed in the metadata for the repo - basically |
|
I am able to install 1.8.12 without warning about missing digest: |
|
Unfortunately, I am unable to install With definition of repository As defined here: https://docs.fluentbit.io/manual/installation/linux/redhat-centos#configure-yum |
|
I find the same thing as @gczarnocki. To be sure, I did a fresh install in a VM of RHEL 8.5 in FIPS mode. I performed a dnf update just after install with all default options (other than booting the installer with the kernel option of |
|
@gavenkoa Was the installation you tried this on a FIPS mode enabled machine? If you are on Redhat 8 (or similar), you can check by running |
|
Can I check is the issue that we need to sign the repo metadata and then it should work, i.e. #3618? Is there anything else required?
Getting a FIPS enabled machine into CI testing is tricky so looking to simplify what we need to verify it as much as we can. If fit is "just" a case of configuring the repo GPG check then I can easily include that in the package tests. |
|
I am not exactly sure what the defect is. The signatures not only have to be present, but also FIPS compatible. (Usually MD5 is the most commonly used algorithm that isn't recognized by FIPS - if there is a MD5 signature, it might as well not be there as far as FIPS mode is concerned). SHA256 should be fine. Both the packages and repo metadata need proper signatures. |
|
Well, it's not just that - there are various security levels and other aspects to consider (e.g. really all algorithms and libraries used should also be FIPS compliant). The RHEL documentation does not seem to cover what is required for that particular FIPS "mode" as far as I can see but please reach out and ask them if you can. In this case, I think the desire is purely to tick the box that you can install it on RHEL 8 when FIPS mode is enabled. Ubuntu also has a FIPS "mode", hopefully they are the same: https://ubuntu.com/blog/how-to-develop-linux-applications-for-fips-on-ubuntu |
|
@patrick-stephens Yes, there is a lot involved for FIPS 140-2 compliance, but this ticket is just enabling td-agent-bit to be installed on a FIPS mode machine. As long as td-agent-bit isn't doing their own crypto stuff (like relying on the openssl implementation resident on the system for TLS connections during operation which is already configured if the machine is in FIPS mode), I wouldn't see any reason they would need to do anything else. However, if you want to request that that might be a good different ticket. I just need to be able to install this on a FIPS mode machine through yum/dnf. |
|
Running the command It appears there is no Payload SHA256 digest in the 1.9.0 RPM distribution. This aligns with the error message received when trying to install with dnf on a FIPS machine: |
|
Ok, I think that means we need to set Appreciate you narrowing it down to something I should be able to check easily. |
|
I'll see if I can add this check plus the repo metadata signing one to the package smoke tests so it gets auto verified as well. |
|
@justchris1 I was looking at making the changes for this but my testing with CentOS 8 does not seem to show the same results you have. Are you using the CentOS 7 RPMs? This is what I'm doing: Each seems to have the SHA256 digest already. If I repeat on the CentOS 7 target then I don't get the SHA256 reported at all: And if I repeat on the CentOS 8 target but specifying the CentOS 7 repo then the SHA256 digest is not reported: The system packages do have it but the CentOS 7 package for td-agent-bit does not. If you use the CentOS 8 repository on your environment is that automatically resolving the signatures now? |
|
I will admit to one little fib (well, it wasn't at the beginning since when I opened the ticket before RedHat killed Centos) - I am using a fresh install of rocky 8 to test here. In fact, I have a VM image that I reserve just for this so I know it is fresh without any other modifications made. However, you are correct in that embarrassingly didn't catch the subtle '7' in the yum.repos.d repo file. I just copied in the copy in the instructions and totally overlooked the baseurl had that in there: When I changed to it did result in the package installing! I am not sure if there is some variable you can use which will replace the 7 with an 8 based on the major distribution version. We should probably think about the most clear way of documenting that in the install instructions. Thanks for your persistence! |
|
Ah good, at least it works then! I think the new CentOS 8 builds are auto configuring it correctly which you'd hope. They weren't available until 1.9 though. I've been using Rocky to test as well just because I don't need to mess with the mirrors now CentOS is EOL. The one line install script handles the appropriate version to use but you're right we should add something in the docs. Could you submit a docs PR? Maybe a faq on the page for using FIPS mode to check the repo. |
|
Opened PR: https://github.com/fluent/fluent-bit-docs/pull/788/files Please verify, but I think the use of the variable works. |
|
@justchris1 |
|
@adamdepollo might be worth adding a note on the installation page for Red Hat. Ultimately there are probably a few differences on various platforms (e.g. does Oracle Linux do something as well, will it change in the future, etc.) so the best we can do is document it |
Bug Report
Describe the bug
td-agent-bit won't install on a Redhat/Centos 8 machine in FIPS mode, after following installations instructions at: https://docs.fluentbit.io/manual/installation/linux/redhat-centos
To Reproduce
Expected behavior
td-agent-bit would install successfully, as reported by yum/dnf.
Your Environment
Additional context
I suspect this is related to FIPS mode which requires strong hash checksums to be present to validate the packages before install. I suspect SHA256 signatures are not being provided for the packages. FIPS mode restricts weak checksums from being used to validate downloaded packages. FIPS mode cannot be disabled due to compliance reasons and is officially supported by Redhat.
The text was updated successfully, but these errors were encountered: