[PATCH 0/1][SRU F/G] Fix regression opening some files in overlayfs

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[PATCH 0/1][SRU F/G] Fix regression opening some files in overlayfs

Seth Forshee
BugLink: https://bugs.launchpad.net/bugs/1900141

[Impact]

The backports to fix CVE-2020-16120 introduced a regression for overlay
mounts within user namespaces. Files with ownership outside of the user
namespace can no longer be accessed, even if allowed by both DAC and
MAC.

This issue is fixed by the following upstream commit:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b6650dab404c701d7fe08a108b746542a934da84

This commit relaxes the check to remove O_NOATIME from the open flags
for the file in the lower filesystem when the overlay filesystem mounter
is not privileged with respect to the underlying inode, rather than
failing the open as happens now.

[Test Case]

See the lp1900141.sh script attached to the bug report. Prior to the fix
the script will show failure to access the file from the lower
filesystem. With the fix the file can be accessed.

[Where problems could occur]

For the most part this patch restores previous behavior of allowing
access to these files while keeping the enhanced permission checks
towards the lower filesystem to help prevent unauthorized access to file
data in the lower filesystem. The one difference in behavior is that
files in the lower filesystem may no longer be opened with the O_NOATIME
flag, potentially causing atime updates for these files which were not
happening before. If any software expects O_NOATIME behavior in this
situation then it could cause problems for that software. However, the
correct behavior is that only the inode owner or a process with
CAP_FOWNER towards the inode owner is allowed to open with O_NOATIME (as
documented in open(2)).

Thanks,
Seth

---

Miklos Szeredi (1):
  ovl: do not fail because of O_NOATIME

 fs/overlayfs/file.c | 11 +++--------
 1 file changed, 3 insertions(+), 8 deletions(-)

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

[PATCH 1/1][SRU F/G] ovl: do not fail because of O_NOATIME

Seth Forshee
From: Miklos Szeredi <[hidden email]>

BugLink: https://bugs.launchpad.net/bugs/1900141

In case the file cannot be opened with O_NOATIME because of lack of
capabilities, then clear O_NOATIME instead of failing.

Remove WARN_ON(), since it would now trigger if O_NOATIME was cleared.
Noticed by Amir Goldstein.

Signed-off-by: Miklos Szeredi <[hidden email]>
(backported from commit b6650dab404c701d7fe08a108b746542a934da84)
Signed-off-by: Seth Forshee <[hidden email]>
---
 fs/overlayfs/file.c | 11 +++--------
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/fs/overlayfs/file.c b/fs/overlayfs/file.c
index 87a399b74f69..0d3ea0cf3e98 100644
--- a/fs/overlayfs/file.c
+++ b/fs/overlayfs/file.c
@@ -43,9 +43,10 @@ static struct file *ovl_open_realfile(const struct file *file,
  err = inode_permission(realinode, MAY_OPEN | acc_mode);
  if (err) {
  realfile = ERR_PTR(err);
- } else if (!inode_owner_or_capable(realinode)) {
- realfile = ERR_PTR(-EPERM);
  } else {
+ if (!inode_owner_or_capable(realinode))
+ flags &= ~O_NOATIME;
+
  ovl_path_real(file->f_path.dentry, &realpath);
  realfile = open_with_fake_path(&realpath, flags, realinode,
        current_cred());
@@ -66,12 +67,6 @@ static int ovl_change_flags(struct file *file, unsigned int flags)
  struct inode *inode = file_inode(file);
  int err;
 
- flags |= OVL_OPEN_FLAGS;
-
- /* If some flag changed that cannot be changed then something's amiss */
- if (WARN_ON((file->f_flags ^ flags) & ~OVL_SETFL_MASK))
- return -EIO;
-
  flags &= OVL_SETFL_MASK;
 
  if (((flags ^ file->f_flags) & O_APPEND) && IS_APPEND(inode))
--
2.29.2


--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

ACK: [PATCH 1/1][SRU F/G] ovl: do not fail because of O_NOATIME

Thadeu Lima de Souza Cascardo-3
Acked-by: Thadeu Lima de Souza Cascardo <[hidden email]>

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

ACK: [PATCH 0/1][SRU F/G] Fix regression opening some files in overlayfs

William Breathitt Gray
In reply to this post by Seth Forshee
On Wed, Jan 06, 2021 at 03:15:14PM -0600, Seth Forshee wrote:

> BugLink: https://bugs.launchpad.net/bugs/1900141
>
> [Impact]
>
> The backports to fix CVE-2020-16120 introduced a regression for overlay
> mounts within user namespaces. Files with ownership outside of the user
> namespace can no longer be accessed, even if allowed by both DAC and
> MAC.
>
> This issue is fixed by the following upstream commit:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b6650dab404c701d7fe08a108b746542a934da84
>
> This commit relaxes the check to remove O_NOATIME from the open flags
> for the file in the lower filesystem when the overlay filesystem mounter
> is not privileged with respect to the underlying inode, rather than
> failing the open as happens now.
>
> [Test Case]
>
> See the lp1900141.sh script attached to the bug report. Prior to the fix
> the script will show failure to access the file from the lower
> filesystem. With the fix the file can be accessed.
>
> [Where problems could occur]
>
> For the most part this patch restores previous behavior of allowing
> access to these files while keeping the enhanced permission checks
> towards the lower filesystem to help prevent unauthorized access to file
> data in the lower filesystem. The one difference in behavior is that
> files in the lower filesystem may no longer be opened with the O_NOATIME
> flag, potentially causing atime updates for these files which were not
> happening before. If any software expects O_NOATIME behavior in this
> situation then it could cause problems for that software. However, the
> correct behavior is that only the inode owner or a process with
> CAP_FOWNER towards the inode owner is allowed to open with O_NOATIME (as
> documented in open(2)).
>
> Thanks,
> Seth
>
> ---
>
> Miklos Szeredi (1):
>   ovl: do not fail because of O_NOATIME
>
>  fs/overlayfs/file.c | 11 +++--------
>  1 file changed, 3 insertions(+), 8 deletions(-)
Acked-by: William Breathitt Gray <[hidden email]>

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

APPLIED: [PATCH 0/1][SRU F/G] Fix regression opening some files in overlayfs

Kleber Souza
In reply to this post by Seth Forshee
On 06.01.21 22:15, Seth Forshee wrote:

> BugLink: https://bugs.launchpad.net/bugs/1900141
>
> [Impact]
>
> The backports to fix CVE-2020-16120 introduced a regression for overlay
> mounts within user namespaces. Files with ownership outside of the user
> namespace can no longer be accessed, even if allowed by both DAC and
> MAC.
>
> This issue is fixed by the following upstream commit:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b6650dab404c701d7fe08a108b746542a934da84
>
> This commit relaxes the check to remove O_NOATIME from the open flags
> for the file in the lower filesystem when the overlay filesystem mounter
> is not privileged with respect to the underlying inode, rather than
> failing the open as happens now.
>
> [Test Case]
>
> See the lp1900141.sh script attached to the bug report. Prior to the fix
> the script will show failure to access the file from the lower
> filesystem. With the fix the file can be accessed.
>
> [Where problems could occur]
>
> For the most part this patch restores previous behavior of allowing
> access to these files while keeping the enhanced permission checks
> towards the lower filesystem to help prevent unauthorized access to file
> data in the lower filesystem. The one difference in behavior is that
> files in the lower filesystem may no longer be opened with the O_NOATIME
> flag, potentially causing atime updates for these files which were not
> happening before. If any software expects O_NOATIME behavior in this
> situation then it could cause problems for that software. However, the
> correct behavior is that only the inode owner or a process with
> CAP_FOWNER towards the inode owner is allowed to open with O_NOATIME (as
> documented in open(2)).
>
> Thanks,
> Seth
>
> ---
>
> Miklos Szeredi (1):
>    ovl: do not fail because of O_NOATIME
>
>   fs/overlayfs/file.c | 11 +++--------
>   1 file changed, 3 insertions(+), 8 deletions(-)
>

Applied to focal/linux and groovy/linux.

Thanks,
Kleber

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team