selinux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paul Moore <paul@paul-moore.com>
To: Casey Schaufler <casey@schaufler-ca.com>,
	casey@schaufler-ca.com, eparis@redhat.com,
	linux-security-module@vger.kernel.org
Cc: jmorris@namei.org, serge@hallyn.com, keescook@chromium.org,
	john.johansen@canonical.com, penguin-kernel@i-love.sakura.ne.jp,
	stephen.smalley.work@gmail.com, linux-kernel@vger.kernel.org,
	selinux@vger.kernel.org
Subject: Re: [PATCH 2/3] LSM: allocate mnt_opts blobs instead of module  specific data
Date: Wed, 06 Aug 2025 18:06:13 -0400	[thread overview]
Message-ID: <f7e03785a79a0ac8f034cd38e263b84f@paul-moore.com> (raw)
In-Reply-To: <20250617210105.17479-3-casey@schaufler-ca.com>

On Jun 17, 2025 Casey Schaufler <casey@schaufler-ca.com> wrote:
> 
> Replace allocations of LSM specific mount data with the
> shared mnt_opts blob.
> 
> Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
> ---
>  include/linux/lsm_hooks.h  |  1 +
>  security/security.c        | 12 ++++++++++++
>  security/selinux/hooks.c   | 10 +++++++---
>  security/smack/smack_lsm.c |  4 ++--
>  4 files changed, 22 insertions(+), 5 deletions(-)

...

> diff --git a/security/security.c b/security/security.c
> index 8a4e0f70e49d..ec61fb7e6492 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -904,6 +904,18 @@ void security_sb_free(struct super_block *sb)
>  	sb->s_security = NULL;
>  }
>  
> +/**
> + * lsm_mnt_opts_alloc - allocate a mnt_opts blob
> + * @priority: memory allocation priority
> + *
> + * Returns a newly allocated mnt_opts blob or NULL if
> + * memory isn't available.
> + */
> +void *lsm_mnt_opts_alloc(gfp_t priority)
> +{
> +	return kzalloc(blob_sizes.lbs_mnt_opts, priority);
> +}

It's probably better to use lsm_blob_alloc() here so we have some
allocator consistency.

Also, make this private/static as we should just handle the blob
allocation in the LSM framework (see below) just like everything else,
unless you can explain why the mount options need to be handled
differently?

>  /**
>   * security_free_mnt_opts() - Free memory associated with mount options
>   * @mnt_opts: LSM processed mount options
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 88cd1d56081a..f7eda0cce68f 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -2808,7 +2808,7 @@ static int selinux_fs_context_submount(struct fs_context *fc,
>  	if (!(sbsec->flags & (FSCONTEXT_MNT|CONTEXT_MNT|DEFCONTEXT_MNT)))
>  		return 0;
>  
> -	opts = kzalloc(sizeof(*opts), GFP_KERNEL);
> +	opts = lsm_mnt_opts_alloc(GFP_KERNEL);

See above.

>  	if (!opts)
>  		return -ENOMEM;
>  
> @@ -2830,8 +2830,12 @@ static int selinux_fs_context_dup(struct fs_context *fc,
>  	if (!src)
>  		return 0;
>  
> -	fc->security = kmemdup(src, sizeof(*src), GFP_KERNEL);
> -	return fc->security ? 0 : -ENOMEM;
> +	fc->security = lsm_mnt_opts_alloc(GFP_KERNEL);
> +	if (!fc->security)
> +		return -ENOMEM;

Another case where we should do the allocation in the LSM framework.

> +	memcpy(fc->security, src, sizeof(*src));
> +	return 0;
>  }
>  
>  static const struct fs_parameter_spec selinux_fs_parameters[] = {
> diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
> index 44bd92410425..1d456df40096 100644
> --- a/security/smack/smack_lsm.c
> +++ b/security/smack/smack_lsm.c
> @@ -622,7 +622,7 @@ static int smack_fs_context_submount(struct fs_context *fc,
>  	struct smack_mnt_opts *ctx;
>  	struct inode_smack *isp;
>  
> -	ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
> +	ctx = lsm_mnt_opts_alloc(GFP_KERNEL);
>  	if (!ctx)
>  		return -ENOMEM;
>  	fc->security = ctx;
> @@ -673,7 +673,7 @@ static int smack_fs_context_dup(struct fs_context *fc,
>  	if (!src)
>  		return 0;
>  
> -	fc->security = kzalloc(sizeof(struct smack_mnt_opts), GFP_KERNEL);
> +	fc->security = lsm_mnt_opts_alloc(GFP_KERNEL);
>  	if (!fc->security)
>  		return -ENOMEM;

Same thing in Smack.

--
paul-moore.com

  reply	other threads:[~2025-08-06 22:06 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20250617210105.17479-1-casey.ref@schaufler-ca.com>
2025-06-17 21:01 ` [PATCH 0/3] LSM: Multiple LSM mount options Casey Schaufler
2025-06-17 21:01   ` [PATCH 1/3] LSM: Add mount opts blob size tracking Casey Schaufler
2025-08-06 22:06     ` Paul Moore
2025-06-17 21:01   ` [PATCH 2/3] LSM: allocate mnt_opts blobs instead of module specific data Casey Schaufler
2025-08-06 22:06     ` Paul Moore [this message]
2025-08-06 23:16       ` Casey Schaufler
2025-08-07  0:40         ` Paul Moore
2025-06-17 21:01   ` [PATCH 3/3] LSM: Infrastructure management of the mnt_opts security blob Casey Schaufler

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=f7e03785a79a0ac8f034cd38e263b84f@paul-moore.com \
    --to=paul@paul-moore.com \
    --cc=casey@schaufler-ca.com \
    --cc=eparis@redhat.com \
    --cc=jmorris@namei.org \
    --cc=john.johansen@canonical.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=penguin-kernel@i-love.sakura.ne.jp \
    --cc=selinux@vger.kernel.org \
    --cc=serge@hallyn.com \
    --cc=stephen.smalley.work@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).