All of lore.kernel.org
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Kalesh Singh <kaleshsingh@google.com>
Cc: Kees Cook <keescook@chromium.org>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Christian Brauner <christian.brauner@ubuntu.com>,
	Christian Koenig <christian.koenig@amd.com>,
	Suren Baghdasaryan <surenb@google.com>,
	Hridya Valsaraju <hridya@google.com>,
	Android Kernel Team <kernel-team@android.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH] procfs: Prevent unpriveleged processes accessing fdinfo
Date: Sat, 10 Jul 2021 11:21:34 -0700	[thread overview]
Message-ID: <CAHk-=whDkekE8n2LdPiKHeTdRnV--ys0V0nPZ76oPaE0fn-d+g@mail.gmail.com> (raw)
In-Reply-To: <20210708155647.44208-1-kaleshsingh@google.com>

On Thu, Jul 8, 2021 at 8:57 AM Kalesh Singh <kaleshsingh@google.com> wrote:
>
> The file permissions on the fdinfo dir from were changed from
> S_IRUSR|S_IXUSR to S_IRUGO|S_IXUGO, and a PTRACE_MODE_READ check was
> added for opening the fdinfo files [1]. However, the ptrace permission
> check was not added to the directory, allowing anyone to get the open FD
> numbers by reading the fdinfo directory.
>
> Add the missing ptrace permission check for opening the fdinfo directory.

The more I look at this, the more I feel like we should look at
instead changing how "get_proc_task()" works.

That's one of the core functions for /proc, and I wonder if we
couldn't just make it refuse to look up a task that has gone through a
suid execve() since the proc inode was opened.

I don't think it's basically ever ok to open something for one thread,
and then use it after the thread has gone through a suid thing.

In fact, I wonder if we could make it even stricter, and go "any exec
at all", but I think a suid exec might be the minimum we should do.

Then the logic really becomes very simple: we did the permission
checks at open time (like UNIX permission checks should be done), and
"get_proc_task()" basically verifies that "yeah, that open-time
decision is still valid".

Wouldn't that make a lot of sense?

             Linus

  reply	other threads:[~2021-07-10 18:21 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-08 15:56 [PATCH] procfs: Prevent unpriveleged processes accessing fdinfo Kalesh Singh
2021-07-10 18:21 ` Linus Torvalds [this message]
2021-07-12 19:45   ` Kalesh Singh
2021-07-12 20:02   ` Eric W. Biederman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAHk-=whDkekE8n2LdPiKHeTdRnV--ys0V0nPZ76oPaE0fn-d+g@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=akpm@linux-foundation.org \
    --cc=christian.brauner@ubuntu.com \
    --cc=christian.koenig@amd.com \
    --cc=ebiederm@xmission.com \
    --cc=hridya@google.com \
    --cc=kaleshsingh@google.com \
    --cc=keescook@chromium.org \
    --cc=kernel-team@android.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=surenb@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.