linux-kernel - Re: [PATCH v3] memfd,selinux: call security_inode_init_security

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAHC9VhS2TU2GWgfUOHerbfjyxb5QZMSMqLdQirjSdkUohR7opg@mail.gmail.com>
Date: Mon, 22 Sep 2025 15:30:04 -0400
From: Paul Moore <paul@...l-moore.com>
To: Stephen Smalley <stephen.smalley.work@...il.com>
Cc: Thiébaud Weksteen <tweek@...gle.com>, 
	Hugh Dickins <hughd@...gle.com>, James Morris <jmorris@...ei.org>, 
	Jeff Vander Stoep <jeffv@...gle.com>, Nick Kralevich <nnk@...gle.com>, Jeff Xu <jeffxu@...gle.com>, 
	Baolin Wang <baolin.wang@...ux.alibaba.com>, Isaac Manjarres <isaacmanjarres@...gle.com>, 
	linux-kernel@...r.kernel.org, linux-security-module@...r.kernel.org, 
	selinux@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH v3] memfd,selinux: call security_inode_init_security_anon

On Mon, Sep 22, 2025 at 9:12 AM Stephen Smalley
<stephen.smalley.work@...il.com> wrote:
>
> When would you recommend that I re-apply the corresponding userspace
> patch to reserve this policy capability number for memfd_class?
> After it is moved to selinux/dev? Understand that it isn't truly
> reserved until it lands in a kernel.org kernel but would prefer to
> reapply it sooner than that since there may be other policy capability
> requests queueing up (e.g. bpf token) that should be done relative to
> it. Can always revert it again if necessary, at least until another
> userspace release is made (not sure on timeline for that).

When it comes to API issues like this, my standard answer is "tagged
release from Linus" as it is the safest option, but you know that
already.

The fuzzier answer is that unless something crazy happens, I'm likely
going to move the patches, in order, from selinux/dev-staging into
selinux/dev when the merge window closes.  This means that any
policycap API additions for the next cycle are going to start with the
memfd_class policycap, so it *should* be fairly safe to merge the
userspace bits now, I just wouldn't do a userspace release with that
API change until we see a tagged release from Linus.

-- 
paul-moore.com