From: Kees Cook <keescook@chromium.org>
To: youling257 <youling257@gmail.com>
Cc: torvalds@linux-foundation.org, christian.brauner@ubuntu.com,
andrea.righi@canonical.com, linux-kernel@vger.kernel.org,
stable@vger.kernel.org, regressions@lists.linux.dev,
linux-security-module@vger.kernel.org,
Paul Moore <paul@paul-moore.com>,
Stephen Smalley <stephen.smalley.work@gmail.com>,
SElinux list <selinux@vger.kernel.org>
Subject: Re: [PATCH] proc: Track /proc/$pid/attr/ opener mm_struct
Date: Mon, 14 Jun 2021 09:45:15 -0700 [thread overview]
Message-ID: <202106140941.7CE5AE64@keescook> (raw)
In-Reply-To: <202106140826.7912F27CD@keescook>
On Mon, Jun 14, 2021 at 08:32:35AM -0700, Kees Cook wrote:
> On Mon, Jun 14, 2021 at 06:02:34PM +0800, youling257 wrote:
> > I used mainline kernel on android, this patch cause "failed to retrieve pid context" problem.
> >
> > 06-14 02:15:51.165 1685 1685 E ServiceManager: SELinux: getpidcon(pid=1682) failed to retrieve pid context.
I found getpidcon() in libselinux:
https://github.com/SELinuxProject/selinux/blob/master/libselinux/src/procattr.c#L159
> > 06-14 02:15:51.166 1685 1685 E ServiceManager: add_service('batteryproperties',1) uid=0 - PERMISSION DENIED
> > 06-14 02:15:51.166 1682 1682 I ServiceManager: addService() batteryproperties failed (err -1 - no service manager yet?). Retrying...
> > 06-14 02:15:51.197 1685 1685 E ServiceManager: SELinux: getpidcon(pid=1695) failed to retrieve pid context.
> > 06-14 02:15:51.197 1685 1685 E ServiceManager: add_service('android.security.keystore',1) uid=1017 - PERMISSION DENIED
> > 06-14 02:15:51.198 1695 1695 I ServiceManager: addService() android.security.keystore failed (err -1 - no service manager yet?). Retrying...
> > 06-14 02:15:51.207 1685 1685 E ServiceManager: SELinux: getpidcon(pid=1708) failed to retrieve pid context.
> > 06-14 02:15:51.207 1685 1685 E ServiceManager: add_service('android.service.gatekeeper.IGateKeeperService',1) uid=1000 - PERMISSION DENIED
> > 06-14 02:15:51.207 1708 1708 I ServiceManager: addService() android.service.gatekeeper.IGateKeeperService failed (err -1 - no service manager yet?). Retrying...
> > 06-14 02:15:51.275 1685 1685 E ServiceManager: SELinux: getpidcon(pid=1693) failed to retrieve pid context.
> > 06-14 02:15:51.275 1692 1692 I cameraserver: ServiceManager: 0xf6d309e0
> > 06-14 02:15:51.275 1685 1685 E ServiceManager: add_service('drm.drmManager',1) uid=1019 - PERMISSION DENIED
> > 06-14 02:15:51.276 1693 1693 I ServiceManager: addService() drm.drmManager failed (err -1 - no service manager yet?). Retrying...
> >
>
> Argh. Are you able to uncover what userspace is doing here?
It looks like this is a case of attempting to _read_ the attr file, and
the new opener check was requiring the opener/target relationship pass
the mm_access() checks, which is clearly too strict.
> So far, my test cases are:
>
> 1) self: open, write, close: allowed
> 2) self: open, clone thread. thread: change privileges, write, close: allowed
> 3) self: open, give to privileged process. privileged process: write: reject
I've now added:
4) self: open privileged process's attr, read, close: allowed
Can folks please test this patch to double-check?
diff --git a/fs/proc/base.c b/fs/proc/base.c
index 7118ebe38fa6..7c55301674e0 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -2676,7 +2676,14 @@ 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);
+ struct mm_struct *mm = __mem_open(inode, file, PTRACE_MODE_READ_FSCREDS);
+
+ /* Reads do not require mm_struct access. */
+ if (IS_ERR(mm))
+ mm = NULL;
+
+ file->private_data = mm;
+ return 0;
}
static ssize_t proc_pid_attr_read(struct file * file, char __user * buf,
@@ -2709,7 +2716,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->private_data != current->mm)
+ if (!file->private_data || file->private_data != current->mm)
return -EPERM;
rcu_read_lock();
Wheee.
--
Kees Cook
next prev parent reply other threads:[~2021-06-14 16:45 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-08 17:12 [PATCH] proc: Track /proc/$pid/attr/ opener mm_struct Kees Cook
2021-06-09 6:40 ` Christian Brauner
2021-06-14 10:02 ` youling257
2021-06-14 15:32 ` Kees Cook
2021-06-14 16:45 ` Kees Cook [this message]
2021-06-14 18:02 ` Linus Torvalds
2021-06-14 18:46 ` youling 257
2021-06-14 22:50 ` Kees Cook
2021-06-15 1:55 ` youling 257
2021-06-15 18:19 ` Linus Torvalds
2021-06-15 21:50 ` Kees Cook
2021-06-16 5:56 ` Greg KH
2021-06-16 5:15 ` youling 257
2021-06-14 17:52 ` Casey Schaufler
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=202106140941.7CE5AE64@keescook \
--to=keescook@chromium.org \
--cc=andrea.righi@canonical.com \
--cc=christian.brauner@ubuntu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=paul@paul-moore.com \
--cc=regressions@lists.linux.dev \
--cc=selinux@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=stephen.smalley.work@gmail.com \
--cc=torvalds@linux-foundation.org \
--cc=youling257@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).