From: Casey Schaufler <casey@schaufler-ca.com>
To: Olga Kornievskaia <olga.kornievskaia@gmail.com>,
Paul Moore <paul@paul-moore.com>
Cc: Trond Myklebust <trond.myklebust@hammerspace.com>,
Anna Schumaker <anna.schumaker@netapp.com>,
linux-nfs <linux-nfs@vger.kernel.org>,
Linux Security Module list
<linux-security-module@vger.kernel.org>,
SElinux list <selinux@vger.kernel.org>,
Casey Schaufler <casey@schaufler-ca.com>
Subject: Re: [PATCH v3 1/3] [security] Add new hook to compare new mount to an existing mount
Date: Thu, 25 Feb 2021 10:22:58 -0800 [thread overview]
Message-ID: <e6d315d6-ee07-bde3-8d87-acff38d43b53@schaufler-ca.com> (raw)
In-Reply-To: <CAN-5tyGuV-gs0KzVbKSj42ZMx553zy9wOfVb1SoHoE-WCoN1_w@mail.gmail.com>
On 2/25/2021 10:03 AM, Olga Kornievskaia wrote:
> On Thu, Feb 25, 2021 at 12:53 PM Paul Moore <paul@paul-moore.com> wrote:
>> 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?
The original implementation did use sb_mnt_opts_equal(). The
change to "compatible" was my suggestion. Smack has multiple
mount options, and while I haven't actually delved into how
you would have compatible but different mount options, I
think it's possible. That's why I think that "equal" isn't
a good name for the function.
>> 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?
> That's is tough to do as it is vague. All I was doing was fixing a
> bug. Selinux didn't allow a new mount because it had a different
> security context. What that translates to for the new hook, is up to
> the LSM module whether it would need the options to be exactly the
> same or if they can be slightly different but yet compatible this is
> really up to the LSM.
>
> Do you care to suggest wording to use? It is hard to find words that
> somebody else is looking for but one is unable to provide them.
>
>>> + * @sb superblock being compared
>>> + * @mnt_opts new mount options
>>> + * Return 0 if options are compatible.
>> --
>> paul moore
>> www.paul-moore.com
next prev parent reply other threads:[~2021-02-25 18:24 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 ` [PATCH v3 1/3] [security] Add new hook to compare new mount to an existing mount Paul Moore
2021-02-25 18:03 ` Olga Kornievskaia
2021-02-25 18:22 ` Casey Schaufler [this message]
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=e6d315d6-ee07-bde3-8d87-acff38d43b53@schaufler-ca.com \
--to=casey@schaufler-ca.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=paul@paul-moore.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).