Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id F03E3C25B50 for ; Mon, 23 Jan 2023 21:36:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232464AbjAWVgr (ORCPT ); Mon, 23 Jan 2023 16:36:47 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58456 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229956AbjAWVgp (ORCPT ); Mon, 23 Jan 2023 16:36:45 -0500 Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9092F16AD4 for ; Mon, 23 Jan 2023 13:36:44 -0800 (PST) Received: by mail-pj1-x102f.google.com with SMTP id o13so12952199pjg.2 for ; Mon, 23 Jan 2023 13:36:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paul-moore.com; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=yGXvyQjwLmOy53oIzm1ZLaTMK3/o09Vv8V+chgSLdeY=; b=CcWptSLeFIccOdIwrrQruiIQVbfQw+qTyjT3yv+7o4oiOdtJnaGwyxjNF8KqV8JCPb EtEuwCUakT7bXDWuTHstKBBxFfx/NFD6nI++Zxx33wEt2LsDHWWFbVo+nWs5aJpvgbDt bcNjHlr2/smIeZ2DgR6hyv29jjDSqQQI+8Qj+9AAlhetLTyxbKX75Vw/uzLti5pjdjDD 1gqqU5UtNkfvmUk9ZygMGK8+1jwTN9eFYCq597DzigUSvomN5c9XhKqAjmlcR+BL0bRb fkuAUTdTl6ZIMoENwrU3bfv6UbzvTXWAqgAlNJDWfnVuL4Hhf5bRgdVGoARAYxrNCCDe ljRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=yGXvyQjwLmOy53oIzm1ZLaTMK3/o09Vv8V+chgSLdeY=; b=owpT3StzkFHFe+6+ZmQ1ENXVdcHZNkiGo0kO4oxx/B0p3ceffAHx1AqGRllqGSzejB +0t50EeA4Si+yWIni014RoTUlCgxVby5nqIHbYkCvgueOwJxX3SWmIqRTgN/tCJe2Eku xR8ORy1NMM1wLeomgpcz93gKffUeIRRap0Rmpw5qN/C+tmyW3biO64OPRReOjLXFRcUE xuyUkvIqNKZ6EJPlphQQUh+9r9WJirGoam9vQTIIsw04gySWJLgTNyQyL11QL9wRZtwE l3LrF5xLHu4+pdsOwHC1aMwAmRIUNNO68GVDQwiPCFoZmr2X9k4C3rxvo/Or83BziU1h W5MA== X-Gm-Message-State: AFqh2kpA/hj6pilLI0p+EEMwU4liLfO8c1m0enhXX6UtJTdyhQhTcN7y 0i0Beq647Op7FViCeuh+U6Q8EUFeNRtBdEILa56n X-Google-Smtp-Source: AMrXdXsTqILQIvoKLSzn2vsOwuLpTkEPmSgexyL8bv143mvjcjNDhObnaFgjhL7UQHe0gGX5etBgH6e4mhBUZDn4fO0= X-Received: by 2002:a17:90a:c784:b0:227:202b:8eaa with SMTP id gn4-20020a17090ac78400b00227202b8eaamr2957806pjb.147.1674509804015; Mon, 23 Jan 2023 13:36:44 -0800 (PST) MIME-Version: 1.0 References: <20230123191728.2928839-1-tjmercier@google.com> <20230123191728.2928839-5-tjmercier@google.com> In-Reply-To: <20230123191728.2928839-5-tjmercier@google.com> From: Paul Moore Date: Mon, 23 Jan 2023 16:36:32 -0500 Message-ID: Subject: Re: [PATCH v2 4/4] security: binder: Add binder object flags to selinux_binder_transfer_file To: "T.J. Mercier" Cc: Greg Kroah-Hartman , =?UTF-8?B?QXJ2ZSBIasO4bm5ldsOlZw==?= , Todd Kjos , Martijn Coenen , Joel Fernandes , Christian Brauner , Carlos Llamas , Suren Baghdasaryan , James Morris , "Serge E. Hallyn" , Stephen Smalley , Eric Paris , 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 Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 23, 2023 at 2:18 PM T.J. Mercier 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 > --- > 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 > #include > #include /* for hashlen_string() */ > +#include > #include > #include > #include > @@ -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? -- paul-moore.com