All of lore.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Kalesh Singh <kaleshsingh@google.com>,
	Kees Cook <keescook@chromium.org>,
	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: Mon, 12 Jul 2021 15:02:38 -0500	[thread overview]
Message-ID: <87czrn8fmp.fsf@disp2133> (raw)
In-Reply-To: <CAHk-=whDkekE8n2LdPiKHeTdRnV--ys0V0nPZ76oPaE0fn-d+g@mail.gmail.com> (Linus Torvalds's message of "Sat, 10 Jul 2021 11:21:34 -0700")

Linus Torvalds <torvalds@linux-foundation.org> writes:

> 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.

The practical implementation that I can see is to add a
exec_id attribute into the proc inode and to modify proc_pid_make_inode
to take a new exec_id parameter.

There are some directories like /proc/PPP/, /proc/PPP/task/TTT/,
/proc/PPP/net where it is both safe and appropriate to allow caching the
reference over a suid exec.

To handle that I would have a flag somewhere (possibly a special exec_id
value) that indicates we don't care about the exec id.

Once get_proc_task is taught to handle both cases and the appropriate
exec_id is passed to proc_pid_make_inode proc_pid_invalidate works
automatically.  So I think that is all we really need to do.

> 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?

Roughly.  I want to use reuse exec_id but that seems a bit strong for
have the permissions changed.  Checking ->cred is too sensitive.
So it is a bit fiddly to get right.

Limiting this to suid-exec (and equivalent) seems like the proper
filter, because it is when the permissions have fundamentally changed.

I just don't think this should be blanket for everything that uses
get_prock_task.

Eric

      parent reply	other threads:[~2021-07-12 20:03 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
2021-07-12 19:45   ` Kalesh Singh
2021-07-12 20:02   ` Eric W. Biederman [this message]

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=87czrn8fmp.fsf@disp2133 \
    --to=ebiederm@xmission.com \
    --cc=akpm@linux-foundation.org \
    --cc=christian.brauner@ubuntu.com \
    --cc=christian.koenig@amd.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 \
    --cc=torvalds@linux-foundation.org \
    /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.