* [PATCH v3 1/3] [security] Add new hook to compare new mount to an existing mount @ 2021-02-19 22:22 Olga Kornievskaia 2021-02-19 22:22 ` [PATCH v3 2/3] [NFS] cleanup: remove unneeded null check in nfs_fill_super() Olga Kornievskaia ` (2 more replies) 0 siblings, 3 replies; 24+ messages in thread From: Olga Kornievskaia @ 2021-02-19 22:22 UTC (permalink / raw) To: trond.myklebust, anna.schumaker; +Cc: linux-nfs, linux-security-module, selinux 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_hook_defs.h b/include/linux/lsm_hook_defs.h index 7aaa753b8608..1b12a5266a51 100644 --- a/include/linux/lsm_hook_defs.h +++ b/include/linux/lsm_hook_defs.h @@ -62,6 +62,7 @@ LSM_HOOK(int, 0, sb_alloc_security, struct super_block *sb) LSM_HOOK(void, LSM_RET_VOID, sb_free_security, struct super_block *sb) LSM_HOOK(void, LSM_RET_VOID, sb_free_mnt_opts, void *mnt_opts) LSM_HOOK(int, 0, sb_eat_lsm_opts, char *orig, void **mnt_opts) +LSM_HOOK(int, 0, sb_mnt_opts_compat, struct super_block *sb, void *mnt_opts) LSM_HOOK(int, 0, sb_remount, struct super_block *sb, void *mnt_opts) LSM_HOOK(int, 0, sb_kern_mount, struct super_block *sb) LSM_HOOK(int, 0, sb_show_options, struct seq_file *m, struct super_block *sb) 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. + * @sb superblock being compared + * @mnt_opts new mount options + * Return 0 if options are compatible. * @sb_remount: * Extracts security system specific mount options and verifies no changes * are being made to those options. diff --git a/include/linux/security.h b/include/linux/security.h index c35ea0ffccd9..50db3d5d1608 100644 --- a/include/linux/security.h +++ b/include/linux/security.h @@ -291,6 +291,7 @@ int security_sb_alloc(struct super_block *sb); void security_sb_free(struct super_block *sb); void security_free_mnt_opts(void **mnt_opts); int security_sb_eat_lsm_opts(char *options, void **mnt_opts); +int security_sb_mnt_opts_compat(struct super_block *sb, void *mnt_opts); int security_sb_remount(struct super_block *sb, void *mnt_opts); int security_sb_kern_mount(struct super_block *sb); int security_sb_show_options(struct seq_file *m, struct super_block *sb); @@ -635,6 +636,13 @@ static inline int security_sb_remount(struct super_block *sb, return 0; } +static inline int security_sb_mnt_opts_compat(struct super_block *sb, + void *mnt_opts) +{ + return 0; +} + + static inline int security_sb_kern_mount(struct super_block *sb) { return 0; diff --git a/security/security.c b/security/security.c index 7b09cfbae94f..56cf5563efde 100644 --- a/security/security.c +++ b/security/security.c @@ -890,6 +890,13 @@ int security_sb_eat_lsm_opts(char *options, void **mnt_opts) } EXPORT_SYMBOL(security_sb_eat_lsm_opts); +int security_sb_mnt_opts_compat(struct super_block *sb, + void *mnt_opts) +{ + return call_int_hook(sb_mnt_opts_compat, 0, sb, mnt_opts); +} +EXPORT_SYMBOL(security_sb_mnt_opts_compat); + int security_sb_remount(struct super_block *sb, void *mnt_opts) { diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c index 644b17ec9e63..afee3a222a0e 100644 --- a/security/selinux/hooks.c +++ b/security/selinux/hooks.c @@ -2656,6 +2656,61 @@ static int selinux_sb_eat_lsm_opts(char *options, void **mnt_opts) return rc; } +static int selinux_sb_mnt_opts_compat(struct super_block *sb, void *mnt_opts) +{ + struct selinux_mnt_opts *opts = mnt_opts; + struct superblock_security_struct *sbsec = sb->s_security; + u32 sid; + int rc; + + /* + * Superblock not initialized (i.e. no options) - reject if any + * options specified, otherwise accept. + */ + if (!(sbsec->flags & SE_SBINITIALIZED)) + return opts ? 1 : 0; + + /* + * Superblock initialized and no options specified - reject if + * superblock has any options set, otherwise accept. + */ + if (!opts) + return (sbsec->flags & SE_MNTMASK) ? 1 : 0; + + if (opts->fscontext) { + rc = parse_sid(sb, opts->fscontext, &sid); + if (rc) + return 1; + if (bad_option(sbsec, FSCONTEXT_MNT, sbsec->sid, sid)) + return 1; + } + if (opts->context) { + rc = parse_sid(sb, opts->context, &sid); + if (rc) + return 1; + if (bad_option(sbsec, CONTEXT_MNT, sbsec->mntpoint_sid, sid)) + return 1; + } + if (opts->rootcontext) { + struct inode_security_struct *root_isec; + + root_isec = backing_inode_security(sb->s_root); + rc = parse_sid(sb, opts->rootcontext, &sid); + if (rc) + return 1; + if (bad_option(sbsec, ROOTCONTEXT_MNT, root_isec->sid, sid)) + return 1; + } + if (opts->defcontext) { + rc = parse_sid(sb, opts->defcontext, &sid); + if (rc) + return 1; + if (bad_option(sbsec, DEFCONTEXT_MNT, sbsec->def_sid, sid)) + return 1; + } + return 0; +} + static int selinux_sb_remount(struct super_block *sb, void *mnt_opts) { struct selinux_mnt_opts *opts = mnt_opts; @@ -6984,6 +7039,7 @@ static struct security_hook_list selinux_hooks[] __lsm_ro_after_init = { LSM_HOOK_INIT(sb_free_security, selinux_sb_free_security), LSM_HOOK_INIT(sb_free_mnt_opts, selinux_free_mnt_opts), + LSM_HOOK_INIT(sb_mnt_opts_compat, selinux_sb_mnt_opts_compat), LSM_HOOK_INIT(sb_remount, selinux_sb_remount), LSM_HOOK_INIT(sb_kern_mount, selinux_sb_kern_mount), LSM_HOOK_INIT(sb_show_options, selinux_sb_show_options), -- 2.27.0 ^ permalink raw reply related [flat|nested] 24+ messages in thread
* [PATCH v3 2/3] [NFS] cleanup: remove unneeded null check in nfs_fill_super() 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 ` 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-02-25 17:53 ` [PATCH v3 1/3] [security] Add new hook to compare new mount to an existing mount Paul Moore 2 siblings, 1 reply; 24+ messages in thread From: Olga Kornievskaia @ 2021-02-19 22:22 UTC (permalink / raw) To: trond.myklebust, anna.schumaker; +Cc: linux-nfs, linux-security-module, selinux From: Olga Kornievskaia <kolga@netapp.com> In nfs_fill_super() passed in nfs_fs_context can never be NULL. Signed-off-by: Olga Kornievskaia <kolga@netapp.com> --- fs/nfs/super.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/nfs/super.c b/fs/nfs/super.c index 4034102010f0..59d846d7830f 100644 --- a/fs/nfs/super.c +++ b/fs/nfs/super.c @@ -1026,7 +1026,7 @@ static void nfs_fill_super(struct super_block *sb, struct nfs_fs_context *ctx) sb->s_blocksize = 0; sb->s_xattr = server->nfs_client->cl_nfs_mod->xattr; sb->s_op = server->nfs_client->cl_nfs_mod->sops; - if (ctx && ctx->bsize) + if (ctx->bsize) sb->s_blocksize = nfs_block_size(ctx->bsize, &sb->s_blocksize_bits); if (server->nfs_client->rpc_ops->version != 2) { -- 2.27.0 ^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: [PATCH v3 2/3] [NFS] cleanup: remove unneeded null check in nfs_fill_super() 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 0 siblings, 0 replies; 24+ messages in thread From: Paul Moore @ 2021-03-22 19:00 UTC (permalink / raw) To: Olga Kornievskaia Cc: trond.myklebust, anna.schumaker, linux-nfs, linux-security-module, selinux On Fri, Feb 19, 2021 at 5:24 PM Olga Kornievskaia <olga.kornievskaia@gmail.com> wrote: > > From: Olga Kornievskaia <kolga@netapp.com> > > In nfs_fill_super() passed in nfs_fs_context can never be NULL. > > Signed-off-by: Olga Kornievskaia <kolga@netapp.com> > --- > fs/nfs/super.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Merged into selinux/next, thanks. -- paul moore www.paul-moore.com ^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH v3 3/3] NFSv4 account for selinux security context when deciding to share superblock 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-02-19 22:22 ` 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 2 siblings, 1 reply; 24+ messages in thread From: Olga Kornievskaia @ 2021-02-19 22:22 UTC (permalink / raw) To: trond.myklebust, anna.schumaker; +Cc: linux-nfs, linux-security-module, selinux From: Olga Kornievskaia <kolga@netapp.com> Keep track of whether or not there were LSM security context options passed during mount (ie creation of the superblock). Then, while deciding if the superblock can be shared for the new mount, check if the newly passed in LSM security context options are compatible with the existing superblock's ones by calling security_sb_mnt_opts_compat(). Previously, with selinux enabled, NFS wasn't able to do the following 2mounts: mount -o vers=4.2,sec=sys,context=system_u:object_r:root_t:s0 <serverip>:/ /mnt mount -o vers=4.2,sec=sys,context=system_u:object_r:swapfile_t:s0 <serverip>:/scratch /scratch 2nd mount would fail with "mount.nfs: an incorrect mount option was specified" and var log messages would have: "SElinux: mount invalid. Same superblock, different security settings for.." Signed-off-by: Olga Kornievskaia <kolga@netapp.com> --- fs/nfs/fs_context.c | 3 +++ fs/nfs/internal.h | 1 + fs/nfs/super.c | 4 ++++ include/linux/nfs_fs_sb.h | 1 + 4 files changed, 9 insertions(+) diff --git a/fs/nfs/fs_context.c b/fs/nfs/fs_context.c index 06894bcdea2d..8067f055d842 100644 --- a/fs/nfs/fs_context.c +++ b/fs/nfs/fs_context.c @@ -448,6 +448,9 @@ static int nfs_fs_context_parse_param(struct fs_context *fc, if (opt < 0) return ctx->sloppy ? 1 : opt; + if (fc->security) + ctx->has_sec_mnt_opts = 1; + switch (opt) { case Opt_source: if (fc->source) diff --git a/fs/nfs/internal.h b/fs/nfs/internal.h index 62d3189745cd..08f4f34e8cf5 100644 --- a/fs/nfs/internal.h +++ b/fs/nfs/internal.h @@ -96,6 +96,7 @@ struct nfs_fs_context { char *fscache_uniq; unsigned short protofamily; unsigned short mountfamily; + bool has_sec_mnt_opts; struct { union { diff --git a/fs/nfs/super.c b/fs/nfs/super.c index 59d846d7830f..686ccc04cd57 100644 --- a/fs/nfs/super.c +++ b/fs/nfs/super.c @@ -1058,6 +1058,7 @@ static void nfs_fill_super(struct super_block *sb, struct nfs_fs_context *ctx) &sb->s_blocksize_bits); nfs_super_set_maxbytes(sb, server->maxfilesize); + server->has_sec_mnt_opts = ctx->has_sec_mnt_opts; } static int nfs_compare_mount_options(const struct super_block *s, const struct nfs_server *b, @@ -1174,6 +1175,9 @@ static int nfs_compare_super(struct super_block *sb, struct fs_context *fc) return 0; if (!nfs_compare_userns(old, server)) return 0; + if ((old->has_sec_mnt_opts || fc->security) && + security_sb_mnt_opts_compat(sb, fc->security)) + return 0; return nfs_compare_mount_options(sb, server, fc); } diff --git a/include/linux/nfs_fs_sb.h b/include/linux/nfs_fs_sb.h index 38e60ec742df..3f0acada5794 100644 --- a/include/linux/nfs_fs_sb.h +++ b/include/linux/nfs_fs_sb.h @@ -254,6 +254,7 @@ struct nfs_server { /* User namespace info */ const struct cred *cred; + bool has_sec_mnt_opts; }; /* Server capabilities */ -- 2.27.0 ^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: [PATCH v3 3/3] NFSv4 account for selinux security context when deciding to share superblock 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 0 siblings, 0 replies; 24+ messages in thread From: Paul Moore @ 2021-03-22 19:04 UTC (permalink / raw) To: Olga Kornievskaia Cc: trond.myklebust, anna.schumaker, linux-nfs, linux-security-module, selinux On Fri, Feb 19, 2021 at 5:25 PM Olga Kornievskaia <olga.kornievskaia@gmail.com> wrote: > > From: Olga Kornievskaia <kolga@netapp.com> > > Keep track of whether or not there were LSM security context > options passed during mount (ie creation of the superblock). > Then, while deciding if the superblock can be shared for the new > mount, check if the newly passed in LSM security context options > are compatible with the existing superblock's ones by calling > security_sb_mnt_opts_compat(). > > Previously, with selinux enabled, NFS wasn't able to do the > following 2mounts: > mount -o vers=4.2,sec=sys,context=system_u:object_r:root_t:s0 > <serverip>:/ /mnt > mount -o vers=4.2,sec=sys,context=system_u:object_r:swapfile_t:s0 > <serverip>:/scratch /scratch > > 2nd mount would fail with "mount.nfs: an incorrect mount option was > specified" and var log messages would have: > "SElinux: mount invalid. Same superblock, different security > settings for.." > > Signed-off-by: Olga Kornievskaia <kolga@netapp.com> > --- > fs/nfs/fs_context.c | 3 +++ > fs/nfs/internal.h | 1 + > fs/nfs/super.c | 4 ++++ > include/linux/nfs_fs_sb.h | 1 + > 4 files changed, 9 insertions(+) Merged into selinux/next, thanks. -- paul moore www.paul-moore.com ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v3 1/3] [security] Add new hook to compare new mount to an existing mount 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-02-19 22:22 ` [PATCH v3 3/3] NFSv4 account for selinux security context when deciding to share superblock Olga Kornievskaia @ 2021-02-25 17:53 ` Paul Moore 2021-02-25 18:03 ` Olga Kornievskaia 2 siblings, 1 reply; 24+ messages in thread From: Paul Moore @ 2021-02-25 17:53 UTC (permalink / raw) To: Olga Kornievskaia Cc: trond.myklebust, anna.schumaker, linux-nfs, linux-security-module, selinux 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v3 1/3] [security] Add new hook to compare new mount to an existing mount 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 ` (2 more replies) 0 siblings, 3 replies; 24+ messages in thread From: Olga Kornievskaia @ 2021-02-25 18:03 UTC (permalink / raw) To: Paul Moore Cc: Trond Myklebust, Anna Schumaker, linux-nfs, Linux Security Module list, SElinux list 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? 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v3 1/3] [security] Add new hook to compare new mount to an existing mount 2021-02-25 18:03 ` 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 2 siblings, 0 replies; 24+ messages in thread From: Casey Schaufler @ 2021-02-25 18:22 UTC (permalink / raw) To: Olga Kornievskaia, Paul Moore Cc: Trond Myklebust, Anna Schumaker, linux-nfs, Linux Security Module list, SElinux list, Casey Schaufler 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v3 1/3] [security] Add new hook to compare new mount to an existing mount 2021-02-25 18:03 ` 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 2 siblings, 0 replies; 24+ messages in thread From: Paul Moore @ 2021-02-25 19:30 UTC (permalink / raw) To: Olga Kornievskaia Cc: Trond Myklebust, Anna Schumaker, linux-nfs, Linux Security Module list, SElinux list On Thu, Feb 25, 2021 at 1:03 PM Olga Kornievskaia <olga.kornievskaia@gmail.com> 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? 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. I didn't have anything particular in mind, I just *really* don't like the ambiguity around "compatible". Perhaps we can take away some of the ambiguity by providing some more explanation, how about something like this: "Determine if the new mount options in @mnt_opts are allowed given the existing mounted filesystem at @sb." ... it's a pretty minor change, I'll readily admit that, but it exchanges "compatible" for "allowed" which I *think* makes it a bit more concrete. -- paul moore www.paul-moore.com ^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH v4 1/3] [security] Add new hook to compare new mount to an existing mount 2021-02-25 18:03 ` Olga Kornievskaia 2021-02-25 18:22 ` Casey Schaufler 2021-02-25 19:30 ` Paul Moore @ 2021-02-27 3:37 ` Olga Kornievskaia 2021-03-02 18:20 ` Anna Schumaker 2 siblings, 1 reply; 24+ messages in thread From: Olga Kornievskaia @ 2021-02-27 3:37 UTC (permalink / raw) To: trond.myklebust, anna.schumaker; +Cc: linux-nfs, linux-security-module, selinux 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_hook_defs.h b/include/linux/lsm_hook_defs.h index 7aaa753b8608..1b12a5266a51 100644 --- a/include/linux/lsm_hook_defs.h +++ b/include/linux/lsm_hook_defs.h @@ -62,6 +62,7 @@ LSM_HOOK(int, 0, sb_alloc_security, struct super_block *sb) LSM_HOOK(void, LSM_RET_VOID, sb_free_security, struct super_block *sb) LSM_HOOK(void, LSM_RET_VOID, sb_free_mnt_opts, void *mnt_opts) LSM_HOOK(int, 0, sb_eat_lsm_opts, char *orig, void **mnt_opts) +LSM_HOOK(int, 0, sb_mnt_opts_compat, struct super_block *sb, void *mnt_opts) LSM_HOOK(int, 0, sb_remount, struct super_block *sb, void *mnt_opts) LSM_HOOK(int, 0, sb_kern_mount, struct super_block *sb) LSM_HOOK(int, 0, sb_show_options, struct seq_file *m, struct super_block *sb) diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h index a19adef1f088..0de8eb2ea547 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 new mount options in @mnt_opts are allowed given + * the existing mounted filesystem at @sb. + * @sb superblock being compared + * @mnt_opts new mount options + * Return 0 if options are compatible. * @sb_remount: * Extracts security system specific mount options and verifies no changes * are being made to those options. diff --git a/include/linux/security.h b/include/linux/security.h index c35ea0ffccd9..50db3d5d1608 100644 --- a/include/linux/security.h +++ b/include/linux/security.h @@ -291,6 +291,7 @@ int security_sb_alloc(struct super_block *sb); void security_sb_free(struct super_block *sb); void security_free_mnt_opts(void **mnt_opts); int security_sb_eat_lsm_opts(char *options, void **mnt_opts); +int security_sb_mnt_opts_compat(struct super_block *sb, void *mnt_opts); int security_sb_remount(struct super_block *sb, void *mnt_opts); int security_sb_kern_mount(struct super_block *sb); int security_sb_show_options(struct seq_file *m, struct super_block *sb); @@ -635,6 +636,13 @@ static inline int security_sb_remount(struct super_block *sb, return 0; } +static inline int security_sb_mnt_opts_compat(struct super_block *sb, + void *mnt_opts) +{ + return 0; +} + + static inline int security_sb_kern_mount(struct super_block *sb) { return 0; diff --git a/security/security.c b/security/security.c index 7b09cfbae94f..56cf5563efde 100644 --- a/security/security.c +++ b/security/security.c @@ -890,6 +890,13 @@ int security_sb_eat_lsm_opts(char *options, void **mnt_opts) } EXPORT_SYMBOL(security_sb_eat_lsm_opts); +int security_sb_mnt_opts_compat(struct super_block *sb, + void *mnt_opts) +{ + return call_int_hook(sb_mnt_opts_compat, 0, sb, mnt_opts); +} +EXPORT_SYMBOL(security_sb_mnt_opts_compat); + int security_sb_remount(struct super_block *sb, void *mnt_opts) { diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c index 644b17ec9e63..afee3a222a0e 100644 --- a/security/selinux/hooks.c +++ b/security/selinux/hooks.c @@ -2656,6 +2656,61 @@ static int selinux_sb_eat_lsm_opts(char *options, void **mnt_opts) return rc; } +static int selinux_sb_mnt_opts_compat(struct super_block *sb, void *mnt_opts) +{ + struct selinux_mnt_opts *opts = mnt_opts; + struct superblock_security_struct *sbsec = sb->s_security; + u32 sid; + int rc; + + /* + * Superblock not initialized (i.e. no options) - reject if any + * options specified, otherwise accept. + */ + if (!(sbsec->flags & SE_SBINITIALIZED)) + return opts ? 1 : 0; + + /* + * Superblock initialized and no options specified - reject if + * superblock has any options set, otherwise accept. + */ + if (!opts) + return (sbsec->flags & SE_MNTMASK) ? 1 : 0; + + if (opts->fscontext) { + rc = parse_sid(sb, opts->fscontext, &sid); + if (rc) + return 1; + if (bad_option(sbsec, FSCONTEXT_MNT, sbsec->sid, sid)) + return 1; + } + if (opts->context) { + rc = parse_sid(sb, opts->context, &sid); + if (rc) + return 1; + if (bad_option(sbsec, CONTEXT_MNT, sbsec->mntpoint_sid, sid)) + return 1; + } + if (opts->rootcontext) { + struct inode_security_struct *root_isec; + + root_isec = backing_inode_security(sb->s_root); + rc = parse_sid(sb, opts->rootcontext, &sid); + if (rc) + return 1; + if (bad_option(sbsec, ROOTCONTEXT_MNT, root_isec->sid, sid)) + return 1; + } + if (opts->defcontext) { + rc = parse_sid(sb, opts->defcontext, &sid); + if (rc) + return 1; + if (bad_option(sbsec, DEFCONTEXT_MNT, sbsec->def_sid, sid)) + return 1; + } + return 0; +} + static int selinux_sb_remount(struct super_block *sb, void *mnt_opts) { struct selinux_mnt_opts *opts = mnt_opts; @@ -6984,6 +7039,7 @@ static struct security_hook_list selinux_hooks[] __lsm_ro_after_init = { LSM_HOOK_INIT(sb_free_security, selinux_sb_free_security), LSM_HOOK_INIT(sb_free_mnt_opts, selinux_free_mnt_opts), + LSM_HOOK_INIT(sb_mnt_opts_compat, selinux_sb_mnt_opts_compat), LSM_HOOK_INIT(sb_remount, selinux_sb_remount), LSM_HOOK_INIT(sb_kern_mount, selinux_sb_kern_mount), LSM_HOOK_INIT(sb_show_options, selinux_sb_show_options), -- 2.27.0 ^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: [PATCH v4 1/3] [security] Add new hook to compare new mount to an existing mount 2021-02-27 3:37 ` [PATCH v4 " Olga Kornievskaia @ 2021-03-02 18:20 ` Anna Schumaker 2021-03-02 18:51 ` Casey Schaufler 0 siblings, 1 reply; 24+ messages in thread From: Anna Schumaker @ 2021-03-02 18:20 UTC (permalink / raw) To: Olga Kornievskaia, casey Cc: Trond Myklebust, Linux NFS Mailing List, linux-security-module, selinux Hi Casey, On Fri, Feb 26, 2021 at 10:40 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> Do you have any other thoughts on this patch? I'm also wondering how you want to handle sending it upstream. I'm happy to take it through the NFS tree (with an acked-by) for a 5.12-rc with Olga's bugfix patches, but if you have other thoughts or plans then let me know! Thanks, Anna > --- > 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_hook_defs.h b/include/linux/lsm_hook_defs.h > index 7aaa753b8608..1b12a5266a51 100644 > --- a/include/linux/lsm_hook_defs.h > +++ b/include/linux/lsm_hook_defs.h > @@ -62,6 +62,7 @@ LSM_HOOK(int, 0, sb_alloc_security, struct super_block *sb) > LSM_HOOK(void, LSM_RET_VOID, sb_free_security, struct super_block *sb) > LSM_HOOK(void, LSM_RET_VOID, sb_free_mnt_opts, void *mnt_opts) > LSM_HOOK(int, 0, sb_eat_lsm_opts, char *orig, void **mnt_opts) > +LSM_HOOK(int, 0, sb_mnt_opts_compat, struct super_block *sb, void *mnt_opts) > LSM_HOOK(int, 0, sb_remount, struct super_block *sb, void *mnt_opts) > LSM_HOOK(int, 0, sb_kern_mount, struct super_block *sb) > LSM_HOOK(int, 0, sb_show_options, struct seq_file *m, struct super_block *sb) > diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h > index a19adef1f088..0de8eb2ea547 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 new mount options in @mnt_opts are allowed given > + * the existing mounted filesystem at @sb. > + * @sb superblock being compared > + * @mnt_opts new mount options > + * Return 0 if options are compatible. > * @sb_remount: > * Extracts security system specific mount options and verifies no changes > * are being made to those options. > diff --git a/include/linux/security.h b/include/linux/security.h > index c35ea0ffccd9..50db3d5d1608 100644 > --- a/include/linux/security.h > +++ b/include/linux/security.h > @@ -291,6 +291,7 @@ int security_sb_alloc(struct super_block *sb); > void security_sb_free(struct super_block *sb); > void security_free_mnt_opts(void **mnt_opts); > int security_sb_eat_lsm_opts(char *options, void **mnt_opts); > +int security_sb_mnt_opts_compat(struct super_block *sb, void *mnt_opts); > int security_sb_remount(struct super_block *sb, void *mnt_opts); > int security_sb_kern_mount(struct super_block *sb); > int security_sb_show_options(struct seq_file *m, struct super_block *sb); > @@ -635,6 +636,13 @@ static inline int security_sb_remount(struct super_block *sb, > return 0; > } > > +static inline int security_sb_mnt_opts_compat(struct super_block *sb, > + void *mnt_opts) > +{ > + return 0; > +} > + > + > static inline int security_sb_kern_mount(struct super_block *sb) > { > return 0; > diff --git a/security/security.c b/security/security.c > index 7b09cfbae94f..56cf5563efde 100644 > --- a/security/security.c > +++ b/security/security.c > @@ -890,6 +890,13 @@ int security_sb_eat_lsm_opts(char *options, void **mnt_opts) > } > EXPORT_SYMBOL(security_sb_eat_lsm_opts); > > +int security_sb_mnt_opts_compat(struct super_block *sb, > + void *mnt_opts) > +{ > + return call_int_hook(sb_mnt_opts_compat, 0, sb, mnt_opts); > +} > +EXPORT_SYMBOL(security_sb_mnt_opts_compat); > + > int security_sb_remount(struct super_block *sb, > void *mnt_opts) > { > diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c > index 644b17ec9e63..afee3a222a0e 100644 > --- a/security/selinux/hooks.c > +++ b/security/selinux/hooks.c > @@ -2656,6 +2656,61 @@ static int selinux_sb_eat_lsm_opts(char *options, void **mnt_opts) > return rc; > } > > +static int selinux_sb_mnt_opts_compat(struct super_block *sb, void *mnt_opts) > +{ > + struct selinux_mnt_opts *opts = mnt_opts; > + struct superblock_security_struct *sbsec = sb->s_security; > + u32 sid; > + int rc; > + > + /* > + * Superblock not initialized (i.e. no options) - reject if any > + * options specified, otherwise accept. > + */ > + if (!(sbsec->flags & SE_SBINITIALIZED)) > + return opts ? 1 : 0; > + > + /* > + * Superblock initialized and no options specified - reject if > + * superblock has any options set, otherwise accept. > + */ > + if (!opts) > + return (sbsec->flags & SE_MNTMASK) ? 1 : 0; > + > + if (opts->fscontext) { > + rc = parse_sid(sb, opts->fscontext, &sid); > + if (rc) > + return 1; > + if (bad_option(sbsec, FSCONTEXT_MNT, sbsec->sid, sid)) > + return 1; > + } > + if (opts->context) { > + rc = parse_sid(sb, opts->context, &sid); > + if (rc) > + return 1; > + if (bad_option(sbsec, CONTEXT_MNT, sbsec->mntpoint_sid, sid)) > + return 1; > + } > + if (opts->rootcontext) { > + struct inode_security_struct *root_isec; > + > + root_isec = backing_inode_security(sb->s_root); > + rc = parse_sid(sb, opts->rootcontext, &sid); > + if (rc) > + return 1; > + if (bad_option(sbsec, ROOTCONTEXT_MNT, root_isec->sid, sid)) > + return 1; > + } > + if (opts->defcontext) { > + rc = parse_sid(sb, opts->defcontext, &sid); > + if (rc) > + return 1; > + if (bad_option(sbsec, DEFCONTEXT_MNT, sbsec->def_sid, sid)) > + return 1; > + } > + return 0; > +} > + > static int selinux_sb_remount(struct super_block *sb, void *mnt_opts) > { > struct selinux_mnt_opts *opts = mnt_opts; > @@ -6984,6 +7039,7 @@ static struct security_hook_list selinux_hooks[] __lsm_ro_after_init = { > > LSM_HOOK_INIT(sb_free_security, selinux_sb_free_security), > LSM_HOOK_INIT(sb_free_mnt_opts, selinux_free_mnt_opts), > + LSM_HOOK_INIT(sb_mnt_opts_compat, selinux_sb_mnt_opts_compat), > LSM_HOOK_INIT(sb_remount, selinux_sb_remount), > LSM_HOOK_INIT(sb_kern_mount, selinux_sb_kern_mount), > LSM_HOOK_INIT(sb_show_options, selinux_sb_show_options), > -- > 2.27.0 > ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v4 1/3] [security] Add new hook to compare new mount to an existing mount 2021-03-02 18:20 ` Anna Schumaker @ 2021-03-02 18:51 ` Casey Schaufler 2021-03-05 1:32 ` Paul Moore 0 siblings, 1 reply; 24+ messages in thread From: Casey Schaufler @ 2021-03-02 18:51 UTC (permalink / raw) To: Anna Schumaker, Olga Kornievskaia Cc: Trond Myklebust, Linux NFS Mailing List, linux-security-module, selinux, Casey Schaufler On 3/2/2021 10:20 AM, Anna Schumaker wrote: > Hi Casey, > > On Fri, Feb 26, 2021 at 10:40 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> > Do you have any other thoughts on this patch? I'm also wondering how > you want to handle sending it upstream. James Morris is the maintainer for the security sub-system, so you'll want to send this through him. He will want you to have an ACK from Paul Moore, who is the SELinux maintainer. > I'm happy to take it through > the NFS tree (with an acked-by) for a 5.12-rc with Olga's bugfix > patches, but if you have other thoughts or plans then let me know! > > Thanks, > Anna > >> --- >> 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_hook_defs.h b/include/linux/lsm_hook_defs.h >> index 7aaa753b8608..1b12a5266a51 100644 >> --- a/include/linux/lsm_hook_defs.h >> +++ b/include/linux/lsm_hook_defs.h >> @@ -62,6 +62,7 @@ LSM_HOOK(int, 0, sb_alloc_security, struct super_block *sb) >> LSM_HOOK(void, LSM_RET_VOID, sb_free_security, struct super_block *sb) >> LSM_HOOK(void, LSM_RET_VOID, sb_free_mnt_opts, void *mnt_opts) >> LSM_HOOK(int, 0, sb_eat_lsm_opts, char *orig, void **mnt_opts) >> +LSM_HOOK(int, 0, sb_mnt_opts_compat, struct super_block *sb, void *mnt_opts) >> LSM_HOOK(int, 0, sb_remount, struct super_block *sb, void *mnt_opts) >> LSM_HOOK(int, 0, sb_kern_mount, struct super_block *sb) >> LSM_HOOK(int, 0, sb_show_options, struct seq_file *m, struct super_block *sb) >> diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h >> index a19adef1f088..0de8eb2ea547 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 new mount options in @mnt_opts are allowed given >> + * the existing mounted filesystem at @sb. >> + * @sb superblock being compared >> + * @mnt_opts new mount options >> + * Return 0 if options are compatible. >> * @sb_remount: >> * Extracts security system specific mount options and verifies no changes >> * are being made to those options. >> diff --git a/include/linux/security.h b/include/linux/security.h >> index c35ea0ffccd9..50db3d5d1608 100644 >> --- a/include/linux/security.h >> +++ b/include/linux/security.h >> @@ -291,6 +291,7 @@ int security_sb_alloc(struct super_block *sb); >> void security_sb_free(struct super_block *sb); >> void security_free_mnt_opts(void **mnt_opts); >> int security_sb_eat_lsm_opts(char *options, void **mnt_opts); >> +int security_sb_mnt_opts_compat(struct super_block *sb, void *mnt_opts); >> int security_sb_remount(struct super_block *sb, void *mnt_opts); >> int security_sb_kern_mount(struct super_block *sb); >> int security_sb_show_options(struct seq_file *m, struct super_block *sb); >> @@ -635,6 +636,13 @@ static inline int security_sb_remount(struct super_block *sb, >> return 0; >> } >> >> +static inline int security_sb_mnt_opts_compat(struct super_block *sb, >> + void *mnt_opts) >> +{ >> + return 0; >> +} >> + >> + >> static inline int security_sb_kern_mount(struct super_block *sb) >> { >> return 0; >> diff --git a/security/security.c b/security/security.c >> index 7b09cfbae94f..56cf5563efde 100644 >> --- a/security/security.c >> +++ b/security/security.c >> @@ -890,6 +890,13 @@ int security_sb_eat_lsm_opts(char *options, void **mnt_opts) >> } >> EXPORT_SYMBOL(security_sb_eat_lsm_opts); >> >> +int security_sb_mnt_opts_compat(struct super_block *sb, >> + void *mnt_opts) >> +{ >> + return call_int_hook(sb_mnt_opts_compat, 0, sb, mnt_opts); >> +} >> +EXPORT_SYMBOL(security_sb_mnt_opts_compat); >> + >> int security_sb_remount(struct super_block *sb, >> void *mnt_opts) >> { >> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c >> index 644b17ec9e63..afee3a222a0e 100644 >> --- a/security/selinux/hooks.c >> +++ b/security/selinux/hooks.c >> @@ -2656,6 +2656,61 @@ static int selinux_sb_eat_lsm_opts(char *options, void **mnt_opts) >> return rc; >> } >> >> +static int selinux_sb_mnt_opts_compat(struct super_block *sb, void *mnt_opts) >> +{ >> + struct selinux_mnt_opts *opts = mnt_opts; >> + struct superblock_security_struct *sbsec = sb->s_security; >> + u32 sid; >> + int rc; >> + >> + /* >> + * Superblock not initialized (i.e. no options) - reject if any >> + * options specified, otherwise accept. >> + */ >> + if (!(sbsec->flags & SE_SBINITIALIZED)) >> + return opts ? 1 : 0; >> + >> + /* >> + * Superblock initialized and no options specified - reject if >> + * superblock has any options set, otherwise accept. >> + */ >> + if (!opts) >> + return (sbsec->flags & SE_MNTMASK) ? 1 : 0; >> + >> + if (opts->fscontext) { >> + rc = parse_sid(sb, opts->fscontext, &sid); >> + if (rc) >> + return 1; >> + if (bad_option(sbsec, FSCONTEXT_MNT, sbsec->sid, sid)) >> + return 1; >> + } >> + if (opts->context) { >> + rc = parse_sid(sb, opts->context, &sid); >> + if (rc) >> + return 1; >> + if (bad_option(sbsec, CONTEXT_MNT, sbsec->mntpoint_sid, sid)) >> + return 1; >> + } >> + if (opts->rootcontext) { >> + struct inode_security_struct *root_isec; >> + >> + root_isec = backing_inode_security(sb->s_root); >> + rc = parse_sid(sb, opts->rootcontext, &sid); >> + if (rc) >> + return 1; >> + if (bad_option(sbsec, ROOTCONTEXT_MNT, root_isec->sid, sid)) >> + return 1; >> + } >> + if (opts->defcontext) { >> + rc = parse_sid(sb, opts->defcontext, &sid); >> + if (rc) >> + return 1; >> + if (bad_option(sbsec, DEFCONTEXT_MNT, sbsec->def_sid, sid)) >> + return 1; >> + } >> + return 0; >> +} >> + >> static int selinux_sb_remount(struct super_block *sb, void *mnt_opts) >> { >> struct selinux_mnt_opts *opts = mnt_opts; >> @@ -6984,6 +7039,7 @@ static struct security_hook_list selinux_hooks[] __lsm_ro_after_init = { >> >> LSM_HOOK_INIT(sb_free_security, selinux_sb_free_security), >> LSM_HOOK_INIT(sb_free_mnt_opts, selinux_free_mnt_opts), >> + LSM_HOOK_INIT(sb_mnt_opts_compat, selinux_sb_mnt_opts_compat), >> LSM_HOOK_INIT(sb_remount, selinux_sb_remount), >> LSM_HOOK_INIT(sb_kern_mount, selinux_sb_kern_mount), >> LSM_HOOK_INIT(sb_show_options, selinux_sb_show_options), >> -- >> 2.27.0 >> ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v4 1/3] [security] Add new hook to compare new mount to an existing mount 2021-03-02 18:51 ` Casey Schaufler @ 2021-03-05 1:32 ` Paul Moore 2021-03-12 15:45 ` Anna Schumaker 0 siblings, 1 reply; 24+ messages in thread From: Paul Moore @ 2021-03-05 1:32 UTC (permalink / raw) To: Casey Schaufler, Anna Schumaker Cc: Olga Kornievskaia, Trond Myklebust, Linux NFS Mailing List, linux-security-module, selinux On Tue, Mar 2, 2021 at 10:53 PM Casey Schaufler <casey@schaufler-ca.com> wrote: > On 3/2/2021 10:20 AM, Anna Schumaker wrote: > > Hi Casey, > > > > On Fri, Feb 26, 2021 at 10:40 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> > > Do you have any other thoughts on this patch? I'm also wondering how > > you want to handle sending it upstream. > > James Morris is the maintainer for the security sub-system, > so you'll want to send this through him. He will want you to > have an ACK from Paul Moore, who is the SELinux maintainer. In the past I've pulled patches such as this (new LSM hook, with only a SELinux implementation of the new hook) in via the selinux/next tree after the other LSMs have ACK'd the new hook. This helps limit merge problems with other SELinux changes and allows us (the SELinux folks) to include it in the ongoing testing that we do during the -rcX releases. So Anna, if you or anyone else on the NFS side of the house want to add your ACKs/REVIEWs/etc. please do so as I don't like merging patches that cross subsystem boundaries without having all the associated ACKs. Casey, James, and other LSM folks please do the same. -- paul moore www.paul-moore.com ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v4 1/3] [security] Add new hook to compare new mount to an existing mount 2021-03-05 1:32 ` Paul Moore @ 2021-03-12 15:45 ` Anna Schumaker 2021-03-12 21:54 ` Paul Moore 0 siblings, 1 reply; 24+ messages in thread From: Anna Schumaker @ 2021-03-12 15:45 UTC (permalink / raw) To: Paul Moore Cc: Casey Schaufler, Olga Kornievskaia, Trond Myklebust, Linux NFS Mailing List, Linux Security Module list, SElinux list On Thu, Mar 4, 2021 at 8:34 PM Paul Moore <paul@paul-moore.com> wrote: > > On Tue, Mar 2, 2021 at 10:53 PM Casey Schaufler <casey@schaufler-ca.com> wrote: > > On 3/2/2021 10:20 AM, Anna Schumaker wrote: > > > Hi Casey, > > > > > > On Fri, Feb 26, 2021 at 10:40 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> > > > Do you have any other thoughts on this patch? I'm also wondering how > > > you want to handle sending it upstream. > > > > James Morris is the maintainer for the security sub-system, > > so you'll want to send this through him. He will want you to > > have an ACK from Paul Moore, who is the SELinux maintainer. > > In the past I've pulled patches such as this (new LSM hook, with only > a SELinux implementation of the new hook) in via the selinux/next tree > after the other LSMs have ACK'd the new hook. This helps limit merge > problems with other SELinux changes and allows us (the SELinux folks) > to include it in the ongoing testing that we do during the -rcX > releases. > > So Anna, if you or anyone else on the NFS side of the house want to > add your ACKs/REVIEWs/etc. please do so as I don't like merging > patches that cross subsystem boundaries without having all the > associated ACKs. Casey, James, and other LSM folks please do the > same. Sure: Acked-by: Anna Schumaker <Anna.Schumaker@Netapp.com> Are you also going to take patch 3/3 that uses the new hook, or should that go through the NFS tree? Patch 2/3 is a cleanup that can go through the NFS tree. Anna > > -- > paul moore > www.paul-moore.com ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v4 1/3] [security] Add new hook to compare new mount to an existing mount 2021-03-12 15:45 ` Anna Schumaker @ 2021-03-12 21:54 ` Paul Moore 2021-03-12 22:34 ` Olga Kornievskaia 0 siblings, 1 reply; 24+ messages in thread From: Paul Moore @ 2021-03-12 21:54 UTC (permalink / raw) To: Anna Schumaker Cc: Casey Schaufler, Olga Kornievskaia, Trond Myklebust, Linux NFS Mailing List, Linux Security Module list, SElinux list On Fri, Mar 12, 2021 at 10:45 AM Anna Schumaker <anna.schumaker@netapp.com> wrote: > On Thu, Mar 4, 2021 at 8:34 PM Paul Moore <paul@paul-moore.com> wrote: > > On Tue, Mar 2, 2021 at 10:53 PM Casey Schaufler <casey@schaufler-ca.com> wrote: > > > On 3/2/2021 10:20 AM, Anna Schumaker wrote: > > > > Hi Casey, > > > > > > > > On Fri, Feb 26, 2021 at 10:40 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> > > > > Do you have any other thoughts on this patch? I'm also wondering how > > > > you want to handle sending it upstream. > > > > > > James Morris is the maintainer for the security sub-system, > > > so you'll want to send this through him. He will want you to > > > have an ACK from Paul Moore, who is the SELinux maintainer. > > > > In the past I've pulled patches such as this (new LSM hook, with only > > a SELinux implementation of the new hook) in via the selinux/next tree > > after the other LSMs have ACK'd the new hook. This helps limit merge > > problems with other SELinux changes and allows us (the SELinux folks) > > to include it in the ongoing testing that we do during the -rcX > > releases. > > > > So Anna, if you or anyone else on the NFS side of the house want to > > add your ACKs/REVIEWs/etc. please do so as I don't like merging > > patches that cross subsystem boundaries without having all the > > associated ACKs. Casey, James, and other LSM folks please do the > > same. > > Sure: > Acked-by: Anna Schumaker <Anna.Schumaker@Netapp.com> > > Are you also going to take patch 3/3 that uses the new hook, or should > that go through the NFS tree? Patch 2/3 is a cleanup that can go > through the NFS tree. Generally when patches are posted as patchsets I would apply the whole patchset assuming they patches were all good, however it does seem like patch 2/3 is not strictly related to the other two? That said, as long as your ACK applies to all three patches in the patchset I have no problem applying all of them to the selinux/next tree once some of the other LSM maintainers provide their ACKs (while there may only a SELinux implementation of the hook at the moment, we need to make sure the other LSMs are okay with the basic hook concept). Also, did the v4 posting only include patch 1/3? I see v3 postings for the other two patches, but the only v4 patch I see is 1/3 ... ? -- paul moore www.paul-moore.com ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v4 1/3] [security] Add new hook to compare new mount to an existing mount 2021-03-12 21:54 ` Paul Moore @ 2021-03-12 22:34 ` Olga Kornievskaia 2021-03-15 1:43 ` Paul Moore 0 siblings, 1 reply; 24+ messages in thread From: Olga Kornievskaia @ 2021-03-12 22:34 UTC (permalink / raw) To: Paul Moore Cc: Anna Schumaker, Casey Schaufler, Trond Myklebust, Linux NFS Mailing List, Linux Security Module list, SElinux list On Fri, Mar 12, 2021 at 4:55 PM Paul Moore <paul@paul-moore.com> wrote: > > On Fri, Mar 12, 2021 at 10:45 AM Anna Schumaker > <anna.schumaker@netapp.com> wrote: > > On Thu, Mar 4, 2021 at 8:34 PM Paul Moore <paul@paul-moore.com> wrote: > > > On Tue, Mar 2, 2021 at 10:53 PM Casey Schaufler <casey@schaufler-ca.com> wrote: > > > > On 3/2/2021 10:20 AM, Anna Schumaker wrote: > > > > > Hi Casey, > > > > > > > > > > On Fri, Feb 26, 2021 at 10:40 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> > > > > > Do you have any other thoughts on this patch? I'm also wondering how > > > > > you want to handle sending it upstream. > > > > > > > > James Morris is the maintainer for the security sub-system, > > > > so you'll want to send this through him. He will want you to > > > > have an ACK from Paul Moore, who is the SELinux maintainer. > > > > > > In the past I've pulled patches such as this (new LSM hook, with only > > > a SELinux implementation of the new hook) in via the selinux/next tree > > > after the other LSMs have ACK'd the new hook. This helps limit merge > > > problems with other SELinux changes and allows us (the SELinux folks) > > > to include it in the ongoing testing that we do during the -rcX > > > releases. > > > > > > So Anna, if you or anyone else on the NFS side of the house want to > > > add your ACKs/REVIEWs/etc. please do so as I don't like merging > > > patches that cross subsystem boundaries without having all the > > > associated ACKs. Casey, James, and other LSM folks please do the > > > same. > > > > Sure: > > Acked-by: Anna Schumaker <Anna.Schumaker@Netapp.com> > > > > Are you also going to take patch 3/3 that uses the new hook, or should > > that go through the NFS tree? Patch 2/3 is a cleanup that can go > > through the NFS tree. > > Generally when patches are posted as patchsets I would apply the whole > patchset assuming they patches were all good, however it does seem > like patch 2/3 is not strictly related to the other two? That said, > as long as your ACK applies to all three patches in the patchset I > have no problem applying all of them to the selinux/next tree once > some of the other LSM maintainers provide their ACKs (while there may > only a SELinux implementation of the hook at the moment, we need to > make sure the other LSMs are okay with the basic hook concept). > > Also, did the v4 posting only include patch 1/3? I see v3 postings > for the other two patches, but the only v4 patch I see is 1/3 ... ? I didn't not repost patches that didn't change. > > -- > paul moore > www.paul-moore.com ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v4 1/3] [security] Add new hook to compare new mount to an existing mount 2021-03-12 22:34 ` Olga Kornievskaia @ 2021-03-15 1:43 ` Paul Moore 2021-03-15 15:30 ` Olga Kornievskaia 0 siblings, 1 reply; 24+ messages in thread From: Paul Moore @ 2021-03-15 1:43 UTC (permalink / raw) To: Olga Kornievskaia Cc: Anna Schumaker, Casey Schaufler, Trond Myklebust, Linux NFS Mailing List, Linux Security Module list, SElinux list On Fri, Mar 12, 2021 at 5:35 PM Olga Kornievskaia <olga.kornievskaia@gmail.com> wrote: > On Fri, Mar 12, 2021 at 4:55 PM Paul Moore <paul@paul-moore.com> wrote: > > > > On Fri, Mar 12, 2021 at 10:45 AM Anna Schumaker > > <anna.schumaker@netapp.com> wrote: > > > On Thu, Mar 4, 2021 at 8:34 PM Paul Moore <paul@paul-moore.com> wrote: > > > > On Tue, Mar 2, 2021 at 10:53 PM Casey Schaufler <casey@schaufler-ca.com> wrote: > > > > > On 3/2/2021 10:20 AM, Anna Schumaker wrote: > > > > > > Hi Casey, > > > > > > > > > > > > On Fri, Feb 26, 2021 at 10:40 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> > > > > > > Do you have any other thoughts on this patch? I'm also wondering how > > > > > > you want to handle sending it upstream. > > > > > > > > > > James Morris is the maintainer for the security sub-system, > > > > > so you'll want to send this through him. He will want you to > > > > > have an ACK from Paul Moore, who is the SELinux maintainer. > > > > > > > > In the past I've pulled patches such as this (new LSM hook, with only > > > > a SELinux implementation of the new hook) in via the selinux/next tree > > > > after the other LSMs have ACK'd the new hook. This helps limit merge > > > > problems with other SELinux changes and allows us (the SELinux folks) > > > > to include it in the ongoing testing that we do during the -rcX > > > > releases. > > > > > > > > So Anna, if you or anyone else on the NFS side of the house want to > > > > add your ACKs/REVIEWs/etc. please do so as I don't like merging > > > > patches that cross subsystem boundaries without having all the > > > > associated ACKs. Casey, James, and other LSM folks please do the > > > > same. > > > > > > Sure: > > > Acked-by: Anna Schumaker <Anna.Schumaker@Netapp.com> > > > > > > Are you also going to take patch 3/3 that uses the new hook, or should > > > that go through the NFS tree? Patch 2/3 is a cleanup that can go > > > through the NFS tree. > > > > Generally when patches are posted as patchsets I would apply the whole > > patchset assuming they patches were all good, however it does seem > > like patch 2/3 is not strictly related to the other two? That said, > > as long as your ACK applies to all three patches in the patchset I > > have no problem applying all of them to the selinux/next tree once > > some of the other LSM maintainers provide their ACKs (while there may > > only a SELinux implementation of the hook at the moment, we need to > > make sure the other LSMs are okay with the basic hook concept). > > > > Also, did the v4 posting only include patch 1/3? I see v3 postings > > for the other two patches, but the only v4 patch I see is 1/3 ... ? > > I didn't not repost patches that didn't change. Okay, so I'm guessing that means path 2/3 and 3/3 didn't change? While I suppose there are cases where people do not do this, it has been my experience that if someone posts a patchset and some portion of the patchset changes, due to feedback or other factors, the entire patchset is reposted under the new version number. If nothing else this helps ensure people are always looking at the latest draft of a particular patch instead of having to dig through the list to determine which patch is the most recent. -- paul moore www.paul-moore.com ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v4 1/3] [security] Add new hook to compare new mount to an existing mount 2021-03-15 1:43 ` Paul Moore @ 2021-03-15 15:30 ` Olga Kornievskaia 2021-03-15 16:15 ` Paul Moore 0 siblings, 1 reply; 24+ messages in thread From: Olga Kornievskaia @ 2021-03-15 15:30 UTC (permalink / raw) To: Paul Moore Cc: Anna Schumaker, Casey Schaufler, Trond Myklebust, Linux NFS Mailing List, Linux Security Module list, SElinux list On Sun, Mar 14, 2021 at 9:44 PM Paul Moore <paul@paul-moore.com> wrote: > > On Fri, Mar 12, 2021 at 5:35 PM Olga Kornievskaia > <olga.kornievskaia@gmail.com> wrote: > > On Fri, Mar 12, 2021 at 4:55 PM Paul Moore <paul@paul-moore.com> wrote: > > > > > > On Fri, Mar 12, 2021 at 10:45 AM Anna Schumaker > > > <anna.schumaker@netapp.com> wrote: > > > > On Thu, Mar 4, 2021 at 8:34 PM Paul Moore <paul@paul-moore.com> wrote: > > > > > On Tue, Mar 2, 2021 at 10:53 PM Casey Schaufler <casey@schaufler-ca.com> wrote: > > > > > > On 3/2/2021 10:20 AM, Anna Schumaker wrote: > > > > > > > Hi Casey, > > > > > > > > > > > > > > On Fri, Feb 26, 2021 at 10:40 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> > > > > > > > Do you have any other thoughts on this patch? I'm also wondering how > > > > > > > you want to handle sending it upstream. > > > > > > > > > > > > James Morris is the maintainer for the security sub-system, > > > > > > so you'll want to send this through him. He will want you to > > > > > > have an ACK from Paul Moore, who is the SELinux maintainer. > > > > > > > > > > In the past I've pulled patches such as this (new LSM hook, with only > > > > > a SELinux implementation of the new hook) in via the selinux/next tree > > > > > after the other LSMs have ACK'd the new hook. This helps limit merge > > > > > problems with other SELinux changes and allows us (the SELinux folks) > > > > > to include it in the ongoing testing that we do during the -rcX > > > > > releases. > > > > > > > > > > So Anna, if you or anyone else on the NFS side of the house want to > > > > > add your ACKs/REVIEWs/etc. please do so as I don't like merging > > > > > patches that cross subsystem boundaries without having all the > > > > > associated ACKs. Casey, James, and other LSM folks please do the > > > > > same. > > > > > > > > Sure: > > > > Acked-by: Anna Schumaker <Anna.Schumaker@Netapp.com> > > > > > > > > Are you also going to take patch 3/3 that uses the new hook, or should > > > > that go through the NFS tree? Patch 2/3 is a cleanup that can go > > > > through the NFS tree. > > > > > > Generally when patches are posted as patchsets I would apply the whole > > > patchset assuming they patches were all good, however it does seem > > > like patch 2/3 is not strictly related to the other two? That said, > > > as long as your ACK applies to all three patches in the patchset I > > > have no problem applying all of them to the selinux/next tree once > > > some of the other LSM maintainers provide their ACKs (while there may > > > only a SELinux implementation of the hook at the moment, we need to > > > make sure the other LSMs are okay with the basic hook concept). > > > > > > Also, did the v4 posting only include patch 1/3? I see v3 postings > > > for the other two patches, but the only v4 patch I see is 1/3 ... ? > > > > I didn't not repost patches that didn't change. > > Okay, so I'm guessing that means path 2/3 and 3/3 didn't change? > > While I suppose there are cases where people do not do this, it has > been my experience that if someone posts a patchset and some portion > of the patchset changes, due to feedback or other factors, the entire > patchset is reposted under the new version number. If nothing else > this helps ensure people are always looking at the latest draft of a > particular patch instead of having to dig through the list to > determine which patch is the most recent. Correct, patches 2&3 didn't change and selinux patch generated several iterations. Would you like me to repost a series? I'm not sure what I'm supposed to do at this point. > > -- > paul moore > www.paul-moore.com ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v4 1/3] [security] Add new hook to compare new mount to an existing mount 2021-03-15 15:30 ` Olga Kornievskaia @ 2021-03-15 16:15 ` Paul Moore 2021-03-18 19:12 ` Paul Moore 0 siblings, 1 reply; 24+ messages in thread From: Paul Moore @ 2021-03-15 16:15 UTC (permalink / raw) To: Olga Kornievskaia Cc: Anna Schumaker, Casey Schaufler, Trond Myklebust, Linux NFS Mailing List, Linux Security Module list, SElinux list On Mon, Mar 15, 2021 at 11:31 AM Olga Kornievskaia <olga.kornievskaia@gmail.com> wrote: > On Sun, Mar 14, 2021 at 9:44 PM Paul Moore <paul@paul-moore.com> wrote: > > On Fri, Mar 12, 2021 at 5:35 PM Olga Kornievskaia > > <olga.kornievskaia@gmail.com> wrote: > > > On Fri, Mar 12, 2021 at 4:55 PM Paul Moore <paul@paul-moore.com> wrote: > > > > > > > > On Fri, Mar 12, 2021 at 10:45 AM Anna Schumaker > > > > <anna.schumaker@netapp.com> wrote: > > > > > On Thu, Mar 4, 2021 at 8:34 PM Paul Moore <paul@paul-moore.com> wrote: > > > > > > On Tue, Mar 2, 2021 at 10:53 PM Casey Schaufler <casey@schaufler-ca.com> wrote: > > > > > > > On 3/2/2021 10:20 AM, Anna Schumaker wrote: > > > > > > > > Hi Casey, > > > > > > > > > > > > > > > > On Fri, Feb 26, 2021 at 10:40 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> > > > > > > > > Do you have any other thoughts on this patch? I'm also wondering how > > > > > > > > you want to handle sending it upstream. > > > > > > > > > > > > > > James Morris is the maintainer for the security sub-system, > > > > > > > so you'll want to send this through him. He will want you to > > > > > > > have an ACK from Paul Moore, who is the SELinux maintainer. > > > > > > > > > > > > In the past I've pulled patches such as this (new LSM hook, with only > > > > > > a SELinux implementation of the new hook) in via the selinux/next tree > > > > > > after the other LSMs have ACK'd the new hook. This helps limit merge > > > > > > problems with other SELinux changes and allows us (the SELinux folks) > > > > > > to include it in the ongoing testing that we do during the -rcX > > > > > > releases. > > > > > > > > > > > > So Anna, if you or anyone else on the NFS side of the house want to > > > > > > add your ACKs/REVIEWs/etc. please do so as I don't like merging > > > > > > patches that cross subsystem boundaries without having all the > > > > > > associated ACKs. Casey, James, and other LSM folks please do the > > > > > > same. > > > > > > > > > > Sure: > > > > > Acked-by: Anna Schumaker <Anna.Schumaker@Netapp.com> > > > > > > > > > > Are you also going to take patch 3/3 that uses the new hook, or should > > > > > that go through the NFS tree? Patch 2/3 is a cleanup that can go > > > > > through the NFS tree. > > > > > > > > Generally when patches are posted as patchsets I would apply the whole > > > > patchset assuming they patches were all good, however it does seem > > > > like patch 2/3 is not strictly related to the other two? That said, > > > > as long as your ACK applies to all three patches in the patchset I > > > > have no problem applying all of them to the selinux/next tree once > > > > some of the other LSM maintainers provide their ACKs (while there may > > > > only a SELinux implementation of the hook at the moment, we need to > > > > make sure the other LSMs are okay with the basic hook concept). > > > > > > > > Also, did the v4 posting only include patch 1/3? I see v3 postings > > > > for the other two patches, but the only v4 patch I see is 1/3 ... ? > > > > > > I didn't not repost patches that didn't change. > > > > Okay, so I'm guessing that means path 2/3 and 3/3 didn't change? > > > > While I suppose there are cases where people do not do this, it has > > been my experience that if someone posts a patchset and some portion > > of the patchset changes, due to feedback or other factors, the entire > > patchset is reposted under the new version number. If nothing else > > this helps ensure people are always looking at the latest draft of a > > particular patch instead of having to dig through the list to > > determine which patch is the most recent. > > Correct, patches 2&3 didn't change and selinux patch generated several > iterations. Would you like me to repost a series? I'm not sure what > I'm supposed to do at this point. As long as we are clear that the latest draft of patch 1/3 is to be taken from the v4 patch{set} and patches 2/3 and 3/3 are to be taken from v3 of the patchset I don't think you need to do anything further. The important bit is for the other LSM folks to ACK the new hook; if I don't see anything from them, either positive or negative, I'll merge it towards the end of this week or early next. -- paul moore www.paul-moore.com ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v4 1/3] [security] Add new hook to compare new mount to an existing mount 2021-03-15 16:15 ` Paul Moore @ 2021-03-18 19:12 ` Paul Moore 2021-03-18 19:21 ` Casey Schaufler ` (2 more replies) 0 siblings, 3 replies; 24+ messages in thread From: Paul Moore @ 2021-03-18 19:12 UTC (permalink / raw) To: Linux Security Module list Cc: Anna Schumaker, Casey Schaufler, Trond Myklebust, Linux NFS Mailing List, SElinux list, Olga Kornievskaia On Mon, Mar 15, 2021 at 12:15 PM Paul Moore <paul@paul-moore.com> wrote: > As long as we are clear that the latest draft of patch 1/3 is to be > taken from the v4 patch{set} and patches 2/3 and 3/3 are to be taken > from v3 of the patchset I don't think you need to do anything further. > The important bit is for the other LSM folks to ACK the new hook; if I > don't see anything from them, either positive or negative, I'll merge > it towards the end of this week or early next. LSM folks, this is a reminder that if you want to object you've got until Monday morning to do so :) -- paul moore www.paul-moore.com ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v4 1/3] [security] Add new hook to compare new mount to an existing mount 2021-03-18 19:12 ` Paul Moore @ 2021-03-18 19:21 ` Casey Schaufler 2021-03-18 22:49 ` James Morris 2021-03-22 18:56 ` Paul Moore 2 siblings, 0 replies; 24+ messages in thread From: Casey Schaufler @ 2021-03-18 19:21 UTC (permalink / raw) To: Paul Moore, Linux Security Module list Cc: Anna Schumaker, Trond Myklebust, Linux NFS Mailing List, SElinux list, Olga Kornievskaia, Casey Schaufler On 3/18/2021 12:12 PM, Paul Moore wrote: > On Mon, Mar 15, 2021 at 12:15 PM Paul Moore <paul@paul-moore.com> wrote: >> As long as we are clear that the latest draft of patch 1/3 is to be >> taken from the v4 patch{set} and patches 2/3 and 3/3 are to be taken >> from v3 of the patchset I don't think you need to do anything further. >> The important bit is for the other LSM folks to ACK the new hook; if I >> don't see anything from them, either positive or negative, I'll merge >> it towards the end of this week or early next. > LSM folks, this is a reminder that if you want to object you've got > until Monday morning to do so :) No objections on my part. My comments have been addressed. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v4 1/3] [security] Add new hook to compare new mount to an existing mount 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 2 siblings, 1 reply; 24+ messages in thread From: James Morris @ 2021-03-18 22:49 UTC (permalink / raw) To: Paul Moore Cc: Linux Security Module list, Anna Schumaker, Casey Schaufler, Trond Myklebust, Linux NFS Mailing List, SElinux list, Olga Kornievskaia On Thu, 18 Mar 2021, Paul Moore wrote: > On Mon, Mar 15, 2021 at 12:15 PM Paul Moore <paul@paul-moore.com> wrote: > > As long as we are clear that the latest draft of patch 1/3 is to be > > taken from the v4 patch{set} and patches 2/3 and 3/3 are to be taken > > from v3 of the patchset I don't think you need to do anything further. > > The important bit is for the other LSM folks to ACK the new hook; if I > > don't see anything from them, either positive or negative, I'll merge > > it towards the end of this week or early next. > > LSM folks, this is a reminder that if you want to object you've got > until Monday morning to do so :) I'm unclear on whether a new v5 patchset was being posted -- I assume not? -- James Morris <jmorris@namei.org> ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v4 1/3] [security] Add new hook to compare new mount to an existing mount 2021-03-18 22:49 ` James Morris @ 2021-03-18 22:59 ` Olga Kornievskaia 0 siblings, 0 replies; 24+ messages in thread From: Olga Kornievskaia @ 2021-03-18 22:59 UTC (permalink / raw) To: James Morris Cc: Paul Moore, Linux Security Module list, Anna Schumaker, Casey Schaufler, Trond Myklebust, Linux NFS Mailing List, SElinux list On Thu, Mar 18, 2021 at 6:51 PM James Morris <jmorris@namei.org> wrote: > > On Thu, 18 Mar 2021, Paul Moore wrote: > > > On Mon, Mar 15, 2021 at 12:15 PM Paul Moore <paul@paul-moore.com> wrote: > > > As long as we are clear that the latest draft of patch 1/3 is to be > > > taken from the v4 patch{set} and patches 2/3 and 3/3 are to be taken > > > from v3 of the patchset I don't think you need to do anything further. > > > The important bit is for the other LSM folks to ACK the new hook; if I > > > don't see anything from them, either positive or negative, I'll merge > > > it towards the end of this week or early next. > > > > LSM folks, this is a reminder that if you want to object you've got > > until Monday morning to do so :) > > I'm unclear on whether a new v5 patchset was being posted -- I assume not? v4 addressed all the existing concerns/comments that were made. no new version is planned unless somebody else has any more comments. > > -- > James Morris > <jmorris@namei.org> > ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v4 1/3] [security] Add new hook to compare new mount to an existing mount 2021-03-18 19:12 ` Paul Moore 2021-03-18 19:21 ` Casey Schaufler 2021-03-18 22:49 ` James Morris @ 2021-03-22 18:56 ` Paul Moore 2 siblings, 0 replies; 24+ messages in thread From: Paul Moore @ 2021-03-22 18:56 UTC (permalink / raw) To: Linux Security Module list Cc: Anna Schumaker, Casey Schaufler, Trond Myklebust, Linux NFS Mailing List, SElinux list, Olga Kornievskaia On Thu, Mar 18, 2021 at 3:12 PM Paul Moore <paul@paul-moore.com> wrote: > On Mon, Mar 15, 2021 at 12:15 PM Paul Moore <paul@paul-moore.com> wrote: > > As long as we are clear that the latest draft of patch 1/3 is to be > > taken from the v4 patch{set} and patches 2/3 and 3/3 are to be taken > > from v3 of the patchset I don't think you need to do anything further. > > The important bit is for the other LSM folks to ACK the new hook; if I > > don't see anything from them, either positive or negative, I'll merge > > it towards the end of this week or early next. > > LSM folks, this is a reminder that if you want to object you've got > until Monday morning to do so :) Time is up, I just merged it into selinux/next ;) Thanks everyone! -- paul moore www.paul-moore.com ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2021-03-22 19:05 UTC | newest] Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 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
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.