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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAHC9VhTSRkP=jNw8bLRx5em6MnX9HTywBqXGsJCBPQ9MKJym=g@mail.gmail.com>
Date: Mon, 13 Oct 2025 12:11:26 -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 3:30 PM Paul Moore <paul@...l-moore.com> wrote:
> 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.

... and the patch is now in selinux/dev, thanks everyone!

-- 
paul-moore.com