From: "T.J. Mercier" <tjmercier@google.com> To: Paul Moore <paul@paul-moore.com> Cc: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>, "Arve Hjønnevåg" <arve@android.com>, "Todd Kjos" <tkjos@android.com>, "Martijn Coenen" <maco@android.com>, "Joel Fernandes" <joel@joelfernandes.org>, "Christian Brauner" <brauner@kernel.org>, "Carlos Llamas" <cmllamas@google.com>, "Suren Baghdasaryan" <surenb@google.com>, "James Morris" <jmorris@namei.org>, "Serge E. Hallyn" <serge@hallyn.com>, "Stephen Smalley" <stephen.smalley.work@gmail.com>, "Eric Paris" <eparis@parisplace.org>, hannes@cmpxchg.org, daniel.vetter@ffwll.ch, android-mm@google.com, jstultz@google.com, jeffv@google.com, linux-security-module@vger.kernel.org, selinux@vger.kernel.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 4/4] security: binder: Add binder object flags to selinux_binder_transfer_file Date: Mon, 23 Jan 2023 20:47:14 -0800 [thread overview] Message-ID: <CABdmKX0EoAw+TYk29z1dJXtWekfw22KDQAkQPGiDAh8ojeKd1A@mail.gmail.com> (raw) In-Reply-To: <CABdmKX0Jc3OTnSMv_GoL0eEo=7W9dP29+r5K=PfF84xAUHviBw@mail.gmail.com> On Mon, Jan 23, 2023 at 2:04 PM T.J. Mercier <tjmercier@google.com> wrote: > > > > On Mon, Jan 23, 2023 at 1:36 PM Paul Moore <paul@paul-moore.com> wrote: >> >> On Mon, Jan 23, 2023 at 2:18 PM T.J. Mercier <tjmercier@google.com> wrote: >> > >> > Any process can cause a memory charge transfer to occur to any other >> > process when transmitting a file descriptor through binder. This should >> > only be possible for central allocator processes, so the binder object >> > flags are added to the security_binder_transfer_file hook so that LSMs >> > can enforce restrictions on charge transfers. >> > >> > Signed-off-by: T.J. Mercier <tjmercier@google.com> >> > --- >> > drivers/android/binder.c | 2 +- >> > include/linux/lsm_hook_defs.h | 2 +- >> > include/linux/lsm_hooks.h | 5 ++++- >> > include/linux/security.h | 6 ++++-- >> > security/security.c | 4 ++-- >> > security/selinux/hooks.c | 13 ++++++++++++- >> > security/selinux/include/classmap.h | 2 +- >> > 7 files changed, 25 insertions(+), 9 deletions(-) >> >> ... >> >> > diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c >> > index 3c5be76a9199..d4cfca3c9a3b 100644 >> > --- a/security/selinux/hooks.c >> > +++ b/security/selinux/hooks.c >> > @@ -88,6 +88,7 @@ >> > #include <linux/bpf.h> >> > #include <linux/kernfs.h> >> > #include <linux/stringhash.h> /* for hashlen_string() */ >> > +#include <uapi/linux/android/binder.h> >> > #include <uapi/linux/mount.h> >> > #include <linux/fsnotify.h> >> > #include <linux/fanotify.h> >> > @@ -2029,7 +2030,8 @@ static int selinux_binder_transfer_binder(const struct cred *from, >> > >> > static int selinux_binder_transfer_file(const struct cred *from, >> > const struct cred *to, >> > - struct file *file) >> > + struct file *file, >> > + u32 binder_object_flags) >> > { >> > u32 sid = cred_sid(to); >> > struct file_security_struct *fsec = selinux_file(file); >> > @@ -2038,6 +2040,15 @@ static int selinux_binder_transfer_file(const struct cred *from, >> > struct common_audit_data ad; >> > int rc; >> > >> > + if (binder_object_flags & BINDER_FD_FLAG_XFER_CHARGE) { >> > + rc = avc_has_perm(&selinux_state, >> > + cred_sid(from), sid, >> > + SECCLASS_BINDER, BINDER__TRANSFER_CHARGE, >> > + NULL); >> > + if (rc) >> > + return rc; >> > + } >> > + >> > ad.type = LSM_AUDIT_DATA_PATH; >> > ad.u.path = file->f_path; >> > >> > diff --git a/security/selinux/include/classmap.h b/security/selinux/include/classmap.h >> > index a3c380775d41..2eef180d10d7 100644 >> > --- a/security/selinux/include/classmap.h >> > +++ b/security/selinux/include/classmap.h >> > @@ -172,7 +172,7 @@ const struct security_class_mapping secclass_map[] = { >> > { "tun_socket", >> > { COMMON_SOCK_PERMS, "attach_queue", NULL } }, >> > { "binder", { "impersonate", "call", "set_context_mgr", "transfer", >> > - NULL } }, >> > + "transfer_charge", NULL } }, >> > { "cap_userns", >> > { COMMON_CAP_PERMS, NULL } }, >> > { "cap2_userns", >> >> My first take on reading these changes above is that you've completely >> ignored my previous comments about SELinux access controls around >> resource management. You've leveraged the existing LSM/SELinux hook >> as we discussed previously, that's good, but can you explain what >> changes you've made to address my concerns about one-off resource >> management controls? >> > It's been a couple of weeks since v1 so I've sent this update out now to incorporate all the other feedback so far to make sure it's headed in the right direction. I've tried opening up a discussion about this rather unique case, but there's been no activity on that yet. > Someone pointed out this didn't make it to the lists. Retrying. >> -- >> paul-moore.com
WARNING: multiple messages have this Message-ID (diff)
From: "T.J. Mercier" <tjmercier-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> To: Paul Moore <paul-r2n+y4ga6xFZroRs9YW3xA@public.gmane.org> Cc: "Greg Kroah-Hartman" <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>, "Arve Hjønnevåg" <arve-z5hGa2qSFaRBDgjK7y7TUQ@public.gmane.org>, "Todd Kjos" <tkjos-z5hGa2qSFaRBDgjK7y7TUQ@public.gmane.org>, "Martijn Coenen" <maco-z5hGa2qSFaRBDgjK7y7TUQ@public.gmane.org>, "Joel Fernandes" <joel-QYYGw3jwrUn5owFQY34kdNi2O/JbrIOy@public.gmane.org>, "Christian Brauner" <brauner-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, "Carlos Llamas" <cmllamas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>, "Suren Baghdasaryan" <surenb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>, "James Morris" <jmorris-gx6/JNMH7DfYtjvyW6yDsg@public.gmane.org>, "Serge E. Hallyn" <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>, "Stephen Smalley" <stephen.smalley.work-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, "Eric Paris" <eparis-FjpueFixGhCM4zKIHC2jIg@public.gmane.org>, hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org, daniel.vetter-/w4YWyX8dFk@public.gmane.org, android-mm-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org, jstultz-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org, jeffv-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org, linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, selinux-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Subject: Re: [PATCH v2 4/4] security: binder: Add binder object flags to selinux_binder_transfer_file Date: Mon, 23 Jan 2023 20:47:14 -0800 [thread overview] Message-ID: <CABdmKX0EoAw+TYk29z1dJXtWekfw22KDQAkQPGiDAh8ojeKd1A@mail.gmail.com> (raw) In-Reply-To: <CABdmKX0Jc3OTnSMv_GoL0eEo=7W9dP29+r5K=PfF84xAUHviBw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> On Mon, Jan 23, 2023 at 2:04 PM T.J. Mercier <tjmercier-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote: > > > > On Mon, Jan 23, 2023 at 1:36 PM Paul Moore <paul-r2n+y4ga6xFZroRs9YW3xA@public.gmane.org> wrote: >> >> On Mon, Jan 23, 2023 at 2:18 PM T.J. Mercier <tjmercier-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote: >> > >> > Any process can cause a memory charge transfer to occur to any other >> > process when transmitting a file descriptor through binder. This should >> > only be possible for central allocator processes, so the binder object >> > flags are added to the security_binder_transfer_file hook so that LSMs >> > can enforce restrictions on charge transfers. >> > >> > Signed-off-by: T.J. Mercier <tjmercier-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> >> > --- >> > drivers/android/binder.c | 2 +- >> > include/linux/lsm_hook_defs.h | 2 +- >> > include/linux/lsm_hooks.h | 5 ++++- >> > include/linux/security.h | 6 ++++-- >> > security/security.c | 4 ++-- >> > security/selinux/hooks.c | 13 ++++++++++++- >> > security/selinux/include/classmap.h | 2 +- >> > 7 files changed, 25 insertions(+), 9 deletions(-) >> >> ... >> >> > diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c >> > index 3c5be76a9199..d4cfca3c9a3b 100644 >> > --- a/security/selinux/hooks.c >> > +++ b/security/selinux/hooks.c >> > @@ -88,6 +88,7 @@ >> > #include <linux/bpf.h> >> > #include <linux/kernfs.h> >> > #include <linux/stringhash.h> /* for hashlen_string() */ >> > +#include <uapi/linux/android/binder.h> >> > #include <uapi/linux/mount.h> >> > #include <linux/fsnotify.h> >> > #include <linux/fanotify.h> >> > @@ -2029,7 +2030,8 @@ static int selinux_binder_transfer_binder(const struct cred *from, >> > >> > static int selinux_binder_transfer_file(const struct cred *from, >> > const struct cred *to, >> > - struct file *file) >> > + struct file *file, >> > + u32 binder_object_flags) >> > { >> > u32 sid = cred_sid(to); >> > struct file_security_struct *fsec = selinux_file(file); >> > @@ -2038,6 +2040,15 @@ static int selinux_binder_transfer_file(const struct cred *from, >> > struct common_audit_data ad; >> > int rc; >> > >> > + if (binder_object_flags & BINDER_FD_FLAG_XFER_CHARGE) { >> > + rc = avc_has_perm(&selinux_state, >> > + cred_sid(from), sid, >> > + SECCLASS_BINDER, BINDER__TRANSFER_CHARGE, >> > + NULL); >> > + if (rc) >> > + return rc; >> > + } >> > + >> > ad.type = LSM_AUDIT_DATA_PATH; >> > ad.u.path = file->f_path; >> > >> > diff --git a/security/selinux/include/classmap.h b/security/selinux/include/classmap.h >> > index a3c380775d41..2eef180d10d7 100644 >> > --- a/security/selinux/include/classmap.h >> > +++ b/security/selinux/include/classmap.h >> > @@ -172,7 +172,7 @@ const struct security_class_mapping secclass_map[] = { >> > { "tun_socket", >> > { COMMON_SOCK_PERMS, "attach_queue", NULL } }, >> > { "binder", { "impersonate", "call", "set_context_mgr", "transfer", >> > - NULL } }, >> > + "transfer_charge", NULL } }, >> > { "cap_userns", >> > { COMMON_CAP_PERMS, NULL } }, >> > { "cap2_userns", >> >> My first take on reading these changes above is that you've completely >> ignored my previous comments about SELinux access controls around >> resource management. You've leveraged the existing LSM/SELinux hook >> as we discussed previously, that's good, but can you explain what >> changes you've made to address my concerns about one-off resource >> management controls? >> > It's been a couple of weeks since v1 so I've sent this update out now to incorporate all the other feedback so far to make sure it's headed in the right direction. I've tried opening up a discussion about this rather unique case, but there's been no activity on that yet. > Someone pointed out this didn't make it to the lists. Retrying. >> -- >> paul-moore.com
next prev parent reply other threads:[~2023-01-24 4:47 UTC|newest] Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-01-23 19:17 [PATCH v2 0/4] Track exported dma-buffers with memcg T.J. Mercier 2023-01-23 19:17 ` T.J. Mercier 2023-01-23 19:17 ` T.J. Mercier 2023-01-23 19:17 ` [PATCH v2 1/4] memcg: Track exported dma-buffers T.J. Mercier 2023-01-23 19:17 ` T.J. Mercier 2023-01-23 19:17 ` T.J. Mercier 2023-01-24 14:59 ` Michal Hocko 2023-01-24 14:59 ` Michal Hocko 2023-01-24 18:55 ` T.J. Mercier 2023-01-24 18:55 ` T.J. Mercier 2023-01-25 12:05 ` Michal Hocko 2023-01-25 12:05 ` Michal Hocko 2023-01-25 20:04 ` T.J. Mercier 2023-01-25 20:04 ` T.J. Mercier 2023-01-24 19:46 ` Shakeel Butt 2023-01-24 19:46 ` Shakeel Butt 2023-01-24 19:46 ` Shakeel Butt 2023-01-25 11:52 ` Michal Hocko 2023-01-25 11:52 ` Michal Hocko 2023-01-25 17:30 ` Tvrtko Ursulin 2023-01-25 17:30 ` Tvrtko Ursulin 2023-01-25 20:04 ` T.J. Mercier 2023-01-25 20:04 ` T.J. Mercier 2023-01-25 20:04 ` T.J. Mercier 2023-01-31 14:00 ` Tvrtko Ursulin 2023-01-31 14:00 ` Tvrtko Ursulin 2023-01-31 14:00 ` Tvrtko Ursulin 2023-02-01 1:49 ` T.J. Mercier 2023-02-01 1:49 ` T.J. Mercier 2023-02-01 1:49 ` T.J. Mercier 2023-02-01 14:23 ` Tvrtko Ursulin 2023-02-01 14:23 ` Tvrtko Ursulin 2023-02-01 14:23 ` Tvrtko Ursulin 2023-02-01 14:52 ` Tvrtko Ursulin 2023-02-01 14:52 ` Tvrtko Ursulin 2023-02-01 14:52 ` Tvrtko Ursulin 2023-02-02 23:43 ` T.J. Mercier 2023-02-02 23:43 ` T.J. Mercier 2023-02-02 23:43 ` T.J. Mercier 2023-02-03 9:27 ` Tvrtko Ursulin 2023-02-03 9:27 ` Tvrtko Ursulin 2023-02-03 9:27 ` Tvrtko Ursulin 2023-02-02 23:43 ` T.J. Mercier 2023-02-02 23:43 ` T.J. Mercier 2023-02-02 23:43 ` T.J. Mercier 2023-02-03 9:46 ` Tvrtko Ursulin 2023-02-03 9:46 ` Tvrtko Ursulin 2023-02-03 9:46 ` Tvrtko Ursulin 2023-01-23 19:17 ` [PATCH v2 2/4] dmabuf: Add cgroup charge transfer function T.J. Mercier 2023-01-23 19:17 ` T.J. Mercier 2023-01-23 19:17 ` T.J. Mercier 2023-01-23 19:17 ` [PATCH v2 3/4] binder: Add flags to relinquish ownership of fds T.J. Mercier 2023-01-25 4:20 ` kernel test robot 2023-01-25 17:30 ` Carlos Llamas 2023-01-25 22:07 ` T.J. Mercier 2023-01-23 19:17 ` [PATCH v2 4/4] security: binder: Add binder object flags to selinux_binder_transfer_file T.J. Mercier 2023-01-23 19:17 ` T.J. Mercier 2023-01-23 21:36 ` Paul Moore 2023-01-23 21:36 ` Paul Moore [not found] ` <CABdmKX0Jc3OTnSMv_GoL0eEo=7W9dP29+r5K=PfF84xAUHviBw@mail.gmail.com> 2023-01-24 4:47 ` T.J. Mercier [this message] 2023-01-24 4:47 ` T.J. Mercier
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=CABdmKX0EoAw+TYk29z1dJXtWekfw22KDQAkQPGiDAh8ojeKd1A@mail.gmail.com \ --to=tjmercier@google.com \ --cc=android-mm@google.com \ --cc=arve@android.com \ --cc=brauner@kernel.org \ --cc=cgroups@vger.kernel.org \ --cc=cmllamas@google.com \ --cc=daniel.vetter@ffwll.ch \ --cc=eparis@parisplace.org \ --cc=gregkh@linuxfoundation.org \ --cc=hannes@cmpxchg.org \ --cc=jeffv@google.com \ --cc=jmorris@namei.org \ --cc=joel@joelfernandes.org \ --cc=jstultz@google.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-security-module@vger.kernel.org \ --cc=maco@android.com \ --cc=paul@paul-moore.com \ --cc=selinux@vger.kernel.org \ --cc=serge@hallyn.com \ --cc=stephen.smalley.work@gmail.com \ --cc=surenb@google.com \ --cc=tkjos@android.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.