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
