Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1226983

Re: [PATCH v3 6/7] Smack: Add support for unprivileged mounts from user namespaces

From Seth Forshee <seth.forshee@canonical.com>
Newsgroups linux.kernel
Subject Re: [PATCH v3 6/7] Smack: Add support for unprivileged mounts from user namespaces
Date 2015-09-17 15:00 +0200
Message-ID <q9GX9-40N-19@gated-at.bofh.it> (permalink)
References <q9rbI-6jD-9@gated-at.bofh.it> <q9rbJ-6jD-33@gated-at.bofh.it> <q9rEJ-6RI-3@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Wed, Sep 16, 2015 at 01:33:50PM -0700, Casey Schaufler wrote:
> On 9/16/2015 1:02 PM, Seth Forshee wrote:
> > Security labels from unprivileged mounts cannot be trusted.
> > Ideally for these mounts we would assign the objects in the
> > filesystem the same label as the inode for the backing device
> > passed to mount. Unfortunately it's currently impossible to
> > determine which inode this is from the LSM mount hooks, so we
> > settle for the label of the process doing the mount.
> >
> > This label is assigned to s_root, and also to smk_default to
> > ensure that new inodes receive this label. The transmute property
> > is also set on s_root to make this behavior more explicit, even
> > though it is technically not necessary.
> >
> > If a filesystem has existing security labels, access to inodes is
> > permitted if the label is the same as smk_root, otherwise access
> > is denied. The SMACK64EXEC xattr is completely ignored.
> >
> > Explicit setting of security labels continues to require
> > CAP_MAC_ADMIN in init_user_ns.
> >
> > Altogether, this ensures that filesystem objects are not
> > accessible to subjects which cannot already access the backing
> > store, that MAC is not violated for any objects in the fileystem
> > which are already labeled, and that a user cannot use an
> > unprivileged mount to gain elevated MAC privileges.
> >
> > sysfs, tmpfs, and ramfs are already mountable from user
> > namespaces and support security labels. We can't rule out the
> > possibility that these filesystems may already be used in mounts
> > from user namespaces with security lables set from the init
> > namespace, so failing to trust lables in these filesystems may
> > introduce regressions. It is safe to trust labels from these
> > filesystems, since the unprivileged user does not control the
> > backing store and thus cannot supply security labels, so an
> > explicit exception is made to trust labels from these
> > filesystems.
> >
> > Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
> 
> One coding comment below, otherwise looking good.
> 
> > ---
> >  security/smack/smack.h     |  6 ++++++
> >  security/smack/smack_lsm.c | 35 +++++++++++++++++++++++++++--------
> >  2 files changed, 33 insertions(+), 8 deletions(-)
> >
> > diff --git a/security/smack/smack.h b/security/smack/smack.h
> > index fff0c612bbb7..070223960a2c 100644
> > --- a/security/smack/smack.h
> > +++ b/security/smack/smack.h
> > @@ -91,8 +91,14 @@ struct superblock_smack {
> >  	struct smack_known	*smk_hat;
> >  	struct smack_known	*smk_default;
> >  	int			smk_initialized;
> > +	int			smk_flags;
> 
> How about deleting smk_initialized and using a bit
> in smk_flags. A whole int for each seems excessive.
> The smk_initialized field is only used in two places,
> both in smack_set_mnt_opts.

Sure, I can do that.

Thanks,
Seth
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH v3 0/7] Initial support for user namespace owned mounts Seth Forshee <seth.forshee@canonical.com> - 2015-09-16 22:10 +0200
  [PATCH v3 1/7] fs: Add user namesapace member to struct super_block Seth Forshee <seth.forshee@canonical.com> - 2015-09-16 22:10 +0200
  [PATCH v3 6/7] Smack: Add support for unprivileged mounts from user namespaces Seth Forshee <seth.forshee@canonical.com> - 2015-09-16 22:10 +0200
    Re: [PATCH v3 6/7] Smack: Add support for unprivileged mounts from  user namespaces Casey Schaufler <casey@schaufler-ca.com> - 2015-09-16 22:40 +0200
      Re: [PATCH v3 6/7] Smack: Add support for unprivileged mounts from  user namespaces Seth Forshee <seth.forshee@canonical.com> - 2015-09-17 15:00 +0200
  [PATCH v3 2/7] userns: Simpilify MNT_NODEV handling. Seth Forshee <seth.forshee@canonical.com> - 2015-09-16 22:10 +0200
    Re: [PATCH v3 2/7] userns: Simpilify MNT_NODEV handling. Andy Lutomirski <luto@amacapital.net> - 2015-09-17 02:30 +0200
      Re: [PATCH v3 2/7] userns: Simpilify MNT_NODEV handling. ebiederm@xmission.com (Eric W. Biederman) - 2015-09-17 03:10 +0200
        Re: [PATCH v3 2/7] userns: Simpilify MNT_NODEV handling. Andy Lutomirski <luto@amacapital.net> - 2015-09-18 00:20 +0200
  [PATCH v3 3/7] fs: Verify access of user towards block device file when mounting Seth Forshee <seth.forshee@canonical.com> - 2015-09-16 22:10 +0200
  [PATCH v3 7/7] selinux: Add support for unprivileged mounts from user namespaces Seth Forshee <seth.forshee@canonical.com> - 2015-09-16 22:10 +0200

csiph-web