[EPEL-devel] Re: apptainer 1.1.8-1 has an incompatible change for apptainer-suid users
As a followup: for additional justification of the importance of having this security change also in EPEL8 and EPEL9, please see the new addendum at the end of the security advisory https://github.com/apptainer/apptainer/security/advisories/GHSA-j4rf-7357-f4cg Dave On Thu, May 11, 2023 at 11:51:10AM -0500, Dave Dykstra wrote: > To Troy and the rest of the EPEL Steering Committee: > > Thank you very much for granting the request. > > The apptainer maintainers promise to do our best to avoid incompatible > updates in the future. However if we discover another high severity > vulnerability in the setuid-root portion that cannot be worked around in > a compatible way, you will have put us into a very difficult position of > deciding between protecting the security of our users and making this > popular software more difficult for them to install. It doesn't make > sense to me that packages should be punished for doing what they are > forced to do for good security. > > Dave > > On Wed, May 10, 2023 at 02:20:52PM -0700, Troy Dawson wrote: > > We discussed this in the weekly EPEL Steering Committee meeting. We broke > > this into two separate votes. > > > > *Allow the epel 7 update : Passed* > > Votes: All who voted, voted in favor of this. > > Notes: No notes. > > > > *Allow the epel 8 and 9 update - with a stern warning : Passed* > > Votes: 4 for, 2 against, 1 abstaining - > > Notes: Although your argument was that these needed the same breaking > > configurations to prevent future security issues, that wasn't what swayed > > the votes. The first reason was that having older versions in epel 8 and 9 > > causes more problems. The second reason was that we felt we didn't give you > > a stern enough warning last time. > > > > *WARNING / ADVISEMENT / ATTENTION* > > This is the second time that apptainer has had breaking updates. The EPEL > > Steering Committee feels that if this happens again, then apptainer isn't a > > good fit for EPEL. We will pull apptainer from EPEL and recommend that you > > release it in COPR <https://copr.fedorainfracloud.org/ > instead of EPEL. > > Please inform the upstream maintainers of this. > > > > > > Troy > > > > On Mon, May 8, 2023 at 7:29 AM Dave Dykstra wrote: > > > > > Hi Troy, > > > > > > If required, the epel8 & epel9 builds could have a patch added that > > > changes the default of the new "allow setuid-mount extfs" to be "yes" > > > instead of "no". That's all that would be required to disable the > > > incompatible change. > > > > > > But as I said, I think it's a bad idea to make this behavior different > > > on different OS versions. Epel8 & 9 are still vulnerable to the same > > > general issue; even though they're likely to get patches for future low > > > or moderate level severity vulnerabilities, they don't get patches > > > quickly and so admins will have to turn this off for the period of time > > > between announcement and patch upstream. Also the incompatibility is > > > going to only affect a small percentage of epel8 & 9 users, and they > > > should be able to quickly workaround it by adding the --userns option. > > > > > > The --userns option is already available everywhere. Are you > > > suggesting that it default to --userns option behavior on epel8 & 9, at > > > least for ext3, when "allow setuid-mount extfs = no"? I have thought > > > of that but I believe that we cannot mix the setuid mode and the > > > fuse2fs mount, at least not without a lot of major rework and careful > > > investigation of the security implications. I don't think it would be > > > good to automatically switch fully to the --userns mode with a setuid > > > installation and "allow setuid-mount extfs = no", because then users > > > will get subtle differences with other behavior depending on whether or > > > not they are requesting something that is using an ext3 filesystem. > > > > > > Dave > > > > > > On Mon, May 08, 2023 at 06:47:04AM -0700, Troy Dawson wrote: > > > > That makes it more clear for epel7. > > > > But it will be strange for epel7 to have a higher version than epel8 and > > > 9. > > > > Would the apptainer maintainers be willing to create an update that has > > > the > > > > --userns option, as well as the original option? > > > > Then for epel7 the rpm's would have the original option turned off, but > > > for >
[EPEL-devel] Update of minor version of golang-1.19 coming to EPEL7
golang-1.19.6 is now available in epel-testing for EPEL7, an update of a minor version from 1.18.9. I expect it to be promoted in about a week unless karma changes that. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-ba899b9717 My policy for updating golang in EPEL7 is to follow the updates in RHEL8, including whatever patches they include. RHEL 8.8 released yesterday updated to golang-1.19.6. Dave ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: Update of minor version of golang-1.19 coming to EPEL7
I posted the below a couple of weeks ago but I don't think it ever came through. 1.9.6 is now in EPEL7's stable epel repository. Another new update 1.9.9 is now in EPEL7's epel-testing, since RHEL8 did another update due to a high severity vulnerability. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-efd9bbf67e Dave On Wed, May 17, 2023 at 04:04:30PM -0500, Dave Dykstra wrote: > golang-1.19.6 is now available in epel-testing for EPEL7, an update of a > minor version from 1.18.9. I expect it to be promoted in about a week > unless karma changes that. > https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-ba899b9717 > > My policy for updating golang in EPEL7 is to follow the updates in RHEL8, > including whatever patches they include. RHEL 8.8 released yesterday > updated to golang-1.19.6. > > Dave ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: apptainer 1.1.8-1 has an incompatible change for apptainer-suid users
Carl, You don't seem to have looked at this closely enough to understand. This is not an ordinary security problem that can be worked around in a compatible way. The security vulnerability is the feature itself. There's nothing that can be done about it short of disabling the feature. Of course if there was a compatible way to deal with this security vulnerability, we would have done it. Dave On Thu, May 11, 2023 at 10:34:40PM -0500, Carl George wrote: > Tens of thousands of upstream projects are packaged into Fedora and > EPEL. If they can find ways to deliver security fixes while following > Fedora and EPEL update policies, then apptainer can too. Asking you > to follow these policies is not a punishment. If you're unwilling to > follow these policies, then I agree with Troy that copr will be a > better fit for apptainer. > > On Thu, May 11, 2023 at 11:51 AM Dave Dykstra via epel-devel > wrote: > > > > To Troy and the reset of the EPEL Steering Committee: > > > > Thank you very much for granting the request. > > > > The apptainer maintainers promise to do our best to avoid incompatible > > updates in the future. However if we discover another high severity > > vulnerability in the setuid-root portion that cannot be worked around in > > a compatible way, you will have put us into a very difficult position of > > deciding between protecting the security of our users and making this > > popular software more difficult for them to install. It doesn't make > > sense to me that packages should be punished for doing what they are > > forced to do for good security. > > > > Dave > > > > On Wed, May 10, 2023 at 02:20:52PM -0700, Troy Dawson wrote: > > > We discussed this in the weekly EPEL Steering Committee meeting. We broke > > > this into two separate votes. > > > > > > *Allow the epel 7 update : Passed* > > > Votes: All who voted, voted in favor of this. > > > Notes: No notes. > > > > > > *Allow the epel 8 and 9 update - with a stern warning : Passed* > > > Votes: 4 for, 2 against, 1 abstaining - > > > Notes: Although your argument was that these needed the same breaking > > > configurations to prevent future security issues, that wasn't what swayed > > > the votes. The first reason was that having older versions in epel 8 and 9 > > > causes more problems. The second reason was that we felt we didn't give > > > you > > > a stern enough warning last time. > > > > > > *WARNING / ADVISEMENT / ATTENTION* > > > This is the second time that apptainer has had breaking updates. The EPEL > > > Steering Committee feels that if this happens again, then apptainer isn't > > > a > > > good fit for EPEL. We will pull apptainer from EPEL and recommend that you > > > release it in COPR <https://copr.fedorainfracloud.org/ > instead of EPEL. > > > Please inform the upstream maintainers of this. > > > > > > > > > Troy > > > > > > On Mon, May 8, 2023 at 7:29 AM Dave Dykstra wrote: > > > > > > > Hi Troy, > > > > > > > > If required, the epel8 & epel9 builds could have a patch added that > > > > changes the default of the new "allow setuid-mount extfs" to be "yes" > > > > instead of "no". That's all that would be required to disable the > > > > incompatible change. > > > > > > > > But as I said, I think it's a bad idea to make this behavior different > > > > on different OS versions. Epel8 & 9 are still vulnerable to the same > > > > general issue; even though they're likely to get patches for future low > > > > or moderate level severity vulnerabilities, they don't get patches > > > > quickly and so admins will have to turn this off for the period of time > > > > between announcement and patch upstream. Also the incompatibility is > > > > going to only affect a small percentage of epel8 & 9 users, and they > > > > should be able to quickly workaround it by adding the --userns option. > > > > > > > > The --userns option is already available everywhere. Are you > > > > suggesting that it default to --userns option behavior on epel8 & 9, at > > > > least for ext3, when "allow setuid-mount extfs = no"? I have thought > > > > of that but I believe that we cannot mix the setuid mode and the > > > > fuse2fs mount, at least not without a lot of major rework and careful > > > > investigation of the security implicat
[EPEL-devel] Re: Incompatible change in apptainer-suid-1.1.8 now in epel-testing
This change has now been approved by the EPEL Steering Committee and requested to be pushed to stable. I expect it to be in stable sometime tomorrow. Dave On Wed, Apr 26, 2023 at 01:07:32PM -0500, Dave Dykstra wrote: > The apptainer-suid package version 1.1.8 now in epel-testing has an > incompatible change because of a security vulnerability. The change is > that a new option "allow setuid-mount extfs" was added which defaults to > no, preventing ordinary users from mounting ext3 filesystems in > setuid-root mode. Those filesystems are used by a subset of users > primarily for the overlay feature which adds changes on top of a base > container image. If unprivileged user namespaces are enabled, users > will be able to still mount ext3 filesystems by using the "-u/--userns" > option or if the apptainer-suid package is removed. If system > administrators review the vulnerability description at > > https://github.com/apptainer/apptainer/security/advisories/GHSA-j4rf-7357-f4cg > and decide they still want to allow setuid-root access to this feature, > they can enable it by setting "allow setuid-mount extfs = yes" in > /etc/apptainer/apptainer.conf. > > This package will not be promoted to the epel repository for at least > two weeks, pending approval by the EPEL Steering Committee according to > the EPEL incompatible change policy. > > Apptainer 1.1.8 release notes are at > https://github.com/apptainer/apptainer/releases/tag/v1.1.8 > > Dave ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: apptainer 1.1.8-1 has an incompatible change for apptainer-suid users
To Troy and the reset of the EPEL Steering Committee: Thank you very much for granting the request. The apptainer maintainers promise to do our best to avoid incompatible updates in the future. However if we discover another high severity vulnerability in the setuid-root portion that cannot be worked around in a compatible way, you will have put us into a very difficult position of deciding between protecting the security of our users and making this popular software more difficult for them to install. It doesn't make sense to me that packages should be punished for doing what they are forced to do for good security. Dave On Wed, May 10, 2023 at 02:20:52PM -0700, Troy Dawson wrote: > We discussed this in the weekly EPEL Steering Committee meeting. We broke > this into two separate votes. > > *Allow the epel 7 update : Passed* > Votes: All who voted, voted in favor of this. > Notes: No notes. > > *Allow the epel 8 and 9 update - with a stern warning : Passed* > Votes: 4 for, 2 against, 1 abstaining - > Notes: Although your argument was that these needed the same breaking > configurations to prevent future security issues, that wasn't what swayed > the votes. The first reason was that having older versions in epel 8 and 9 > causes more problems. The second reason was that we felt we didn't give you > a stern enough warning last time. > > *WARNING / ADVISEMENT / ATTENTION* > This is the second time that apptainer has had breaking updates. The EPEL > Steering Committee feels that if this happens again, then apptainer isn't a > good fit for EPEL. We will pull apptainer from EPEL and recommend that you > release it in COPR <https://copr.fedorainfracloud.org/ > instead of EPEL. > Please inform the upstream maintainers of this. > > > Troy > > On Mon, May 8, 2023 at 7:29 AM Dave Dykstra wrote: > > > Hi Troy, > > > > If required, the epel8 & epel9 builds could have a patch added that > > changes the default of the new "allow setuid-mount extfs" to be "yes" > > instead of "no". That's all that would be required to disable the > > incompatible change. > > > > But as I said, I think it's a bad idea to make this behavior different > > on different OS versions. Epel8 & 9 are still vulnerable to the same > > general issue; even though they're likely to get patches for future low > > or moderate level severity vulnerabilities, they don't get patches > > quickly and so admins will have to turn this off for the period of time > > between announcement and patch upstream. Also the incompatibility is > > going to only affect a small percentage of epel8 & 9 users, and they > > should be able to quickly workaround it by adding the --userns option. > > > > The --userns option is already available everywhere. Are you > > suggesting that it default to --userns option behavior on epel8 & 9, at > > least for ext3, when "allow setuid-mount extfs = no"? I have thought > > of that but I believe that we cannot mix the setuid mode and the > > fuse2fs mount, at least not without a lot of major rework and careful > > investigation of the security implications. I don't think it would be > > good to automatically switch fully to the --userns mode with a setuid > > installation and "allow setuid-mount extfs = no", because then users > > will get subtle differences with other behavior depending on whether or > > not they are requesting something that is using an ext3 filesystem. > > > > Dave > > > > On Mon, May 08, 2023 at 06:47:04AM -0700, Troy Dawson wrote: > > > That makes it more clear for epel7. > > > But it will be strange for epel7 to have a higher version than epel8 and > > 9. > > > Would the apptainer maintainers be willing to create an update that has > > the > > > --userns option, as well as the original option? > > > Then for epel7 the rpm's would have the original option turned off, but > > for > > > epel8 and 9 the option could be there and update wouldn't be a breaking > > > update. > > > > > > That would allow users that have machines on RHEL 7,8 and 9 to use the > > same > > > version and secure options. > > > Users that only have machines on RHEL 8 and 9, would then have the option > > > to move to the more secure option when the time is good for them. > > > > > > Troy > > > > > > On Fri, May 5, 2023 at 3:30 PM Dave Dykstra via epel-devel < > > > epel-devel@lists.fedoraproject.org> wrote: > > > > > > > The NVD analysis at > > > > https://nvd.nist.gov/vuln/
[EPEL-devel] Re: apptainer 1.1.8-1 has an incompatible change for apptainer-suid users
Hi Troy, If required, the epel8 & epel9 builds could have a patch added that changes the default of the new "allow setuid-mount extfs" to be "yes" instead of "no". That's all that would be required to disable the incompatible change. But as I said, I think it's a bad idea to make this behavior different on different OS versions. Epel8 & 9 are still vulnerable to the same general issue; even though they're likely to get patches for future low or moderate level severity vulnerabilities, they don't get patches quickly and so admins will have to turn this off for the period of time between announcement and patch upstream. Also the incompatibility is going to only affect a small percentage of epel8 & 9 users, and they should be able to quickly workaround it by adding the --userns option. The --userns option is already available everywhere. Are you suggesting that it default to --userns option behavior on epel8 & 9, at least for ext3, when "allow setuid-mount extfs = no"? I have thought of that but I believe that we cannot mix the setuid mode and the fuse2fs mount, at least not without a lot of major rework and careful investigation of the security implications. I don't think it would be good to automatically switch fully to the --userns mode with a setuid installation and "allow setuid-mount extfs = no", because then users will get subtle differences with other behavior depending on whether or not they are requesting something that is using an ext3 filesystem. Dave On Mon, May 08, 2023 at 06:47:04AM -0700, Troy Dawson wrote: > That makes it more clear for epel7. > But it will be strange for epel7 to have a higher version than epel8 and 9. > Would the apptainer maintainers be willing to create an update that has the > --userns option, as well as the original option? > Then for epel7 the rpm's would have the original option turned off, but for > epel8 and 9 the option could be there and update wouldn't be a breaking > update. > > That would allow users that have machines on RHEL 7,8 and 9 to use the same > version and secure options. > Users that only have machines on RHEL 8 and 9, would then have the option > to move to the more secure option when the time is good for them. > > Troy > > On Fri, May 5, 2023 at 3:30 PM Dave Dykstra via epel-devel < > epel-devel@lists.fedoraproject.org> wrote: > > > The NVD analysis at > > https://nvd.nist.gov/vuln/detail/CVE-2023-30549 > > is now finished and they agreed with the impact score that I gave it. > > They ended up with an even higher rating because they said the attack > > complexity was low. I think the complexity is high, but in either case the > > overall severity is rated High. > > > > Dave > > > > On Thu, May 04, 2023 at 10:17:42AM -0500, Dave Dykstra wrote: > > > DT, > > > > > > I am not all arguing that CVE-2022-1184 impact score was incorrect. I > > can't imagine why you think that. > > > > > > By itself, CVE-2022-1184 is not a privilege escalation, because it can > > normally only be exploited by someone with write access to the filesystem > > boots, that is, root. Only with setuid-root apptainer/singularity does it > > become a privilege escalation. > > > > > > I have said that I think that CVE-2022-1184's "Privileges Required" was > > incorrect. It was you who suggested USB automounts being available to > > users may have been their reason for setting it to "low". If that's what > > they meant, then I think it makes perfect sense that they don't count that > > as a privilege escalation because physical access already gives privilege > > escalation in much easier ways. I said that that's probably why they only > > counted it as denial of service since that was the only thing new. > > > > > > Dave > > > > > > On Thu, May 04, 2023 at 02:14:08PM +0100, David Trudgian wrote: > > > > Dave, > > > > > > > > On Wed, May 3, 2023, at 10:31 PM, Dave Dykstra via epel-devel wrote: > > > > > On Wed, May 03, 2023 at 02:59:42PM -0500, Carl George wrote: > > > > > > On Thu, Apr 27, 2023 at 10:20 AM Dave Dykstra via epel-devel > > > > > > wrote: > > > > > > > > > > > > > > On Thu, Apr 27, 2023 at 02:11:46AM -0500, Carl George wrote: > > > > > ... > > > > > > > > The Red Hat CVSS score for CVE-2022-1184 has the same > > breakdown as the > > > > > > > > NVD CVSS score. Both rate the "privileges required" property > > as low. > > > > > > > > From what
[EPEL-devel] Re: apptainer 1.1.8-1 has an incompatible change for apptainer-suid users
The NVD analysis at https://nvd.nist.gov/vuln/detail/CVE-2023-30549 is now finished and they agreed with the impact score that I gave it. They ended up with an even higher rating because they said the attack complexity was low. I think the complexity is high, but in either case the overall severity is rated High. Dave On Thu, May 04, 2023 at 10:17:42AM -0500, Dave Dykstra wrote: > DT, > > I am not all arguing that CVE-2022-1184 impact score was incorrect. I can't > imagine why you think that. > > By itself, CVE-2022-1184 is not a privilege escalation, because it can > normally only be exploited by someone with write access to the filesystem > boots, that is, root. Only with setuid-root apptainer/singularity does it > become a privilege escalation. > > I have said that I think that CVE-2022-1184's "Privileges Required" was > incorrect. It was you who suggested USB automounts being available to users > may have been their reason for setting it to "low". If that's what they > meant, then I think it makes perfect sense that they don't count that as a > privilege escalation because physical access already gives privilege > escalation in much easier ways. I said that that's probably why they only > counted it as denial of service since that was the only thing new. > > Dave > > On Thu, May 04, 2023 at 02:14:08PM +0100, David Trudgian wrote: > > Dave, > > > > On Wed, May 3, 2023, at 10:31 PM, Dave Dykstra via epel-devel wrote: > > > On Wed, May 03, 2023 at 02:59:42PM -0500, Carl George wrote: > > > > On Thu, Apr 27, 2023 at 10:20 AM Dave Dykstra via epel-devel > > > > wrote: > > > > > > > > > > On Thu, Apr 27, 2023 at 02:11:46AM -0500, Carl George wrote: > > > ... > > > > > > The Red Hat CVSS score for CVE-2022-1184 has the same breakdown as > > > > > > the > > > > > > NVD CVSS score. Both rate the "privileges required" property as > > > > > > low. > > > > > > From what I can tell that property would be rated high if they > > > > > > considered root privileges to be required. How does apptainer's use > > > > > > of setuid change anything here? > > > > > > > > > > According to the explanation I received from the ext4 kernel > > > > > developer, > > > > > Red Hat's CVSS rating was incorrect on that property. Without > > > > > singularity > > > > > or apptainer it does require high privileges to exploit. > > > > > > > > Red Hat's CVSS score breakdown for CVE-2022-1184 is: > > > > > > > > CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H > > > > > > > > You're suggesting that Red Hat's rating should have been higher > > > > because they didn't factor in low privileges, but that is objectively > > > > false because they did score it with low privileges. If they had > > > > scored it for high privileges, that would have dropped the rating down > > > > from 5.5 to 4.4. > > > > > > As DT pointed out, perhaps Red Hat was thinking that low privileges could > > > have been used by automounts of a USB device, but since that requires > > > physical access and there are much easier ways to get privilege escalation > > > with physical access, the only additional capability that would give to > > > a user is a crash, a denial of service. > > > > Impact scoring for a CVE doesn't depend on how it is triggered, though. If > > CVE-2022-1184 can provably give privilege escalation then it should be > > scored high on the impact (confidentiality/integrity/availability) metrics. > > It is not relevant to the impact whether I need physical access. The ease > > of the exploit is covered by the exploitability metrics, not the impact > > metrics. > > > > https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator > > > > My comment about automounts etc. was only related to why Red Hat might hve > > set the 'Privileges Required' property to low, even though `mount` is > > usually a root-only operation. Here you are arguing that CVE-2022-1184 was > > mis-scored on impact (confidentiality/integrity/availability). This is not > > related to my point about privileges required. > > > > > > There is no reason to believe that CVE-2022-1184 > > > > should have been marked as higher impact than it was, and thus I see > > > > no reason to justify the likely duplicate CVE-2023-30549 as high. > &g
[EPEL-devel] Re: apptainer 1.1.8-1 has an incompatible change for apptainer-suid users
DT, I am not all arguing that CVE-2022-1184 impact score was incorrect. I can't imagine why you think that. By itself, CVE-2022-1184 is not a privilege escalation, because it can normally only be exploited by someone with write access to the filesystem boots, that is, root. Only with setuid-root apptainer/singularity does it become a privilege escalation. I have said that I think that CVE-2022-1184's "Privileges Required" was incorrect. It was you who suggested USB automounts being available to users may have been their reason for setting it to "low". If that's what they meant, then I think it makes perfect sense that they don't count that as a privilege escalation because physical access already gives privilege escalation in much easier ways. I said that that's probably why they only counted it as denial of service since that was the only thing new. Dave On Thu, May 04, 2023 at 02:14:08PM +0100, David Trudgian wrote: > Dave, > > On Wed, May 3, 2023, at 10:31 PM, Dave Dykstra via epel-devel wrote: > > On Wed, May 03, 2023 at 02:59:42PM -0500, Carl George wrote: > > > On Thu, Apr 27, 2023 at 10:20 AM Dave Dykstra via epel-devel > > > wrote: > > > > > > > > On Thu, Apr 27, 2023 at 02:11:46AM -0500, Carl George wrote: > > ... > > > > > The Red Hat CVSS score for CVE-2022-1184 has the same breakdown as the > > > > > NVD CVSS score. Both rate the "privileges required" property as low. > > > > > From what I can tell that property would be rated high if they > > > > > considered root privileges to be required. How does apptainer's use > > > > > of setuid change anything here? > > > > > > > > According to the explanation I received from the ext4 kernel developer, > > > > Red Hat's CVSS rating was incorrect on that property. Without > > > > singularity > > > > or apptainer it does require high privileges to exploit. > > > > > > Red Hat's CVSS score breakdown for CVE-2022-1184 is: > > > > > > CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H > > > > > > You're suggesting that Red Hat's rating should have been higher > > > because they didn't factor in low privileges, but that is objectively > > > false because they did score it with low privileges. If they had > > > scored it for high privileges, that would have dropped the rating down > > > from 5.5 to 4.4. > > > > As DT pointed out, perhaps Red Hat was thinking that low privileges could > > have been used by automounts of a USB device, but since that requires > > physical access and there are much easier ways to get privilege escalation > > with physical access, the only additional capability that would give to > > a user is a crash, a denial of service. > > Impact scoring for a CVE doesn't depend on how it is triggered, though. If > CVE-2022-1184 can provably give privilege escalation then it should be scored > high on the impact (confidentiality/integrity/availability) metrics. It is > not relevant to the impact whether I need physical access. The ease of the > exploit is covered by the exploitability metrics, not the impact metrics. > > https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator > > My comment about automounts etc. was only related to why Red Hat might hve > set the 'Privileges Required' property to low, even though `mount` is usually > a root-only operation. Here you are arguing that CVE-2022-1184 was mis-scored > on impact (confidentiality/integrity/availability). This is not related to my > point about privileges required. > > > > There is no reason to believe that CVE-2022-1184 > > > should have been marked as higher impact than it was, and thus I see > > > no reason to justify the likely duplicate CVE-2023-30549 as high. > > > > Now you seem to be missing the point of CVE-2023-30549. I agree that > > there's no reason to believe that CVE-2022-1184 should have been marked > > as higher impact than it was, but CVE-2023-30549 is about the extra > > impact that setuid-root apptainer (prior to 1.1.8) gives to users. > > It gives any user with a local account write access to the underlying > > bits of a filesystem, and since the filesystem can be easily corrupted > > by the user, and since CVE-2022-1184 is a memory corruption bug and not > > a simple panic, it potentially allows privilege escalation. That's why > > CVE-2023-30549 is high severity. > > Again, this is conflating scoring how difficult it is to exploit the > vulnerability with its impact. > > The impact of a vulnerability is not greater if a vulnerabili
[EPEL-devel] Re: apptainer 1.1.8-1 has an incompatible change for apptainer-suid users
On Wed, May 03, 2023 at 02:48:05PM -0500, Carl George wrote: > On Thu, Apr 27, 2023 at 9:42 AM Dave Dykstra via epel-devel > wrote: > > > > We believe that it is important to apply this change to all EPEL releases, > > for these reasons: > > 1. The general vulnerability described in this CVE applies equally to all > > currently supported Linux distributions. The Singularity/Apptainer > > CVE-2023-30549 only applies to apptainer on RHEL 7 because the > underlying vulnerability (CVE-2022-1184) has been fixed on RHEL 8 and > 9. CVE-2023-30549 most urgently applies to RHEL 7 because of the example of CVE-2022-1184, but as I explain in the rest of the point, it also applies in general to any similar moderate or low severity memory- corruption ext4 vulnerability that will come in the future on RHEL 8 & RHEL 9 because Red Hat has no motivation to fix them urgently. > > community has long been aware that making setuid-root kernel > > filesystem mounts available to all users has been a risk, because > > https://lwn.net/Articles/652468/ briefly explained that kernel > > developers considered that to be a great risk. System admins have > > been willing to live with the risk because (a) nobody had identified > > an attack, (b) the functionality was so useful, especially the > > squashfs mounts, and (c) there wasn't an alternative. With the new > > information from the ext4 kernel filesystem owner, we now have more > > specifics on how the attack can be done including an example > > vulnerability, the ext3 mounts aren't as widely used as squashfs, > > and Apptainer has an alternative using unprivileged user namespaces. > > 2. RHEL8 & RHEL9 have unprivileged user namespaces enabled by default, > > so the functionality will still be available to most of the users. > > It does not automatically switch to the alternative, but there's a > > clear error message saying that it is disabled by configuration and > > suggesting that users add the --userns option (and of course if > > apptainer-suid is not installed it uses the user namespace mode > > automatically). > > 3. It is important to have consistency across platforms, since users and > > administrators often use more than one and it would be confusing to > > have different behavior on different platforms. Admins can also > > If consistency across platforms is important, then it seems prudent to > avoid this incompatible update across all three platforms, especially > this late in the RHEL 7 lifecycle. It's not prudent to leave RHEL 7 exposed to high-severity vulnerabilities. Apptainer also supports more platforms than Red Hat. > > install the rpm on RHEL8 & 9 directly from github, and it would not > > be good to have different behavior when installed from EPEL. Dave ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: apptainer 1.1.8-1 has an incompatible change for apptainer-suid users
On Wed, May 03, 2023 at 02:59:42PM -0500, Carl George wrote: > On Thu, Apr 27, 2023 at 10:20 AM Dave Dykstra via epel-devel > wrote: > > > > On Thu, Apr 27, 2023 at 02:11:46AM -0500, Carl George wrote: ... > > > The Red Hat CVSS score for CVE-2022-1184 has the same breakdown as the > > > NVD CVSS score. Both rate the "privileges required" property as low. > > > From what I can tell that property would be rated high if they > > > considered root privileges to be required. How does apptainer's use > > > of setuid change anything here? > > > > According to the explanation I received from the ext4 kernel developer, > > Red Hat's CVSS rating was incorrect on that property. Without singularity > > or apptainer it does require high privileges to exploit. > > Red Hat's CVSS score breakdown for CVE-2022-1184 is: > > CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H > > You're suggesting that Red Hat's rating should have been higher > because they didn't factor in low privileges, but that is objectively > false because they did score it with low privileges. If they had > scored it for high privileges, that would have dropped the rating down > from 5.5 to 4.4. As DT pointed out, perhaps Red Hat was thinking that low privileges could have been used by automounts of a USB device, but since that requires physical access and there are much easier ways to get privilege escalation with physical access, the only additional capability that would give to a user is a crash, a denial of service. > There is no reason to believe that CVE-2022-1184 > should have been marked as higher impact than it was, and thus I see > no reason to justify the likely duplicate CVE-2023-30549 as high. Now you seem to be missing the point of CVE-2023-30549. I agree that there's no reason to believe that CVE-2022-1184 should have been marked as higher impact than it was, but CVE-2023-30549 is about the extra impact that setuid-root apptainer (prior to 1.1.8) gives to users. It gives any user with a local account write access to the underlying bits of a filesystem, and since the filesystem can be easily corrupted by the user, and since CVE-2022-1184 is a memory corruption bug and not a simple panic, it potentially allows privilege escalation. That's why CVE-2023-30549 is high severity. Dave ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: apptainer 1.1.8-1 has an incompatible change for apptainer-suid users
On Thu, Apr 27, 2023 at 12:00:47PM +0100, David Trudgian wrote: > On Thu, Apr 27, 2023, at 8:11 AM, Carl George wrote: > > The Red Hat CVSS score for CVE-2022-1184 has the same breakdown as the > > NVD CVSS score. Both rate the "privileges required" property as low. > > From what I can tell that property would be rated high if they > > considered root privileges to be required. How does apptainer's use > > of setuid change anything here? > > My read of privileges required 'low' on CVE-2022-1184 is that perhaps > it is related to the situation where, although a direct `mount` > command against an extfs filesystem usually requires root, it is > common that a non-root user can initiate mounts of extfs USB drives > etc in 'standard' distro configurations via udisks2. I could be way > off here, but at least on desktop systems there's usually a way for a > non-root user to mount extfs removable drives. It's possible that's what they meant, but as the already referenced article https://lwn.net/Articles/652468/ makes clear, security experts do not worry about that case because it requires physical access to the machine. That's another type of privilege, and there are countless ways for such a user to get root access. > With respect to CVE-2023-30549 scoring, we're going to have quite a > bit of confusion arising from the fact that the CNA suggested score at > the NVD listing is different than on the GitHub GHSA page... > > On https://nvd.nist.gov/vuln/detail/CVE-2023-30549 the CNA provided > vector is CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H > > This results in a higher score than CVE-2022-1184 because it lists > 'Privileges Required: None' which is surely incorrect, as you > have to have a user account with enough privileges to run apptainer? That's odd. It only makes a .1 diference in any case, and doesn't change the high severity rating. > On > https://github.com/apptainer/apptainer/security/advisories/GHSA-j4rf-7357-f4cg > the vector is CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H > > So... at the GHSA page, the Privleges Required is low (which seems > correct), but compared to CVE-2022-1184: > > 1) attack complexity is now high... which seems odd to change. I think that was because they had a low complexity way to cause denial of service. It's high complexity to do privilege escalation. The ext4 kernel developer was confident that a kernel security expert could cause any use-after-free vulnerability into a privilege escalation, and that's why I set this to be high complexity. > 2) the suggested scoring has bumped Confidentiality and Integrity > impact to 'high', where they are both 'none' in the underlying > CVE-2022-1184. Not clear how this can be correct when CVE-2022-1184 is > a denial of service vuln. That's because of the potential privilege escalation. I based the individual property settings on CVE-2023-0386 which was a low complexity privilege escalation. Red Hat rated that high complexity, which I think was another mistake because I was able to easily reproduce the exploit on a pre-patched kernel. > I'm quite confused looking at this now. I don't know how the GitHub > submited CNA suggest score at the NVD would differ from the score on > the GitHub Security Advisory. Was the scoring on the GHSA edited after > publication, after it had been sent to the NVD? Oh, you're on to something. I did change those settings after the initial creation, after I learned about CVE-2023-0386, but it was before publication. I don't know how to get that corrected, but I will try. > Also, I don't know what the justification is on the GHSA for bumping > confidentiality / integrity impact, nor changing complexity from low > -> high versus CVE-2022-1184. Explained above. Dave ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: apptainer 1.1.8-1 has an incompatible change for apptainer-suid users
On Thu, Apr 27, 2023 at 02:11:46AM -0500, Carl George wrote: > On Wed, Apr 26, 2023 at 11:20 AM Dave Dykstra via epel-devel ... > > The summary of the CVE is that the way that apptainer & singularity > > allow mounts of ext3 filesystems in setuid mode raises the severity of > > many ext4 filesystem CVEs (ext3 filesystems are implemented by the ext4 > > driver). OS vendors consider those CVEs to be low or moderate priority > > because they assume that users do not have write access to the > > underlying bits of the filesystem, but apptainer/singularity setuid mode > > gives that access to users by default (before this release of apptainer). > > Since vendors don't see urgency to patch low/moderate CVEs, it can take > > a very long time for them to patch them and in fact RHEL7 is not patched > > for one in particular. All this information came from a reliable source, > > the owner of the ext4 kernel driver. > > The Red Hat CVSS score for CVE-2022-1184 has the same breakdown as the > NVD CVSS score. Both rate the "privileges required" property as low. > From what I can tell that property would be rated high if they > considered root privileges to be required. How does apptainer's use > of setuid change anything here? According to the explanation I received from the ext4 kernel developer, Red Hat's CVSS rating was incorrect on that property. Without singularity or apptainer it does require high privileges to exploit. > > I am sorry to see that I have already done one step too many according > > to the incompatible changes policy, and have made the release available > > to epel-testing. However, I think it's important to make it available > > that way for system administrators to install early. The large High > > Energy Physics community that I represent has security teams that want > > to be able to notify their site administrators to upgrade to respond to > > this high severity CVE, and it would be so much better if the > > announcement they send can say to install from epel-testing rather than > > having to provide URLs to download from koji. > > You can't just ignore the policy because you feel it's important to > make a particular update available quickly. If you feel the policy > needs to allow for things to be done in that order, propose a change > to the policy. The policy does already say parenthetically that a short-circuit is needed for security updates. I will propose a change to make such a short-circuit. > > So, to the EPEL Steering Committee members: must I unpublish this update > > from testing, or may I leave it there and send an announcement to > > epel-announce that it is there and pending approval by the committee? > > The bodhi settings are set so they won't get auto-updated by karma or > > time. > > We discussed this earlier today at the Steering Committee meeting. No > one seemed to have an issue with allowing these updates to stay in the > testing repo until we vote on it next week. Next time, follow the > policy steps correctly. Thank you, I will do that. I apologize for starting off on the wrong foot. I neglected to read the policy again in my focus on getting the release done. Dave ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: apptainer 1.1.8-1 has an incompatible change for apptainer-suid users
On Thu, Apr 27, 2023 at 09:09:57AM +0100, Nick Howitt via epel-devel wrote: > On 2023-04-27 08:42, Carl George wrote: ... > > should be modified to set the "allow setuid-mount extfs" option to yes > > for compatibility, even if that isn't the upstream default. > > Can you not set the option to no for a new install and yes if it is an > upgrade? You may need to be a bit cuter if it is upgraded again to see what > it is upgrading from or read the old value first and don't update it. Theoretically that's possible, but I don't think that's a good choice. It would be a too subtle and surprising policy. Also, you're right that it would be especially tricky to distinguish a second upgrade. Dave ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: apptainer 1.1.8-1 has an incompatible change for apptainer-suid users
We believe that it is important to apply this change to all EPEL releases, for these reasons: 1. The general vulnerability described in this CVE applies equally to all currently supported Linux distributions. The Singularity/Apptainer community has long been aware that making setuid-root kernel filesystem mounts available to all users has been a risk, because https://lwn.net/Articles/652468/ briefly explained that kernel developers considered that to be a great risk. System admins have been willing to live with the risk because (a) nobody had identified an attack, (b) the functionality was so useful, especially the squashfs mounts, and (c) there wasn't an alternative. With the new information from the ext4 kernel filesystem owner, we now have more specifics on how the attack can be done including an example vulnerability, the ext3 mounts aren't as widely used as squashfs, and Apptainer has an alternative using unprivileged user namespaces. 2. RHEL8 & RHEL9 have unprivileged user namespaces enabled by default, so the functionality will still be available to most of the users. It does not automatically switch to the alternative, but there's a clear error message saying that it is disabled by configuration and suggesting that users add the --userns option (and of course if apptainer-suid is not installed it uses the user namespace mode automatically). 3. It is important to have consistency across platforms, since users and administrators often use more than one and it would be confusing to have different behavior on different platforms. Admins can also install the rpm on RHEL8 & 9 directly from github, and it would not be good to have different behavior when installed from EPEL. Dave On Thu, Apr 27, 2023 at 02:42:13AM -0500, Carl George wrote: ... > EPEL 9: > > RHEL 9 has the fix for CVE-2022-1184. CVE-2023-30549 requires > CVE-2022-1184 to be unpatched. Because of this I'm opposed to an > incompatible update for apptainer in EPEL 9. Apptainer in EPEL 9 > should be modified to set the "allow setuid-mount extfs" option to yes > for compatibility, even if that isn't the upstream default. > > EPEL 8: > > RHEL 8 has the fix for CVE-2022-1184. CVE-2023-30549 requires > CVE-2022-1184 to be unpatched. Because of this I'm opposed to an > incompatible update for apptainer in EPEL 8. Apptainer in EPEL 8 > should be modified to set the "allow setuid-mount extfs" option to yes > for compatibility, even if that isn't the upstream default. > > EPEL 7: > > RHEL 7 appears to be vulnerable to CVE-2022-1184. CVE-2023-30549 > requires CVE-2022-1184 to be unpatched, so unlike EPEL 8 and EPEL 9 it > actually impacts the EPEL 7 apptainer package. This CVE has not yet > been rated by NVD. If the NVD assigns a rating of high (matching the > CNA suggestion) or critical, I would be agreeable to an incompatible > update of apptainer in EPEL 7. If the NVD assigns a rating of medium > (matching CVE-2022-1184) or low, I would be opposed to an incompatible > update of apptainer in EPEL 7. > > https://nvd.nist.gov/vuln/detail/CVE-2023-30549 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Incompatible change in apptainer-suid-1.1.8 now in epel-testing
The apptainer-suid package version 1.1.8 now in epel-testing has an incompatible change because of a security vulnerability. The change is that a new option "allow setuid-mount extfs" was added which defaults to no, preventing ordinary users from mounting ext3 filesystems in setuid-root mode. Those filesystems are used by a subset of users primarily for the overlay feature which adds changes on top of a base container image. If unprivileged user namespaces are enabled, users will be able to still mount ext3 filesystems by using the "-u/--userns" option or if the apptainer-suid package is removed. If system administrators review the vulnerability description at https://github.com/apptainer/apptainer/security/advisories/GHSA-j4rf-7357-f4cg and decide they still want to allow setuid-root access to this feature, they can enable it by setting "allow setuid-mount extfs = yes" in /etc/apptainer/apptainer.conf. This package will not be promoted to the epel repository for at least two weeks, pending approval by the EPEL Steering Committee according to the EPEL incompatible change policy. Apptainer 1.1.8 release notes are at https://github.com/apptainer/apptainer/releases/tag/v1.1.8 Dave ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] apptainer 1.1.8-1 has an incompatible change for apptainer-suid users
DT is correct, this change is subject to the EPEL incompatible change policy. apptainer-suid-1.1.8 by default disables mounting of ext3 filesystems, because of CVE-2023-30549 https://github.com/apptainer/apptainer/security/advisories/GHSA-j4rf-7357-f4cg Most users don't use this feature, but a significant minority does. Apptainer has a non-setuid alternative for the same functionality if unprivileged user namespaces are available. The summary of the CVE is that the way that apptainer & singularity allow mounts of ext3 filesystems in setuid mode raises the severity of many ext4 filesystem CVEs (ext3 filesystems are implemented by the ext4 driver). OS vendors consider those CVEs to be low or moderate priority because they assume that users do not have write access to the underlying bits of the filesystem, but apptainer/singularity setuid mode gives that access to users by default (before this release of apptainer). Since vendors don't see urgency to patch low/moderate CVEs, it can take a very long time for them to patch them and in fact RHEL7 is not patched for one in particular. All this information came from a reliable source, the owner of the ext4 kernel driver. I am sorry to see that I have already done one step too many according to the incompatible changes policy, and have made the release available to epel-testing. However, I think it's important to make it available that way for system administrators to install early. The large High Energy Physics community that I represent has security teams that want to be able to notify their site administrators to upgrade to respond to this high severity CVE, and it would be so much better if the announcement they send can say to install from epel-testing rather than having to provide URLs to download from koji. So, to the EPEL Steering Committee members: must I unpublish this update from testing, or may I leave it there and send an announcement to epel-announce that it is there and pending approval by the committee? The bodhi settings are set so they won't get auto-updated by karma or time. And another question: should I submit an epel ticket for this? The policy doesn't mention that. Dave On Wed, Apr 26, 2023 at 09:41:16AM +0100, David Trudgian wrote: > Subject: Re: apptainer 1.1.8-1 appears to be an incompatible upgrade for > apptainer-suid users > > Hello, > > The maintainer of the apptainer package has submitted updates to version > 1.1.8-1 against epel-testing: > > https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-18a0e3fa23 > https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-44ff2475c4 > https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-b31211e2ce > > I believe that the update should be considered an incompatible upgrade, > requiring the incompatible upgrades policy to be followed, as it > significantly changes behaviour for users who have the apptainer-setuid > sub-package installed. > > The update now disallows, by default, workflows that involve ext format > container images and overlays: > > ``` > # Before update > $ apptainer exec sif-overlay.sif /bin/date > Wed Apr 26 09:12:37 BST 2023 > > # Update to the testing package > $ sudo dnf update --enablerepo=epel-testing apptainer-suid > > # After update > $ apptainer exec sif-overlay.sif /bin/date > FATAL: configuration disallows users from mounting SIF extfs partition in > setuid mode, try --userns > ``` > > I understand that the update is related to a security issue that upstream has > published: > > CVE-2023-30549 - > https://github.com/apptainer/apptainer/security/advisories/GHSA-j4rf-7357-f4cg > > > However, I don't think this exempts the update from the incompatible upgrades > policy? > > I'd also like to note that CVE-2023-30549 is dependent on and potentially a > duplicate of CVE-2022-1184, which has been patched in EL8 and EL9, but > admittedly not in EL7. > > Thanks, > > DT > > ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Update of minor version of golang coming to EPEL7
golang-1.18.4 is now available in epel-testing for EPEL7, an update of a minor version from 1.17.12. I expect it to be promoted in about a week unless karma changes that. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-96dbad9cd3 My policy for updating golang is to follow the updates in RHEL8. RHEL8.7 updated to golang-1.18.4 a few weeks ago. Golang typically gets a minor version update twice a year and they only support 2 minor versions for security updates (and almost every patch release has CVEs), so minor versions are obsoleted more quickly than most open source tools. Dave ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: What to do about an incompatible update I approved
Thanks, Troy. I will send a message to epel-announce. I looked through the last couple of years of epel-announce archives and don't see similar messages. I have a hard time imagining that somewhat incompatible changes aren't happening to other packages too, so it seems that such announcements aren't usually sent. With regard to golang, they usually have some small incompatibilities every minor upgrade. They do a new minor upgrade every 6 months, they only support security updates for 2 minor release lines at a time, and they have frequent CVEs, so the only viable option is to keep upgrading the minor version number once or twice a year. There is a golang fedoraproject.org mailing list. Maybe it's enough to announce minor release upgrades there instead of epel-announce. Dave On Thu, Oct 20, 2022 at 01:18:30PM -0700, Troy Dawson wrote: > On Wed, Oct 19, 2022 at 5:42 PM Dave Dykstra via epel-devel < > epel-devel@lists.fedoraproject.org> wrote: > > > Hello all, > > > > It is been pointed out to me that I pushed out an update of a package to > > EPEL that did not follow the incompatible upgrades policy: > > > > https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/ > > > > That's because I wasn't aware of the policy until it was pointed out to > > me (or possibly I had seen it once and had forgotten). > > > > The incompatible change to the "apptainer" package that was pushed to > > stable 3 weeks ago moved the setuid-root portion to another package > > called "apptainer-suid", which does not get installed by default. The > > remaining package can run non-setuid for most important operations, but > > only if unprivileged user namespaces are enabled. This most effects > > EPEL7 because unprivileged user namespaces are not enabled by default. > > So the upgrade forces admins who haven't enabled them to either enable > > them or install the extra package. This was done intentionally because > > of the inherent risks associated with setuid programs, especially the > > fact that the things that this program does with setuid (mounting > > filesystems implemented in the kernel although the raw files are > > writable by users) is something that kernel developers say should never > > be allowed for unprivileged users (https://lwn.net/Articles/652468/ ). On > > the other hand there aren't any known published exploits (anybody know a > > good squashfs or ext3/4 filesystem developer who could find one?). > > > > So the question is, what should be done about it since I didn't follow > > the procedure before the release 3 weeks ago? > > > > > Better late than never. Please send an email to epel-announce saying what > changed and why. > I'm not seeing any installation problems because of it, so I don't think > you have to worry about other packages. > > Having an email explaining what was updated and why allows us to point > people to the explanation when they have questions. > > > > On a related note, I maintain golang in EPEL7 too, and every time that > > RHEL8 upgrades to a new minor golang version number 1.X I do the same > > for EPEL7. I expect that could be considered an incompatible update > > too, although every time that's done there's a ton of CVEs that go along > > with them so it's much easier to argue that the exceptions in the > > incompatible upgrade policy apply. The question is, am I supposed to go > > through the whole process every time? > > > > If this is a recurring thing, then I believe the answer is "sortof". > You don't have to come to the council meeting each time, but you should > send out an email to epel-announce saying that it is happening and why. > > I'm not seeing any epel7 golang dependency problems. > I would check to see if it really is an incompatible upgrade. Usually RHEL > tries to keep things compatible, so if you are following their lead, often > things are good. > > Troy ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] What to do about an incompatible update I approved
Hello all, It is been pointed out to me that I pushed out an update of a package to EPEL that did not follow the incompatible upgrades policy: https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/ That's because I wasn't aware of the policy until it was pointed out to me (or possibly I had seen it once and had forgotten). The incompatible change to the "apptainer" package that was pushed to stable 3 weeks ago moved the setuid-root portion to another package called "apptainer-suid", which does not get installed by default. The remaining package can run non-setuid for most important operations, but only if unprivileged user namespaces are enabled. This most effects EPEL7 because unprivileged user namespaces are not enabled by default. So the upgrade forces admins who haven't enabled them to either enable them or install the extra package. This was done intentionally because of the inherent risks associated with setuid programs, especially the fact that the things that this program does with setuid (mounting filesystems implemented in the kernel although the raw files are writable by users) is something that kernel developers say should never be allowed for unprivileged users (https://lwn.net/Articles/652468/). On the other hand there aren't any known published exploits (anybody know a good squashfs or ext3/4 filesystem developer who could find one?). So the question is, what should be done about it since I didn't follow the procedure before the release 3 weeks ago? On a related note, I maintain golang in EPEL7 too, and every time that RHEL8 upgrades to a new minor golang version number 1.X I do the same for EPEL7. I expect that could be considered an incompatible update too, although every time that's done there's a ton of CVEs that go along with them so it's much easier to argue that the exceptions in the incompatible upgrade policy apply. The question is, am I supposed to go through the whole process every time? Dave ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Looking for a fedora review of an epel7-only new package
I asked for a review swap on this on fedora-devel but so far did not get any takers. I'm thinking maybe a lot of Fedora people don't care that much about an epel7-only package. The package is fuse2fs and this is the request: https://bugzilla.redhat.com/show_bug.cgi?id=2104533 The tool is standard in the e2fsprogs package on el8 and later, but I need to use it from apptainer on el7 and later, thus the desire to install it as its own package in epel7. I am hoping to use this in an apptainer release candidate in just a couple of weeks, so it would be very good to have a timely review and approval. Dave ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
