linux-security-module.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paul Moore <paul@paul-moore.com>
To: Olga Kornievskaia <olga.kornievskaia@gmail.com>
Cc: trond.myklebust@hammerspace.com, anna.schumaker@netapp.com,
	linux-nfs@vger.kernel.org, linux-security-module@vger.kernel.org,
	selinux@vger.kernel.org
Subject: Re: [PATCH v3 1/3] [security] Add new hook to compare new mount to an existing mount
Date: Thu, 25 Feb 2021 12:53:35 -0500	[thread overview]
Message-ID: <CAHC9VhRKLBNNfUE0FMgGJBR5eBQ+Et=oK1rcErUU_i62AGhfsQ@mail.gmail.com> (raw)
In-Reply-To: <20210219222233.20748-1-olga.kornievskaia@gmail.com>

On Fri, Feb 19, 2021 at 5:25 PM Olga Kornievskaia
<olga.kornievskaia@gmail.com> wrote:
>
> From: Olga Kornievskaia <kolga@netapp.com>
>
> Add a new hook that takes an existing super block and a new mount
> with new options and determines if new options confict with an
> existing mount or not.
>
> A filesystem can use this new hook to determine if it can share
> the an existing superblock with a new superblock for the new mount.
>
> Signed-off-by: Olga Kornievskaia <kolga@netapp.com>
> ---
>  include/linux/lsm_hook_defs.h |  1 +
>  include/linux/lsm_hooks.h     |  6 ++++
>  include/linux/security.h      |  8 +++++
>  security/security.c           |  7 +++++
>  security/selinux/hooks.c      | 56 +++++++++++++++++++++++++++++++++++
>  5 files changed, 78 insertions(+)

...

> diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
> index a19adef1f088..d76aaecfdf0f 100644
> --- a/include/linux/lsm_hooks.h
> +++ b/include/linux/lsm_hooks.h
> @@ -142,6 +142,12 @@
>   *     @orig the original mount data copied from userspace.
>   *     @copy copied data which will be passed to the security module.
>   *     Returns 0 if the copy was successful.
> + * @sb_mnt_opts_compat:
> + *     Determine if the existing mount options are compatible with the new
> + *     mount options being used.

Full disclosure: I'm a big fan of good documentation, regardless of if
it lives in comments or a separate dedicated resource.  Looking at the
comment above, and the SELinux implementation of this hook below, it
appears that the comment is a bit vague; specifically the use of
"compatible".  Based on the SELinux implementation, "compatible" would
seem to equal, do you envision that to be the case for every
LSM/security-model?  If the answer is yes, then let's say that (and
possibly rename the hook to "sb_mnt_opts_equal").  If the answer is
no, then I think we need to do a better job explaining what
compatibility really means; put yourself in the shoes of someone
writing a LSM, what would they need to know to write an implementation
for this hook?

> + *     @sb superblock being compared
> + *     @mnt_opts new mount options
> + *     Return 0 if options are compatible.

-- 
paul moore
www.paul-moore.com

  parent reply	other threads:[~2021-02-25 17:55 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-19 22:22 [PATCH v3 1/3] [security] Add new hook to compare new mount to an existing mount Olga Kornievskaia
2021-02-19 22:22 ` [PATCH v3 2/3] [NFS] cleanup: remove unneeded null check in nfs_fill_super() Olga Kornievskaia
2021-03-22 19:00   ` Paul Moore
2021-02-19 22:22 ` [PATCH v3 3/3] NFSv4 account for selinux security context when deciding to share superblock Olga Kornievskaia
2021-03-22 19:04   ` Paul Moore
2021-02-25 17:53 ` Paul Moore [this message]
2021-02-25 18:03   ` [PATCH v3 1/3] [security] Add new hook to compare new mount to an existing mount Olga Kornievskaia
2021-02-25 18:22     ` Casey Schaufler
2021-02-25 19:30     ` Paul Moore
2021-02-27  3:37     ` [PATCH v4 " Olga Kornievskaia
2021-03-02 18:20       ` Anna Schumaker
2021-03-02 18:51         ` Casey Schaufler
2021-03-05  1:32           ` Paul Moore
2021-03-12 15:45             ` Anna Schumaker
2021-03-12 21:54               ` Paul Moore
2021-03-12 22:34                 ` Olga Kornievskaia
2021-03-15  1:43                   ` Paul Moore
2021-03-15 15:30                     ` Olga Kornievskaia
2021-03-15 16:15                       ` Paul Moore
2021-03-18 19:12                         ` Paul Moore
2021-03-18 19:21                           ` Casey Schaufler
2021-03-18 22:49                           ` James Morris
2021-03-18 22:59                             ` Olga Kornievskaia
2021-03-22 18:56                           ` Paul Moore

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='CAHC9VhRKLBNNfUE0FMgGJBR5eBQ+Et=oK1rcErUU_i62AGhfsQ@mail.gmail.com' \
    --to=paul@paul-moore.com \
    --cc=anna.schumaker@netapp.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=olga.kornievskaia@gmail.com \
    --cc=selinux@vger.kernel.org \
    --cc=trond.myklebust@hammerspace.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).