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
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
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
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 w
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 abst
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 d
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
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
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-
On Wed, May 3, 2023, at 10:38 PM, Dave Dykstra via epel-devel wrote:
> 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,
> >
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:
> ...
> >
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 appli
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
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:
> > 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 o
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 Sin
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 p
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
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
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 k
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 r
On 2023-04-27 08:42, Carl George wrote:
On Wed, Apr 26, 2023 at 12:54 PM David Trudgian
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
On Wed, Apr 26, 2023 at 12:54 PM David Trudgian 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 appt
On Wed, Apr 26, 2023 at 11:31 AM 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 fo
On Wed, Apr 26, 2023 at 11:20 AM Dave Dykstra via epel-devel
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/apptaine
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 develop
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
26 matches
Mail list logo
