All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Rapoport <rppt@kernel.org>
To: Paul Moore <paul@paul-moore.com>
Cc: Ackerley Tng <ackerleytng@google.com>,
	linux-security-module@vger.kernel.org, selinux@vger.kernel.org,
	kvm@vger.kernel.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, x86@kernel.org,
	linux-fsdevel@vger.kernel.org, aik@amd.com,
	ajones@ventanamicro.com, akpm@linux-foundation.org,
	amoorthy@google.com, anthony.yznaga@oracle.com,
	anup@brainfault.org, aou@eecs.berkeley.edu, bfoster@redhat.com,
	binbin.wu@linux.intel.com, brauner@kernel.org,
	catalin.marinas@arm.com, chao.p.peng@intel.com,
	chenhuacai@kernel.org, dave.hansen@intel.com, david@redhat.com,
	dmatlack@google.com, dwmw@amazon.co.uk, erdemaktas@google.com,
	fan.du@intel.com, fvdl@google.com, graf@amazon.com,
	haibo1.xu@intel.com, hch@infradead.org, hughd@google.com,
	ira.weiny@intel.com, isaku.yamahata@intel.com, jack@suse.cz,
	james.morse@arm.com, jarkko@kernel.org, jgg@ziepe.ca,
	jgowans@amazon.com, jhubbard@nvidia.com, jroedel@suse.de,
	jthoughton@google.com, jun.miao@intel.com, kai.huang@intel.com,
	keirf@google.com, kent.overstreet@linux.dev,
	kirill.shutemov@intel.com, liam.merwick@oracle.com,
	maciej.wieczor-retman@intel.com, mail@maciej.szmigiero.name,
	maz@kernel.org, mic@digikod.net, michael.roth@amd.com,
	mpe@ellerman.id.au, muchun.song@linux.dev, nikunj@amd.com,
	nsaenz@amazon.es, oliver.upton@linux.dev, palmer@dabbelt.com,
	pankaj.gupta@amd.com, paul.walmsley@sifive.com,
	pbonzini@redhat.com, pdurrant@amazon.co.uk, peterx@redhat.com,
	pgonda@google.com, pvorel@suse.cz, qperret@google.com,
	quic_cvanscha@quicinc.com, quic_eberman@quicinc.com,
	quic_mnalajal@quicinc.com, quic_pderrin@quicinc.com,
	quic_pheragu@quicinc.com, quic_svaddagi@quicinc.com,
	quic_tsoni@quicinc.com, richard.weiyang@gmail.com,
	rick.p.edgecombe@intel.com, rientjes@google.com,
	roypat@amazon.co.uk, seanjc@google.com, shuah@kernel.org,
	steven.price@arm.com, steven.sistare@oracle.com,
	suzuki.poulose@arm.com, tabba@google.com,
	thomas.lendacky@amd.com, vannapurve@google.com, vbabka@suse.cz,
	viro@zeniv.linux.org.uk, vkuznets@redhat.com,
	wei.w.wang@intel.com, will@kernel.org, willy@infradead.org,
	xiaoyao.li@intel.com, yan.y.zhao@intel.com, yilun.xu@intel.com,
	yuzenghui@huawei.com, zhiquan1.li@intel.com
Subject: Re: [PATCH 1/2] fs: Provide function that allocates a secure anonymous inode
Date: Thu, 5 Jun 2025 08:49:44 +0300	[thread overview]
Message-ID: <aEEv-A1ot_t8ePgv@kernel.org> (raw)
In-Reply-To: <CAHC9VhQczhrVx4YEGbXbAS8FLi0jaV1RB0kb8e4rPsUOXYLqtA@mail.gmail.com>

On Wed, Jun 04, 2025 at 05:13:35PM -0400, Paul Moore wrote:
> On Wed, Jun 4, 2025 at 3:59 AM Mike Rapoport <rppt@kernel.org> wrote:
> >
> > (added Paul Moore for selinux bits)
> 
> Thanks Mike.
> 
> I'm adding the LSM and SELinux lists too since there are others that
> will be interested as well.
> 
> > On Mon, Jun 02, 2025 at 12:17:54PM -0700, Ackerley Tng wrote:
> > > The new function, alloc_anon_secure_inode(), returns an inode after
> > > running checks in security_inode_init_security_anon().
> > >
> > > Also refactor secretmem's file creation process to use the new
> > > function.
> > >
> > > Suggested-by: David Hildenbrand <david@redhat.com>
> > > Signed-off-by: Ackerley Tng <ackerleytng@google.com>
> > > ---
> > >  fs/anon_inodes.c   | 22 ++++++++++++++++------
> > >  include/linux/fs.h |  1 +
> > >  mm/secretmem.c     |  9 +--------
> > >  3 files changed, 18 insertions(+), 14 deletions(-)
> > >
> > > diff --git a/fs/anon_inodes.c b/fs/anon_inodes.c
> > > index 583ac81669c2..4c3110378647 100644
> > > --- a/fs/anon_inodes.c
> > > +++ b/fs/anon_inodes.c
> > > @@ -55,17 +55,20 @@ static struct file_system_type anon_inode_fs_type = {
> > >       .kill_sb        = kill_anon_super,
> > >  };
> > >
> > > -static struct inode *anon_inode_make_secure_inode(
> > > -     const char *name,
> > > -     const struct inode *context_inode)
> > > +static struct inode *anon_inode_make_secure_inode(struct super_block *s,
> > > +             const char *name, const struct inode *context_inode,
> > > +             bool fs_internal)
> > >  {
> > >       struct inode *inode;
> > >       int error;
> > >
> > > -     inode = alloc_anon_inode(anon_inode_mnt->mnt_sb);
> > > +     inode = alloc_anon_inode(s);
> > >       if (IS_ERR(inode))
> > >               return inode;
> > > -     inode->i_flags &= ~S_PRIVATE;
> > > +
> > > +     if (!fs_internal)
> > > +             inode->i_flags &= ~S_PRIVATE;
> > > +
> > >       error = security_inode_init_security_anon(inode, &QSTR(name),
> > >                                                 context_inode);
> > >       if (error) {
> > > @@ -75,6 +78,12 @@ static struct inode *anon_inode_make_secure_inode(
> > >       return inode;
> > >  }
> > >
> > > +struct inode *alloc_anon_secure_inode(struct super_block *s, const char *name)
> > > +{
> > > +     return anon_inode_make_secure_inode(s, name, NULL, true);
> > > +}
> > > +EXPORT_SYMBOL_GPL(alloc_anon_secure_inode);
> > > +
> > >  static struct file *__anon_inode_getfile(const char *name,
> > >                                        const struct file_operations *fops,
> > >                                        void *priv, int flags,
> > > @@ -88,7 +97,8 @@ static struct file *__anon_inode_getfile(const char *name,
> > >               return ERR_PTR(-ENOENT);
> > >
> > >       if (make_inode) {
> > > -             inode = anon_inode_make_secure_inode(name, context_inode);
> > > +             inode = anon_inode_make_secure_inode(anon_inode_mnt->mnt_sb,
> > > +                                                  name, context_inode, false);
> > >               if (IS_ERR(inode)) {
> > >                       file = ERR_CAST(inode);
> > >                       goto err;
> > > diff --git a/include/linux/fs.h b/include/linux/fs.h
> > > index 016b0fe1536e..0fded2e3c661 100644
> > > --- a/include/linux/fs.h
> > > +++ b/include/linux/fs.h
> > > @@ -3550,6 +3550,7 @@ extern int simple_write_begin(struct file *file, struct address_space *mapping,
> > >  extern const struct address_space_operations ram_aops;
> > >  extern int always_delete_dentry(const struct dentry *);
> > >  extern struct inode *alloc_anon_inode(struct super_block *);
> > > +extern struct inode *alloc_anon_secure_inode(struct super_block *, const char *);
> > >  extern int simple_nosetlease(struct file *, int, struct file_lease **, void **);
> > >  extern const struct dentry_operations simple_dentry_operations;
> > >
> > > diff --git a/mm/secretmem.c b/mm/secretmem.c
> > > index 1b0a214ee558..c0e459e58cb6 100644
> > > --- a/mm/secretmem.c
> > > +++ b/mm/secretmem.c
> > > @@ -195,18 +195,11 @@ static struct file *secretmem_file_create(unsigned long flags)
> > >       struct file *file;
> > >       struct inode *inode;
> > >       const char *anon_name = "[secretmem]";
> > > -     int err;
> > >
> > > -     inode = alloc_anon_inode(secretmem_mnt->mnt_sb);
> > > +     inode = alloc_anon_secure_inode(secretmem_mnt->mnt_sb, anon_name);
> > >       if (IS_ERR(inode))
> > >               return ERR_CAST(inode);
> >
> > I don't think we should not hide secretmem and guest_memfd inodes from
> > selinux, so clearing S_PRIVATE for them is not needed and you can just drop
> > fs_internal parameter in anon_inode_make_secure_inode()
> 
> It's especially odd since I don't see any comments or descriptions
> about why this is being done.  The secretmem change is concerning as
> this is user accessible and marking the inode with S_PRIVATE will
> bypass a number of LSM/SELinux access controls, possibly resulting in
> a security regression (one would need to dig a bit deeper to see what
> is possible with secretmem and which LSM/SELinux code paths would be
> affected).

secretmem always had S_PRIVATE set because alloc_anon_inode() clears it
anyway and this patch does not change it.
I'm just thinking that it makes sense to actually allow LSM/SELinux
controls that S_PRIVATE bypasses for both secretmem and guest_memfd.
 
-- 
Sincerely yours,
Mike.

  reply	other threads:[~2025-06-05  5:50 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-02 19:17 [PATCH 0/2] Use guest mem inodes instead of anonymous inodes Ackerley Tng
2025-06-02 19:17 ` [PATCH 1/2] fs: Provide function that allocates a secure anonymous inode Ackerley Tng
2025-06-02 20:02   ` David Hildenbrand
2025-06-03  4:52   ` Christoph Hellwig
2025-06-03 10:40     ` Shivank Garg
2025-06-04  7:59   ` Mike Rapoport
2025-06-04 21:13     ` Paul Moore
2025-06-05  5:49       ` Mike Rapoport [this message]
2025-06-05 18:23         ` Paul Moore
2025-06-06 15:09           ` Ira Weiny
2025-06-16 13:00             ` Shivank Garg
2025-06-19  5:36               ` Mike Rapoport
2025-06-04  8:02   ` Christian Brauner
2025-06-02 19:17 ` [PATCH 2/2] KVM: guest_memfd: Use guest mem inodes instead of anonymous inodes Ackerley Tng
2025-06-02 20:13   ` David Hildenbrand

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=aEEv-A1ot_t8ePgv@kernel.org \
    --to=rppt@kernel.org \
    --cc=ackerleytng@google.com \
    --cc=aik@amd.com \
    --cc=ajones@ventanamicro.com \
    --cc=akpm@linux-foundation.org \
    --cc=amoorthy@google.com \
    --cc=anthony.yznaga@oracle.com \
    --cc=anup@brainfault.org \
    --cc=aou@eecs.berkeley.edu \
    --cc=bfoster@redhat.com \
    --cc=binbin.wu@linux.intel.com \
    --cc=brauner@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=chao.p.peng@intel.com \
    --cc=chenhuacai@kernel.org \
    --cc=dave.hansen@intel.com \
    --cc=david@redhat.com \
    --cc=dmatlack@google.com \
    --cc=dwmw@amazon.co.uk \
    --cc=erdemaktas@google.com \
    --cc=fan.du@intel.com \
    --cc=fvdl@google.com \
    --cc=graf@amazon.com \
    --cc=haibo1.xu@intel.com \
    --cc=hch@infradead.org \
    --cc=hughd@google.com \
    --cc=ira.weiny@intel.com \
    --cc=isaku.yamahata@intel.com \
    --cc=jack@suse.cz \
    --cc=james.morse@arm.com \
    --cc=jarkko@kernel.org \
    --cc=jgg@ziepe.ca \
    --cc=jgowans@amazon.com \
    --cc=jhubbard@nvidia.com \
    --cc=jroedel@suse.de \
    --cc=jthoughton@google.com \
    --cc=jun.miao@intel.com \
    --cc=kai.huang@intel.com \
    --cc=keirf@google.com \
    --cc=kent.overstreet@linux.dev \
    --cc=kirill.shutemov@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=liam.merwick@oracle.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=maciej.wieczor-retman@intel.com \
    --cc=mail@maciej.szmigiero.name \
    --cc=maz@kernel.org \
    --cc=mic@digikod.net \
    --cc=michael.roth@amd.com \
    --cc=mpe@ellerman.id.au \
    --cc=muchun.song@linux.dev \
    --cc=nikunj@amd.com \
    --cc=nsaenz@amazon.es \
    --cc=oliver.upton@linux.dev \
    --cc=palmer@dabbelt.com \
    --cc=pankaj.gupta@amd.com \
    --cc=paul.walmsley@sifive.com \
    --cc=paul@paul-moore.com \
    --cc=pbonzini@redhat.com \
    --cc=pdurrant@amazon.co.uk \
    --cc=peterx@redhat.com \
    --cc=pgonda@google.com \
    --cc=pvorel@suse.cz \
    --cc=qperret@google.com \
    --cc=quic_cvanscha@quicinc.com \
    --cc=quic_eberman@quicinc.com \
    --cc=quic_mnalajal@quicinc.com \
    --cc=quic_pderrin@quicinc.com \
    --cc=quic_pheragu@quicinc.com \
    --cc=quic_svaddagi@quicinc.com \
    --cc=quic_tsoni@quicinc.com \
    --cc=richard.weiyang@gmail.com \
    --cc=rick.p.edgecombe@intel.com \
    --cc=rientjes@google.com \
    --cc=roypat@amazon.co.uk \
    --cc=seanjc@google.com \
    --cc=selinux@vger.kernel.org \
    --cc=shuah@kernel.org \
    --cc=steven.price@arm.com \
    --cc=steven.sistare@oracle.com \
    --cc=suzuki.poulose@arm.com \
    --cc=tabba@google.com \
    --cc=thomas.lendacky@amd.com \
    --cc=vannapurve@google.com \
    --cc=vbabka@suse.cz \
    --cc=viro@zeniv.linux.org.uk \
    --cc=vkuznets@redhat.com \
    --cc=wei.w.wang@intel.com \
    --cc=will@kernel.org \
    --cc=willy@infradead.org \
    --cc=x86@kernel.org \
    --cc=xiaoyao.li@intel.com \
    --cc=yan.y.zhao@intel.com \
    --cc=yilun.xu@intel.com \
    --cc=yuzenghui@huawei.com \
    --cc=zhiquan1.li@intel.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: link
Be 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.