[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHC9VhQfPn88QZSMEw1d04V4f9MWwJxUDd-ibTd+6GTBiYLAPg@mail.gmail.com>
Date: Mon, 11 Oct 2021 17:34:15 -0400
From: Paul Moore <paul@...l-moore.com>
To: Casey Schaufler <casey@...aufler-ca.com>
Cc: Todd Kjos <tkjos@...gle.com>, gregkh@...uxfoundation.org,
arve@...roid.com, tkjos@...roid.com, maco@...roid.com,
christian@...uner.io, James Morris <jmorris@...ei.org>,
Serge Hallyn <serge@...lyn.com>,
Stephen Smalley <stephen.smalley.work@...il.com>,
Eric Paris <eparis@...isplace.org>, keescook@...omium.org,
jannh@...gle.com, Jeffrey Vander Stoep <jeffv@...gle.com>,
zohar@...ux.ibm.com, linux-security-module@...r.kernel.org,
selinux@...r.kernel.org, devel@...verdev.osuosl.org,
linux-kernel@...r.kernel.org, joel@...lfernandes.org,
kernel-team@...roid.com, stable@...r.kernel.org
Subject: Re: [PATCH v4 3/3] binder: use euid from cred instead of using task
On Fri, Oct 8, 2021 at 5:25 PM Casey Schaufler <casey@...aufler-ca.com> wrote:
>
> On 10/8/2021 2:12 PM, Paul Moore wrote:
> > On Wed, Oct 6, 2021 at 8:46 PM Todd Kjos <tkjos@...gle.com> wrote:
> >> Set a transaction's sender_euid from the 'struct cred'
> >> saved at binder_open() instead of looking up the euid
> >> from the binder proc's 'struct task'. This ensures
> >> the euid is associated with the security context that
> >> of the task that opened binder.
> >>
> >> Fixes: 457b9a6f09f0 ("Staging: android: add binder driver")
> >> Signed-off-by: Todd Kjos <tkjos@...gle.com>
> >> Suggested-by: Stephen Smalley <stephen.smalley.work@...il.com>
> >> Cc: stable@...r.kernel.org # 4.4+
> >> ---
> >> v3: added this patch to series
> >>
> >> drivers/android/binder.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> > This is an interesting ordering of the patches. Unless I'm missing
> > something I would have expected patch 3/3 to come first, followed by
> > 2/3, with patch 1/3 at the end; basically the reverse of what was
> > posted here.
> >
> > My reading of the previous thread was that Casey has made his peace
> > with these changes
>
> Yes. I will address the stacking concerns more directly.
> I am still somewhat baffled by the intent of the hook, the data
> passed to it, and the SELinux policy enforcement decisions, but
> that's beyond my scope.
Okay, I just wanted to make sure there were no objections.
--
paul moore
www.paul-moore.com
Powered by blists - more mailing lists