On Thu, Nov 5, 2026 at 12:12 PM sashiko-bot@kernel.org wrote:
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] selinux: one-off dma_buf class instead of general cgroup access control model
--
commit 675e985fff50ea6716b8c00023a75c07ff345a6f Author: Albert Esteve aesteve@redhat.com
selinux: Restrict cross-cgroup dma-buf charging
This commit implements the selinux_dma_buf_charge_task() hook and adds a new dma_buf object class with a charge_task permission in SELinux to restrict cross-cgroup dma-buf memory charging.
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c index 30776b0107f29..8f39d91eabc97 100644 --- a/security/selinux/hooks.c +++ b/security/selinux/hooks.c @@ -2204,6 +2204,12 @@ static int selinux_capable(const struct cred *cred, struct user_namespace *ns, return cred_has_capability(cred, cap, opts, ns == &init_user_ns); }
+static int selinux_dma_buf_charge_task(const struct cred *from, const struct cred *to) +{
return avc_has_perm(cred_sid(from), cred_sid(to),SECCLASS_DMA_BUF, DMA_BUF__CHARGE_TASK, NULL);+}
static int selinux_quotactl(int cmds, int type, int id, const struct super_block *sb) { const struct cred *cred = current_cred();
[ ... ]
diff --git a/security/selinux/include/classmap.h b/security/selinux/include/classmap.h index 90cb61b164256..b4ebedc6e4240 100644 --- a/security/selinux/include/classmap.h +++ b/security/selinux/include/classmap.h @@ -181,6 +181,7 @@ const struct security_class_mapping secclass_map[] = { { "user_namespace", { "create", NULL } }, { "memfd_file", { COMMON_FILE_PERMS, "execute_no_trans", "entrypoint", NULL } },
{ "dma_buf", { "charge_task", NULL } },[Severity: Medium] As reported by Paul Moore on RFC [1], adding a one-off SELinux object class and permission for a specific subsystem's cgroup charging (previously dma_heap with charge_to, now dma_buf with charge_task in secclass_map[] and selinux_dma_buf_charge_task(), along with charge_cgroup in a later patch in this series) introduces a narrow, subsystem-specific policy class rather than a general cgroup and resource access control model for SELinux.
Although resolving the target memcg from charge_fd moved into generic memcontrol code in mem_cgroup_get_from_fd(), the SELinux hook in selinux_dma_buf_charge_task() and class definition in secclass_map[] still define a dma-buf-specific class instead of a broader cgroup access control abstraction.
Should this permission check be designed around a general cgroup or resource SELinux object class rather than a one-off dma_buf class?
[1] https://lore.kernel.org/r/16093a0278a6d7d1a0a8bc055c228bed@paul-moore.com
I held off on this so the core charging proposal could settle first, and then refine the LSM side later / in a separate series depending on the feedback.
For v5 I'm adding a capability baseline in mem_cgroup_get_from_fd() following a Sashiko report, so that charging a memcg outside the caller's own subtree requires CAP_SYS_RESOURCE. With that in place the LSM hooks no longer act as the only check, they add finer-grained policy on top of it. Also, unlike the RFC, they are now called from generic memcg code rather than dma-buf code, so I should have renamed them (and plan to) to security_memcg_charge_{task,cgroup}().
Regarding the broader cgroup model, as far as I can tell, existing cgroup control points are kernfs file operations, which SELinux already covers. The only non-file operations taking a cgroup fd (i.e., BPF attach and perf cgroup events) use their own subsystem classes. Since remote charging in this series consumes the target cgroup's resources, checking against the cgroup's label (as patch 7 already does) sounds like a good fit.
So to Sashiko remark and Paul's comment, rather than a dma-buf specific class, would something like a "cgroup" class with a "charge_to" permission for the cgroupfd path, and a process (process2 really) permission for the pidfd path, be an acceptable first step, with the class growing as other non-file control points come up? I'm happy to adjust the naming or structure to what works best.
BR, Albert
-- Sashiko AI review · https://sashiko.dev/#/patchset/20261104-v2_20230123_tjmercier_google_com-v4-...