Bug#990089: linux-image-4.19.0-17-amd64: lxc-attach fails with Failed to set AppArmor label unconfined
Hi Mark,
On Sun, Jun 20, 2021 at 10:44:29AM +0100, Mark Grant wrote:
> Package: src:linux
> Version: 4.19.194-1
> Severity: normal
>
> Dear Maintainer,
>
> After upgrading from linux-image-4.19.0-16-amd64 to linux-image-4.19.0-17-amd64
> attaching an unprivileged linux container fails with the message:
> lxc-attach: debian-buster-amd64-basic: lsm/lsm.c: lsm_process_label_set_at: 174
> Operation not permitted - Failed to set AppArmor label "unconfined"
> Rebooting into linux-image-4.19.0-16-amd64 with no other changes, the lxc
> system works as expected.
I think this is the same issue as in #990072, would you be able to
test the patch as commited
https://salsa.debian.org/kernel-team/linux/-/commit/d3fc7c8514bed949d8797cfd3a50a1bed95629c0
?
Regards,
Salvatore
From: Kees Cook <keescook@chromium.org>
Date: Tue, 8 Jun 2021 10:12:21 -0700
Subject: proc: Track /proc/$pid/attr/ opener mm_struct
Origin: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit?id=1f41b8f9577907fba56684231c7be89c8243d960
Bug-Debian: https://bugs.debian.org/990072
commit 591a22c14d3f45cc38bd1931c593c221df2f1881 upstream.
Commit bfb819ea20ce ("proc: Check /proc/$pid/attr/ writes against file opener")
tried to make sure that there could not be a confusion between the opener of
a /proc/$pid/attr/ file and the writer. It used struct cred to make sure
the privileges didn't change. However, there were existing cases where a more
privileged thread was passing the opened fd to a differently privileged thread
(during container setup). Instead, use mm_struct to track whether the opener
and writer are still the same process. (This is what several other proc files
already do, though for different reasons.)
Reported-by: Christian Brauner <christian.brauner@ubuntu.com>
Reported-by: Andrea Righi <andrea.righi@canonical.com>
Tested-by: Andrea Righi <andrea.righi@canonical.com>
Fixes: bfb819ea20ce ("proc: Check /proc/$pid/attr/ writes against file opener")
Cc: stable@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/proc/base.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/fs/proc/base.c b/fs/proc/base.c
index bc736ea1192a..9f331abc202d 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -2535,6 +2535,11 @@ static int proc_pident_readdir(struct file *file, struct dir_context *ctx,
}
#ifdef CONFIG_SECURITY
+static int proc_pid_attr_open(struct inode *inode, struct file *file)
+{
+ return __mem_open(inode, file, PTRACE_MODE_READ_FSCREDS);
+}
+
static ssize_t proc_pid_attr_read(struct file * file, char __user * buf,
size_t count, loff_t *ppos)
{
@@ -2565,7 +2570,7 @@ static ssize_t proc_pid_attr_write(struct file * file, const char __user * buf,
int rv;
/* A task may only write when it was the opener. */
- if (file->f_cred != current_real_cred())
+ if (file->private_data != current->mm)
return -EPERM;
rcu_read_lock();
@@ -2613,9 +2618,11 @@ static ssize_t proc_pid_attr_write(struct file * file, const char __user * buf,
}
static const struct file_operations proc_pid_attr_operations = {
+ .open = proc_pid_attr_open,
.read = proc_pid_attr_read,
.write = proc_pid_attr_write,
.llseek = generic_file_llseek,
+ .release = mem_release,
};
static const struct pid_entry attr_dir_stuff[] = {
--
2.32.0
Reply to: