linux-kernel - Re: [PATCH] proc: Track /proc/$pid/attr/ opener mm

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAOzgRdZJeN6sQWP=Ou0H3bTrp+7ijKuJikG-f4eer5f1oVjrCQ@mail.gmail.com>
Date:   Tue, 15 Jun 2021 02:46:19 +0800
From:   youling 257 <youling257@...il.com>
To:     Kees Cook <keescook@...omium.org>
Cc:     torvalds@...ux-foundation.org, christian.brauner@...ntu.com,
        andrea.righi@...onical.com, linux-kernel@...r.kernel.org,
        stable@...r.kernel.org, regressions@...ts.linux.dev,
        linux-security-module@...r.kernel.org,
        Paul Moore <paul@...l-moore.com>,
        Stephen Smalley <stephen.smalley.work@...il.com>,
        SElinux list <selinux@...r.kernel.org>
Subject: Re: [PATCH] proc: Track /proc/$pid/attr/ opener mm_struct

I test this patch cause "init: cannot setexeccon(u:r:ueventd:s0)
operation not permitted.
init ctrl_write_limited.

2021-06-15 0:45 GMT+08:00, Kees Cook <keescook@...omium.org>:
> 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
>

Download attachment "wp_ss_20210615_0001.png" of type "image/png" (1198107 bytes)