Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH] proc: Track /proc/$pid/attr/ opener mm_struct
To:     Kees Cook <keescook@chromium.org>,
        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>,
        Casey Schaufler <casey@schaufler-ca.com>
References: <20210608171221.276899-1-keescook@chromium.org>
 <20210614100234.12077-1-youling257@gmail.com>
 <202106140826.7912F27CD@keescook>
From:   Casey Schaufler <casey@schaufler-ca.com>
Message-ID: <17222cd4-3c2b-9d0c-aa51-64b7a50a9c2c@schaufler-ca.com>
Date:   Mon, 14 Jun 2021 10:52:48 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <202106140826.7912F27CD@keescook>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Content-Length: 2578
Precedence: bulk

On 6/14/2021 8:32 AM, 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 retriev=
e pid context" problem.
>>
>> 06-14 02:15:51.165  1685  1685 E ServiceManager: SELinux: getpidcon(pi=
d=3D1682) failed to retrieve pid context.
>> 06-14 02:15:51.166  1685  1685 E ServiceManager: add_service('batteryp=
roperties',1) uid=3D0 - PERMISSION DENIED
>> 06-14 02:15:51.166  1682  1682 I ServiceManager: addService() batteryp=
roperties failed (err -1 - no service manager yet?).  Retrying...
>> 06-14 02:15:51.197  1685  1685 E ServiceManager: SELinux: getpidcon(pi=
d=3D1695) failed to retrieve pid context.
>> 06-14 02:15:51.197  1685  1685 E ServiceManager: add_service('android.=
security.keystore',1) uid=3D1017 - 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(pi=
d=3D1708) failed to retrieve pid context.
>> 06-14 02:15:51.207  1685  1685 E ServiceManager: add_service('android.=
service.gatekeeper.IGateKeeperService',1) uid=3D1000 - 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(pi=
d=3D1693) failed to retrieve pid context.
>> 06-14 02:15:51.275  1692  1692 I cameraserver: ServiceManager: 0xf6d30=
9e0
>> 06-14 02:15:51.275  1685  1685 E ServiceManager: add_service('drm.drmM=
anager',1) uid=3D1019 - PERMISSION DENIED
>> 06-14 02:15:51.276  1693  1693 I ServiceManager: addService() drm.drmM=
anager failed (err -1 - no service manager yet?).  Retrying...
>>
> Argh. Are you able to uncover what userspace is doing here?
>
> So far, my test cases are:
>
> 1) self: open, write, close: allowed
> 2) self: open, clone thread. thread: change privileges, write, close: a=
llowed
> 3) self: open, give to privileged process. privileged process: write: r=
eject

I found an issue under Smack where a privileged process opened
/proc/self/attr/smack/current, wrote to it successfully, then tried
to write to it again, which failed because the cred has changed.=20
That's not a common use case. The usual case is open, write, close.
If ServiceManager is assuming that it can leave a descriptor open
while manipulations are in progress it could encounter the same kind
of problem.