[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANaxB-xczp4NSHUN0xCoRve+OgaGEQuac5w2X4mqegmsQQT7ug@mail.gmail.com>
Date: Tue, 24 Jan 2023 11:17:15 -0800
From: Andrei Vagin <avagin@...il.com>
To: Aleksa Sarai <cyphar@...har.com>
Cc: Giuseppe Scrivano <gscrivan@...hat.com>,
linux-kernel@...r.kernel.org, keescook@...omium.org,
bristot@...hat.com, ebiederm@...ssion.com, brauner@...nel.org,
viro@...iv.linux.org.uk, alexl@...hat.com, peterz@...radead.org,
bmasney@...hat.com
Subject: Re: [PATCH v3 1/2] exec: add PR_HIDE_SELF_EXE prctl
On Mon, Jan 23, 2023 at 6:04 PM Aleksa Sarai <cyphar@...har.com> wrote:
>
> On 2023-01-20, Giuseppe Scrivano <gscrivan@...hat.com> wrote:
> > This patch adds a new prctl called PR_HIDE_SELF_EXE which allows
> > processes to hide their own /proc/*/exe file. When this prctl is
> > used, every access to /proc/*/exe for the calling process will
> > fail with ENOENT.
> >
> > This is useful for preventing issues like CVE-2019-5736, where an
> > attacker can gain host root access by overwriting the binary
> > in OCI runtimes through file-descriptor mishandling in containers.
> >
> > The current fix for CVE-2019-5736 is to create a read-only copy or
> > a bind-mount of the current executable, and then re-exec the current
> > process. With the new prctl, the read-only copy or bind-mount copy is
> > not needed anymore.
> >
> > While map_files/ also might contain symlinks to files in host,
> > proc_map_files_get_link() permissions checks are already sufficient.
>
> I suspect this doesn't protect against the execve("/proc/self/exe")
> tactic (because it clears the bit on execve), so I'm not sure this is
> much safer than PR_SET_DUMPABLE (yeah, it stops root in the source
> userns from accessing /proc/$pid/exe but the above attack makes that no
> longer that important).
>
> I think the only way to fix this properly is by blocking re-opens of
> magic links that have more permissions than they originally did. I just
> got back from vacation, but I'm working on fixing up [1] so it's ready
> to be an RFC so we can close this hole once and for all.
>
> [1]: https://github.com/cyphar/linux/tree/magiclink/open_how-reopen
pls add me into cc when you will send this change. We need to be sure
that it doesn't break CRIU...
Thanks,
Andrei
Powered by blists - more mailing lists