| Message ID | 1443039368-55445-7-git-send-email-seth.forshee@canonical.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Seth Forshee <seth.forshee@canonical.com> writes: > 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. Casey can I get your ack on this patch? Or do you still have concerns? Eric > Signed-off-by: Seth Forshee <seth.forshee@canonical.com> > --- > security/smack/smack.h | 8 +++++++- > security/smack/smack_lsm.c | 41 ++++++++++++++++++++++++++++++----------- > 2 files changed, 37 insertions(+), 12 deletions(-) > > diff --git a/security/smack/smack.h b/security/smack/smack.h > index fff0c612bbb7..f95759015f29 100644 > --- a/security/smack/smack.h > +++ b/security/smack/smack.h > @@ -90,9 +90,15 @@ struct superblock_smack { > struct smack_known *smk_floor; > struct smack_known *smk_hat; > struct smack_known *smk_default; > - int smk_initialized; > + int smk_flags; > }; > > +/* > + * Superblock flags > + */ > +#define SMK_SB_INITIALIZED 0x01 > +#define SMK_SB_UNTRUSTED 0x02 > + > struct socket_smack { > struct smack_known *smk_out; /* outbound label */ > struct smack_known *smk_in; /* inbound label */ > diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c > index 996c88956438..621200f86b56 100644 > --- a/security/smack/smack_lsm.c > +++ b/security/smack/smack_lsm.c > @@ -521,7 +521,7 @@ static int smack_sb_alloc_security(struct super_block *sb) > sbsp->smk_floor = &smack_known_floor; > sbsp->smk_hat = &smack_known_hat; > /* > - * smk_initialized will be zero from kzalloc. > + * SMK_SB_INITIALIZED will be zero from kzalloc. > */ > sb->s_security = sbsp; > > @@ -738,10 +738,10 @@ static int smack_set_mnt_opts(struct super_block *sb, > int num_opts = opts->num_mnt_opts; > int transmute = 0; > > - if (sp->smk_initialized) > + if (sp->smk_flags & SMK_SB_INITIALIZED) > return 0; > > - sp->smk_initialized = 1; > + sp->smk_flags |= SMK_SB_INITIALIZED; > > for (i = 0; i < num_opts; i++) { > switch (opts->mnt_opts_flags[i]) { > @@ -793,6 +793,17 @@ static int smack_set_mnt_opts(struct super_block *sb, > skp = smk_of_current(); > sp->smk_root = skp; > sp->smk_default = skp; > + /* > + * For a handful of fs types with no user-controlled > + * backing store it's okay to trust security labels > + * in the filesystem. The rest are untrusted. > + */ > + if (sb->s_user_ns != &init_user_ns && > + sb->s_magic != SYSFS_MAGIC && sb->s_magic != TMPFS_MAGIC && > + sb->s_magic != RAMFS_MAGIC) { > + transmute = 1; > + sp->smk_flags |= SMK_SB_UNTRUSTED; > + } > } > > /* > @@ -1175,6 +1186,7 @@ static int smack_inode_rename(struct inode *old_inode, > */ > static int smack_inode_permission(struct inode *inode, int mask) > { > + struct superblock_smack *sbsp = inode->i_sb->s_security; > struct smk_audit_info ad; > int no_block = mask & MAY_NOT_BLOCK; > int rc; > @@ -1186,6 +1198,11 @@ static int smack_inode_permission(struct inode *inode, int mask) > if (mask == 0) > return 0; > > + if (sbsp->smk_flags & SMK_SB_UNTRUSTED) { > + if (smk_of_inode(inode) != sbsp->smk_root) > + return -EACCES; > + } > + > /* May be droppable after audit */ > if (no_block) > return -ECHILD; > @@ -3475,14 +3492,16 @@ static void smack_d_instantiate(struct dentry *opt_dentry, struct inode *inode) > if (rc >= 0) > transflag = SMK_INODE_TRANSMUTE; > } > - /* > - * Don't let the exec or mmap label be "*" or "@". > - */ > - skp = smk_fetch(XATTR_NAME_SMACKEXEC, inode, dp); > - if (IS_ERR(skp) || skp == &smack_known_star || > - skp == &smack_known_web) > - skp = NULL; > - isp->smk_task = skp; > + if (!(sbsp->smk_flags & SMK_SB_UNTRUSTED)) { > + /* > + * Don't let the exec or mmap label be "*" or "@". > + */ > + skp = smk_fetch(XATTR_NAME_SMACKEXEC, inode, dp); > + if (IS_ERR(skp) || skp == &smack_known_star || > + skp == &smack_known_web) > + skp = NULL; > + isp->smk_task = skp; > + } > > skp = smk_fetch(XATTR_NAME_SMACKMMAP, inode, dp); > if (IS_ERR(skp) || skp == &smack_known_star || -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 9/23/2015 1:16 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> Acked-by: Casey Schaufler <casey@schaufler-ca.com> > --- > security/smack/smack.h | 8 +++++++- > security/smack/smack_lsm.c | 41 ++++++++++++++++++++++++++++++----------- > 2 files changed, 37 insertions(+), 12 deletions(-) > > diff --git a/security/smack/smack.h b/security/smack/smack.h > index fff0c612bbb7..f95759015f29 100644 > --- a/security/smack/smack.h > +++ b/security/smack/smack.h > @@ -90,9 +90,15 @@ struct superblock_smack { > struct smack_known *smk_floor; > struct smack_known *smk_hat; > struct smack_known *smk_default; > - int smk_initialized; > + int smk_flags; > }; > > +/* > + * Superblock flags > + */ > +#define SMK_SB_INITIALIZED 0x01 > +#define SMK_SB_UNTRUSTED 0x02 > + > struct socket_smack { > struct smack_known *smk_out; /* outbound label */ > struct smack_known *smk_in; /* inbound label */ > diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c > index 996c88956438..621200f86b56 100644 > --- a/security/smack/smack_lsm.c > +++ b/security/smack/smack_lsm.c > @@ -521,7 +521,7 @@ static int smack_sb_alloc_security(struct super_block *sb) > sbsp->smk_floor = &smack_known_floor; > sbsp->smk_hat = &smack_known_hat; > /* > - * smk_initialized will be zero from kzalloc. > + * SMK_SB_INITIALIZED will be zero from kzalloc. > */ > sb->s_security = sbsp; > > @@ -738,10 +738,10 @@ static int smack_set_mnt_opts(struct super_block *sb, > int num_opts = opts->num_mnt_opts; > int transmute = 0; > > - if (sp->smk_initialized) > + if (sp->smk_flags & SMK_SB_INITIALIZED) > return 0; > > - sp->smk_initialized = 1; > + sp->smk_flags |= SMK_SB_INITIALIZED; > > for (i = 0; i < num_opts; i++) { > switch (opts->mnt_opts_flags[i]) { > @@ -793,6 +793,17 @@ static int smack_set_mnt_opts(struct super_block *sb, > skp = smk_of_current(); > sp->smk_root = skp; > sp->smk_default = skp; > + /* > + * For a handful of fs types with no user-controlled > + * backing store it's okay to trust security labels > + * in the filesystem. The rest are untrusted. > + */ > + if (sb->s_user_ns != &init_user_ns && > + sb->s_magic != SYSFS_MAGIC && sb->s_magic != TMPFS_MAGIC && > + sb->s_magic != RAMFS_MAGIC) { > + transmute = 1; > + sp->smk_flags |= SMK_SB_UNTRUSTED; > + } > } > > /* > @@ -1175,6 +1186,7 @@ static int smack_inode_rename(struct inode *old_inode, > */ > static int smack_inode_permission(struct inode *inode, int mask) > { > + struct superblock_smack *sbsp = inode->i_sb->s_security; > struct smk_audit_info ad; > int no_block = mask & MAY_NOT_BLOCK; > int rc; > @@ -1186,6 +1198,11 @@ static int smack_inode_permission(struct inode *inode, int mask) > if (mask == 0) > return 0; > > + if (sbsp->smk_flags & SMK_SB_UNTRUSTED) { > + if (smk_of_inode(inode) != sbsp->smk_root) > + return -EACCES; > + } > + > /* May be droppable after audit */ > if (no_block) > return -ECHILD; > @@ -3475,14 +3492,16 @@ static void smack_d_instantiate(struct dentry *opt_dentry, struct inode *inode) > if (rc >= 0) > transflag = SMK_INODE_TRANSMUTE; > } > - /* > - * Don't let the exec or mmap label be "*" or "@". > - */ > - skp = smk_fetch(XATTR_NAME_SMACKEXEC, inode, dp); > - if (IS_ERR(skp) || skp == &smack_known_star || > - skp == &smack_known_web) > - skp = NULL; > - isp->smk_task = skp; > + if (!(sbsp->smk_flags & SMK_SB_UNTRUSTED)) { > + /* > + * Don't let the exec or mmap label be "*" or "@". > + */ > + skp = smk_fetch(XATTR_NAME_SMACKEXEC, inode, dp); > + if (IS_ERR(skp) || skp == &smack_known_star || > + skp == &smack_known_web) > + skp = NULL; > + isp->smk_task = skp; > + } > > skp = smk_fetch(XATTR_NAME_SMACKMMAP, inode, dp); > if (IS_ERR(skp) || skp == &smack_known_star || -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Seth Forshee <seth.forshee@canonical.com> writes: > 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. Hmm. > > Signed-off-by: Seth Forshee <seth.forshee@canonical.com> > --- > security/smack/smack.h | 8 +++++++- > security/smack/smack_lsm.c | 41 ++++++++++++++++++++++++++++++----------- > 2 files changed, 37 insertions(+), 12 deletions(-) [snip] > @@ -3475,14 +3492,16 @@ static void smack_d_instantiate(struct dentry *opt_dentry, struct inode *inode) > if (rc >= 0) > transflag = SMK_INODE_TRANSMUTE; > } > - /* > - * Don't let the exec or mmap label be "*" or "@". > - */ > - skp = smk_fetch(XATTR_NAME_SMACKEXEC, inode, dp); > - if (IS_ERR(skp) || skp == &smack_known_star || > - skp == &smack_known_web) > - skp = NULL; > - isp->smk_task = skp; > + if (!(sbsp->smk_flags & SMK_SB_UNTRUSTED)) { > + /* > + * Don't let the exec or mmap label be "*" or "@". > + */ > + skp = smk_fetch(XATTR_NAME_SMACKEXEC, inode, dp); > + if (IS_ERR(skp) || skp == &smack_known_star || > + skp == &smack_known_web) > + skp = NULL; > + isp->smk_task = skp; I have to stop and ask is this really what we want to do? If I have permission I can get around this by explicitly setting the XATTR_NAME_SMACKEXEC. Perhaps that does not matter but I think it is siginficant. We don't do any filtering on the the smk_mmap label. Given the policy as I understand it is to only honor labels that match smk_root would we not be better off allowing anything to be set and filtering the labels at use when SMK_SB_UNTRUSTED is set? Having three different policies depending on the kind of label concerns me. > + } > > skp = smk_fetch(XATTR_NAME_SMACKMMAP, inode, dp); > if (IS_ERR(skp) || skp == &smack_known_star || Eric -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Sep 27, 2015 at 02:30:58PM -0500, Eric W. Biederman wrote: > Seth Forshee <seth.forshee@canonical.com> writes: > > > 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. > > Hmm. > > > > > Signed-off-by: Seth Forshee <seth.forshee@canonical.com> > > --- > > security/smack/smack.h | 8 +++++++- > > security/smack/smack_lsm.c | 41 ++++++++++++++++++++++++++++++----------- > > 2 files changed, 37 insertions(+), 12 deletions(-) > > [snip] > > > @@ -3475,14 +3492,16 @@ static void smack_d_instantiate(struct dentry *opt_dentry, struct inode *inode) > > if (rc >= 0) > > transflag = SMK_INODE_TRANSMUTE; > > } > > - /* > > - * Don't let the exec or mmap label be "*" or "@". > > - */ > > - skp = smk_fetch(XATTR_NAME_SMACKEXEC, inode, dp); > > - if (IS_ERR(skp) || skp == &smack_known_star || > > - skp == &smack_known_web) > > - skp = NULL; > > - isp->smk_task = skp; > > + if (!(sbsp->smk_flags & SMK_SB_UNTRUSTED)) { > > + /* > > + * Don't let the exec or mmap label be "*" or "@". > > + */ > > + skp = smk_fetch(XATTR_NAME_SMACKEXEC, inode, dp); > > + if (IS_ERR(skp) || skp == &smack_known_star || > > + skp == &smack_known_web) > > + skp = NULL; > > + isp->smk_task = skp; > > I have to stop and ask is this really what we want to do? > > If I have permission I can get around this by explicitly setting the > XATTR_NAME_SMACKEXEC. Perhaps that does not matter but I think it is > siginficant. > > We don't do any filtering on the the smk_mmap label. > > Given the policy as I understand it is to only honor labels that match > smk_root would we not be better off allowing anything to be set and > filtering the labels at use when SMK_SB_UNTRUSTED is set? > > Having three different policies depending on the kind of label concerns > me. The thinking behind the behavior was that since SMACK64EXEC is analagous to suid or file caps it should be handled similarly, i.e. ignore it in situations when the mount isn't trusted. You have a point about it being incongruous with how the other Smack labels are handled though. So let's say we read the label in an untrusted mount and handle it in bprm_set_creds. If the label matches smk_root, we allow the transition. I can't think of a problem with that, but I'd like to hear what Casey has to say. What if the label doesn't match? We have a couple of options, either refuse to exec or exec without changing the label. I'd still favor the latter, which would keep it consistent with what we do with suid or file caps. I'm okay with moving to something like this. Seems like we probably do need to handle smk_mmap as well. Good catch. Seth -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/security/smack/smack.h b/security/smack/smack.h index fff0c612bbb7..f95759015f29 100644 --- a/security/smack/smack.h +++ b/security/smack/smack.h @@ -90,9 +90,15 @@ struct superblock_smack { struct smack_known *smk_floor; struct smack_known *smk_hat; struct smack_known *smk_default; - int smk_initialized; + int smk_flags; }; +/* + * Superblock flags + */ +#define SMK_SB_INITIALIZED 0x01 +#define SMK_SB_UNTRUSTED 0x02 + struct socket_smack { struct smack_known *smk_out; /* outbound label */ struct smack_known *smk_in; /* inbound label */ diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c index 996c88956438..621200f86b56 100644 --- a/security/smack/smack_lsm.c +++ b/security/smack/smack_lsm.c @@ -521,7 +521,7 @@ static int smack_sb_alloc_security(struct super_block *sb) sbsp->smk_floor = &smack_known_floor; sbsp->smk_hat = &smack_known_hat; /* - * smk_initialized will be zero from kzalloc. + * SMK_SB_INITIALIZED will be zero from kzalloc. */ sb->s_security = sbsp; @@ -738,10 +738,10 @@ static int smack_set_mnt_opts(struct super_block *sb, int num_opts = opts->num_mnt_opts; int transmute = 0; - if (sp->smk_initialized) + if (sp->smk_flags & SMK_SB_INITIALIZED) return 0; - sp->smk_initialized = 1; + sp->smk_flags |= SMK_SB_INITIALIZED; for (i = 0; i < num_opts; i++) { switch (opts->mnt_opts_flags[i]) { @@ -793,6 +793,17 @@ static int smack_set_mnt_opts(struct super_block *sb, skp = smk_of_current(); sp->smk_root = skp; sp->smk_default = skp; + /* + * For a handful of fs types with no user-controlled + * backing store it's okay to trust security labels + * in the filesystem. The rest are untrusted. + */ + if (sb->s_user_ns != &init_user_ns && + sb->s_magic != SYSFS_MAGIC && sb->s_magic != TMPFS_MAGIC && + sb->s_magic != RAMFS_MAGIC) { + transmute = 1; + sp->smk_flags |= SMK_SB_UNTRUSTED; + } } /* @@ -1175,6 +1186,7 @@ static int smack_inode_rename(struct inode *old_inode, */ static int smack_inode_permission(struct inode *inode, int mask) { + struct superblock_smack *sbsp = inode->i_sb->s_security; struct smk_audit_info ad; int no_block = mask & MAY_NOT_BLOCK; int rc; @@ -1186,6 +1198,11 @@ static int smack_inode_permission(struct inode *inode, int mask) if (mask == 0) return 0; + if (sbsp->smk_flags & SMK_SB_UNTRUSTED) { + if (smk_of_inode(inode) != sbsp->smk_root) + return -EACCES; + } + /* May be droppable after audit */ if (no_block) return -ECHILD; @@ -3475,14 +3492,16 @@ static void smack_d_instantiate(struct dentry *opt_dentry, struct inode *inode) if (rc >= 0) transflag = SMK_INODE_TRANSMUTE; } - /* - * Don't let the exec or mmap label be "*" or "@". - */ - skp = smk_fetch(XATTR_NAME_SMACKEXEC, inode, dp); - if (IS_ERR(skp) || skp == &smack_known_star || - skp == &smack_known_web) - skp = NULL; - isp->smk_task = skp; + if (!(sbsp->smk_flags & SMK_SB_UNTRUSTED)) { + /* + * Don't let the exec or mmap label be "*" or "@". + */ + skp = smk_fetch(XATTR_NAME_SMACKEXEC, inode, dp); + if (IS_ERR(skp) || skp == &smack_known_star || + skp == &smack_known_web) + skp = NULL; + isp->smk_task = skp; + } skp = smk_fetch(XATTR_NAME_SMACKMMAP, inode, dp); if (IS_ERR(skp) || skp == &smack_known_star ||
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> --- security/smack/smack.h | 8 +++++++- security/smack/smack_lsm.c | 41 ++++++++++++++++++++++++++++++----------- 2 files changed, 37 insertions(+), 12 deletions(-)