MIME-Version: 1.0
References: <20230120102512.3195094-1-gscrivan@redhat.com> <20230124015348.6rvic5g6ymsfvj4e@senku>
In-Reply-To: <20230124015348.6rvic5g6ymsfvj4e@senku>
From:   Andrei Vagin <avagin@gmail.com>
Date:   Tue, 24 Jan 2023 11:17:15 -0800
Message-ID: <CANaxB-xczp4NSHUN0xCoRve+OgaGEQuac5w2X4mqegmsQQT7ug@mail.gmail.com>
Subject: Re: [PATCH v3 1/2] exec: add PR_HIDE_SELF_EXE prctl
To:     Aleksa Sarai <cyphar@cyphar.com>
Cc:     Giuseppe Scrivano <gscrivan@redhat.com>,
        linux-kernel@vger.kernel.org, keescook@chromium.org,
        bristot@redhat.com, ebiederm@xmission.com, brauner@kernel.org,
        viro@zeniv.linux.org.uk, alexl@redhat.com, peterz@infradead.org,
        bmasney@redhat.com
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Mon, Jan 23, 2023 at 6:04 PM Aleksa Sarai <cyphar@cyphar.com> wrote:
>
> On 2023-01-20, Giuseppe Scrivano <gscrivan@redhat.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