Re: apptainer 1.1.8-1 has an incompatible change for apptainer-suid users

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 2023-04-27 08:42, Carl George wrote:
On Wed, Apr 26, 2023 at 12:54 PM David Trudgian <dave@xxxxxxxxxxxx> wrote:

Dave, Jonathan,

Thank you for the replies and actions after my original message r.e. the incompatible upgrades policy.

I should now declare that I have an interest in how the discussion around the incompatible change for apptainer goes, due to being the packager and one of the upstream developers of singularity-ce... which is a fork from the same historic codebase as apptainer was.

WIth my upstream hat on... Sylabs, my employer, has a response to the publication of the Apptainer project's CVE-2023-30549 available here:

https://sylabs.io/2023/04/response-to-cve-2023-30549/

.... which is likely broader than is relevant for EPEL packaging, but takes a basic position that CVE-2023-30549 is a duplicate of CVE-2022-1184 and is a medium severity DoS kernel vuln, and not a high severity security issue in apptainer / singularity-ce etc.

Trying to keep to what is likely of relevance for EPEL, CVE-2022-1184 is a medium severity denial of service kernel vulnerability. It has a CVSS3.x base score of 5.5 - https://nvd.nist.gov/vuln/detail/CVE-2022-1184

The new CVE-2023-30549 opened by the Apptainer project against apptainer, and which the breaking change is aiming to address, depends on the presence of CVE-2022-1184, but has an (unreviewed) CVSS3.x base score of 7.1. I'm not clear how the Apptainer CVE bumps the score from 5.5 to 7.1 for the same underlying vulnerability - https://nvd.nist.gov/vuln/detail/CVE-2023-30549

Red Hat seem to agree with the 5.5 score on CVE-2022-1184, and the kernel vuln has been patched in EL8 and EL9:

https://access.redhat.com/security/cve/cve-2022-1184

This means that in EPEL8 and EPEL9 the Apptainer vulnerability CVE-2023-30549 may be irrelevant. There is no direct impact due to the patches for CVE-2022-1184 that are in place, and the breaking change made to apptainer is, in my view, at least questionable. The argument about other possible but unproven kernel bugs doesn't seem to warrant duplicating the original CVE-2022-1184, raising its severity, and introducing a breaking change for EPEL8/9 users.

Admittedly, according to Dave Dykstra's findings, CVE-2022-1184 has not been patched in EL7. However, it's not clear to me that this justifies CVE-2023-30549, though a defense-in-depth strategy of disabling, or allowing users to disable use of extfs images in apptainer-suid on EL7 might be warranted. I'm not clear how EPEL packages are expected to handle (if at all) any "won't fix" security issues in components on which they depend.

FWIW, upstream in singularity-ce we are currently adding the ability for extfs image mounts through the kernel to be disabled, but not disabling them by default - as this is a breaking change to important functionality, and the underlying CVE-2022-1184 has been patched in most distros. We aren't considering this a security fix in singularty-ce, but the addition of a defence-in-depth option for users of distros with unpatched extfs vulnerabilities.

I'm hoping that the discussion / outcome w.r.t. apptainer will inform the approach for EPEL7 singularity-ce.

Many Thanks,

DT

On Wed, Apr 26, 2023, at 5:31 PM, Jonathan Wright via epel-devel wrote:
> Dave (Dykstra),
>
> The process is pretty well laid out at https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/#process_for_incompatible_upgrades
>
> I think leaving the package in epel-testing for now is OK but you definitely need to hold it from release repos until the policy is followed and the necessary approvals are obtained from the EPEL steering committee.
>
> I can't currently find it in the docs but I think going ahead and opening an issue at https://pagure.io/epel/issues will help facilitate the process.  I'm quite sure that this is/was documented somewhere when submitted an incompatible update for approval a few months back.  You can see it at https://pagure.io/epel/issue/212 which might help make more sense of the process as well.
>
> On Wed, Apr 26, 2023 at 11:20 AM Dave Dykstra via epel-devel <epel-devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
>> 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@xxxxxxxxxxxxxxxxxxxxxxx
>> To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
>> 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@xxxxxxxxxxxxxxxxxxxxxxx
>> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
>
>
> --
> Jonathan Wright
> AlmaLinux Foundation
> Mattermost: chat <https://chat.almalinux.org/almalinux/messages/@jonathan>
> _______________________________________________
> epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxxxxxxxx
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
>
_______________________________________________
epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

Thanks everyone for the detailed information provided so far.  We
should evaluate each of these updates separately since the conditions
surrounding them are not the same across the board.

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.

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.


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.


Same comment applies.

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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue




[Index of Archives]     [Fedora Announce]     [Fedora News]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Announce]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora QA]     [Fedora Triage]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Linux Apps]     [Gnome Users]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Maemo Users]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Fedora ARM]

  Powered by Linux