* [PATCH v3 3/7] mtd: Check permissions towards mtd block device inode when mounting
From: Seth Forshee @ 2015-11-17 16:39 UTC (permalink / raw)
To: Eric W. Biederman, David Woodhouse, Brian Norris
Cc: Alexander Viro, Serge Hallyn, Andy Lutomirski, linux-kernel,
linux-bcache, dm-devel, linux-raid, linux-mtd, linux-fsdevel,
linux-security-module, selinux, Seth Forshee
In-Reply-To: <1447778351-118699-1-git-send-email-seth.forshee@canonical.com>
Unprivileged users should not be able to mount mtd block devices
when they lack sufficient privileges towards the block device
inode. Update mount_mtd() to validate that the user has the
required access to the inode at the specified path. The check
will be skipped for CAP_SYS_ADMIN, so privileged mounts will
continue working as before.
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
---
drivers/mtd/mtdsuper.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/mtdsuper.c b/drivers/mtd/mtdsuper.c
index b5b60e1af31c..5d7e7705fed8 100644
--- a/drivers/mtd/mtdsuper.c
+++ b/drivers/mtd/mtdsuper.c
@@ -125,6 +125,7 @@ struct dentry *mount_mtd(struct file_system_type *fs_type, int flags,
#ifdef CONFIG_BLOCK
struct block_device *bdev;
int ret, major;
+ int perm;
#endif
int mtdnr;
@@ -176,7 +177,10 @@ struct dentry *mount_mtd(struct file_system_type *fs_type, int flags,
/* try the old way - the hack where we allowed users to mount
* /dev/mtdblock$(n) but didn't actually _use_ the blockdev
*/
- bdev = lookup_bdev(dev_name, 0);
+ perm = MAY_READ;
+ if (!(flags & MS_RDONLY))
+ perm |= MAY_WRITE;
+ bdev = lookup_bdev(dev_name, perm);
if (IS_ERR(bdev)) {
ret = PTR_ERR(bdev);
pr_debug("MTDSB: lookup_bdev() returned %d\n", ret);
--
1.9.1
^ permalink raw reply related
* [PATCH v3 4/7] fs: Treat foreign mounts as nosuid
From: Seth Forshee @ 2015-11-17 16:39 UTC (permalink / raw)
To: Eric W. Biederman, Alexander Viro, Serge Hallyn, James Morris,
Serge E. Hallyn, Paul Moore, Stephen Smalley, Eric Paris
Cc: Andy Lutomirski, linux-kernel, linux-bcache, dm-devel, linux-raid,
linux-mtd, linux-fsdevel, linux-security-module, selinux,
Seth Forshee
In-Reply-To: <1447778351-118699-1-git-send-email-seth.forshee@canonical.com>
From: Andy Lutomirski <luto@amacapital.net>
If a process gets access to a mount from a different user
namespace, that process should not be able to take advantage of
setuid files or selinux entrypoints from that filesystem. Prevent
this by treating mounts from other mount namespaces and those not
owned by current_user_ns() or an ancestor as nosuid.
This will make it safer to allow more complex filesystems to be
mounted in non-root user namespaces.
This does not remove the need for MNT_LOCK_NOSUID. The setuid,
setgid, and file capability bits can no longer be abused if code in
a user namespace were to clear nosuid on an untrusted filesystem,
but this patch, by itself, is insufficient to protect the system
from abuse of files that, when execed, would increase MAC privilege.
As a more concrete explanation, any task that can manipulate a
vfsmount associated with a given user namespace already has
capabilities in that namespace and all of its descendents. If they
can cause a malicious setuid, setgid, or file-caps executable to
appear in that mount, then that executable will only allow them to
elevate privileges in exactly the set of namespaces in which they
are already privileges.
On the other hand, if they can cause a malicious executable to
appear with a dangerous MAC label, running it could change the
caller's security context in a way that should not have been
possible, even inside the namespace in which the task is confined.
As a hardening measure, this would have made CVE-2014-5207 much
more difficult to exploit.
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
---
fs/exec.c | 2 +-
fs/namespace.c | 13 +++++++++++++
include/linux/mount.h | 1 +
security/commoncap.c | 2 +-
security/selinux/hooks.c | 2 +-
5 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/fs/exec.c b/fs/exec.c
index b06623a9347f..ea7311d72cc3 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1295,7 +1295,7 @@ static void bprm_fill_uid(struct linux_binprm *bprm)
bprm->cred->euid = current_euid();
bprm->cred->egid = current_egid();
- if (bprm->file->f_path.mnt->mnt_flags & MNT_NOSUID)
+ if (!mnt_may_suid(bprm->file->f_path.mnt))
return;
if (task_no_new_privs(current))
diff --git a/fs/namespace.c b/fs/namespace.c
index da70f7c4ece1..2101ce7b96ab 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -3276,6 +3276,19 @@ found:
return visible;
}
+bool mnt_may_suid(struct vfsmount *mnt)
+{
+ /*
+ * Foreign mounts (accessed via fchdir or through /proc
+ * symlinks) are always treated as if they are nosuid. This
+ * prevents namespaces from trusting potentially unsafe
+ * suid/sgid bits, file caps, or security labels that originate
+ * in other namespaces.
+ */
+ return !(mnt->mnt_flags & MNT_NOSUID) && check_mnt(real_mount(mnt)) &&
+ in_userns(current_user_ns(), mnt->mnt_sb->s_user_ns);
+}
+
static struct ns_common *mntns_get(struct task_struct *task)
{
struct ns_common *ns = NULL;
diff --git a/include/linux/mount.h b/include/linux/mount.h
index f822c3c11377..54a594d49733 100644
--- a/include/linux/mount.h
+++ b/include/linux/mount.h
@@ -81,6 +81,7 @@ extern void mntput(struct vfsmount *mnt);
extern struct vfsmount *mntget(struct vfsmount *mnt);
extern struct vfsmount *mnt_clone_internal(struct path *path);
extern int __mnt_is_readonly(struct vfsmount *mnt);
+extern bool mnt_may_suid(struct vfsmount *mnt);
struct path;
extern struct vfsmount *clone_private_mount(struct path *path);
diff --git a/security/commoncap.c b/security/commoncap.c
index 400aa224b491..6243aef5860e 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -448,7 +448,7 @@ static int get_file_caps(struct linux_binprm *bprm, bool *effective, bool *has_c
if (!file_caps_enabled)
return 0;
- if (bprm->file->f_path.mnt->mnt_flags & MNT_NOSUID)
+ if (!mnt_may_suid(bprm->file->f_path.mnt))
return 0;
if (!in_userns(current_user_ns(), bprm->file->f_path.mnt->mnt_sb->s_user_ns))
return 0;
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index e4369d86e588..de05207eb665 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -2171,7 +2171,7 @@ static int check_nnp_nosuid(const struct linux_binprm *bprm,
const struct task_security_struct *new_tsec)
{
int nnp = (bprm->unsafe & LSM_UNSAFE_NO_NEW_PRIVS);
- int nosuid = (bprm->file->f_path.mnt->mnt_flags & MNT_NOSUID);
+ int nosuid = !mnt_may_suid(bprm->file->f_path.mnt);
int rc;
if (!nnp && !nosuid)
--
1.9.1
^ permalink raw reply related
* [PATCH v3 5/7] selinux: Add support for unprivileged mounts from user namespaces
From: Seth Forshee @ 2015-11-17 16:39 UTC (permalink / raw)
To: Eric W. Biederman, Paul Moore, Stephen Smalley, Eric Paris
Cc: Alexander Viro, Serge Hallyn, Andy Lutomirski, linux-kernel,
linux-bcache, dm-devel, linux-raid, linux-mtd, linux-fsdevel,
linux-security-module, selinux, Seth Forshee, James Morris,
Serge E. Hallyn
In-Reply-To: <1447778351-118699-1-git-send-email-seth.forshee@canonical.com>
Security labels from unprivileged mounts in user namespaces must
be ignored. Force superblocks from user namespaces whose labeling
behavior is to use xattrs to use mountpoint labeling instead.
For the mountpoint label, default to converting the current task
context into a form suitable for file objects, but also allow the
policy writer to specify a different label through policy
transition rules.
Pieced together from code snippets provided by Stephen Smalley.
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Stephen Smalley <sds@tycho.nsa.gov>
---
security/selinux/hooks.c | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index de05207eb665..09be1dc21e58 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -756,6 +756,28 @@ static int selinux_set_mnt_opts(struct super_block *sb,
goto out;
}
}
+
+ /*
+ * If this is a user namespace mount, no contexts are allowed
+ * on the command line and security labels must be ignored.
+ */
+ if (sb->s_user_ns != &init_user_ns) {
+ if (context_sid || fscontext_sid || rootcontext_sid ||
+ defcontext_sid) {
+ rc = -EACCES;
+ goto out;
+ }
+ if (sbsec->behavior == SECURITY_FS_USE_XATTR) {
+ sbsec->behavior = SECURITY_FS_USE_MNTPOINT;
+ rc = security_transition_sid(current_sid(), current_sid(),
+ SECCLASS_FILE, NULL,
+ &sbsec->mntpoint_sid);
+ if (rc)
+ goto out;
+ }
+ goto out_set_opts;
+ }
+
/* sets the context of the superblock for the fs being mounted. */
if (fscontext_sid) {
rc = may_context_mount_sb_relabel(fscontext_sid, sbsec, cred);
@@ -824,6 +846,7 @@ static int selinux_set_mnt_opts(struct super_block *sb,
sbsec->def_sid = defcontext_sid;
}
+out_set_opts:
rc = sb_finish_set_opts(sb);
out:
mutex_unlock(&sbsec->lock);
--
1.9.1
^ permalink raw reply related
* [PATCH v3 6/7] userns: Replace in_userns with current_in_userns
From: Seth Forshee @ 2015-11-17 16:39 UTC (permalink / raw)
To: Eric W. Biederman, Alexander Viro, Serge Hallyn, James Morris,
Serge E. Hallyn
Cc: Andy Lutomirski, linux-kernel, linux-bcache, dm-devel, linux-raid,
linux-mtd, linux-fsdevel, linux-security-module, selinux,
Seth Forshee
In-Reply-To: <1447778351-118699-1-git-send-email-seth.forshee@canonical.com>
All current callers of in_userns pass current_user_ns as the
first argument. Simplify by replacing in_userns with
current_in_userns which checks whether current_user_ns is in the
namespace supplied as an argument.
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
---
fs/namespace.c | 2 +-
include/linux/user_namespace.h | 6 ++----
kernel/user_namespace.c | 6 +++---
security/commoncap.c | 2 +-
4 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/fs/namespace.c b/fs/namespace.c
index 2101ce7b96ab..18fc58760aec 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -3286,7 +3286,7 @@ bool mnt_may_suid(struct vfsmount *mnt)
* in other namespaces.
*/
return !(mnt->mnt_flags & MNT_NOSUID) && check_mnt(real_mount(mnt)) &&
- in_userns(current_user_ns(), mnt->mnt_sb->s_user_ns);
+ current_in_userns(mnt->mnt_sb->s_user_ns);
}
static struct ns_common *mntns_get(struct task_struct *task)
diff --git a/include/linux/user_namespace.h b/include/linux/user_namespace.h
index a43faa727124..9217169c64cb 100644
--- a/include/linux/user_namespace.h
+++ b/include/linux/user_namespace.h
@@ -72,8 +72,7 @@ extern ssize_t proc_projid_map_write(struct file *, const char __user *, size_t,
extern ssize_t proc_setgroups_write(struct file *, const char __user *, size_t, loff_t *);
extern int proc_setgroups_show(struct seq_file *m, void *v);
extern bool userns_may_setgroups(const struct user_namespace *ns);
-extern bool in_userns(const struct user_namespace *ns,
- const struct user_namespace *target_ns);
+extern bool current_in_userns(const struct user_namespace *target_ns);
#else
static inline struct user_namespace *get_user_ns(struct user_namespace *ns)
@@ -103,8 +102,7 @@ static inline bool userns_may_setgroups(const struct user_namespace *ns)
return true;
}
-static inline bool in_userns(const struct user_namespace *ns,
- const struct user_namespace *target_ns)
+static inline bool current_in_userns(const struct user_namespace *target_ns)
{
return true;
}
diff --git a/kernel/user_namespace.c b/kernel/user_namespace.c
index 69fbc377357b..5960edc7e644 100644
--- a/kernel/user_namespace.c
+++ b/kernel/user_namespace.c
@@ -949,10 +949,10 @@ bool userns_may_setgroups(const struct user_namespace *ns)
* Returns true if @ns is the same namespace as or a descendant of
* @target_ns.
*/
-bool in_userns(const struct user_namespace *ns,
- const struct user_namespace *target_ns)
+bool current_in_userns(const struct user_namespace *target_ns)
{
- for (; ns; ns = ns->parent) {
+ struct user_namespace *ns;
+ for (ns = current_user_ns(); ns; ns = ns->parent) {
if (ns == target_ns)
return true;
}
diff --git a/security/commoncap.c b/security/commoncap.c
index 6243aef5860e..2119421613f6 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -450,7 +450,7 @@ static int get_file_caps(struct linux_binprm *bprm, bool *effective, bool *has_c
if (!mnt_may_suid(bprm->file->f_path.mnt))
return 0;
- if (!in_userns(current_user_ns(), bprm->file->f_path.mnt->mnt_sb->s_user_ns))
+ if (!current_in_userns(bprm->file->f_path.mnt->mnt_sb->s_user_ns))
return 0;
rc = get_vfs_caps_from_disk(bprm->file->f_path.dentry, &vcaps);
--
1.9.1
^ permalink raw reply related
* [PATCH v3 7/7] Smack: Handle labels consistently in untrusted mounts
From: Seth Forshee @ 2015-11-17 16:39 UTC (permalink / raw)
To: Eric W. Biederman, Casey Schaufler
Cc: Alexander Viro, Serge Hallyn, Andy Lutomirski, linux-kernel,
linux-bcache, dm-devel, linux-raid, linux-mtd, linux-fsdevel,
linux-security-module, selinux, Seth Forshee, James Morris,
Serge E. Hallyn
In-Reply-To: <1447778351-118699-1-git-send-email-seth.forshee@canonical.com>
The SMACK64, SMACK64EXEC, and SMACK64MMAP labels are all handled
differently in untrusted mounts. This is confusing and
potentically problematic. Change this to handle them all the same
way that SMACK64 is currently handled; that is, read the label
from disk and check it at use time. For SMACK64 and SMACK64MMAP
access is denied if the label does not match smk_root. To be
consistent with suid, a SMACK64EXEC label which does not match
smk_root will still allow execution of the file but will not run
with the label supplied in the xattr.
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
---
security/smack/smack_lsm.c | 29 +++++++++++++++++++----------
1 file changed, 19 insertions(+), 10 deletions(-)
diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
index 621200f86b56..9b7ff781df9a 100644
--- a/security/smack/smack_lsm.c
+++ b/security/smack/smack_lsm.c
@@ -891,6 +891,7 @@ static int smack_bprm_set_creds(struct linux_binprm *bprm)
struct inode *inode = file_inode(bprm->file);
struct task_smack *bsp = bprm->cred->security;
struct inode_smack *isp;
+ struct superblock_smack *sbsp;
int rc;
if (bprm->cred_prepared)
@@ -900,6 +901,11 @@ static int smack_bprm_set_creds(struct linux_binprm *bprm)
if (isp->smk_task == NULL || isp->smk_task == bsp->smk_task)
return 0;
+ sbsp = inode->i_sb->s_security;
+ if ((sbsp->smk_flags & SMK_SB_UNTRUSTED) &&
+ isp->smk_task != sbsp->smk_root)
+ return 0;
+
if (bprm->unsafe & (LSM_UNSAFE_PTRACE | LSM_UNSAFE_PTRACE_CAP)) {
struct task_struct *tracer;
rc = 0;
@@ -1703,6 +1709,7 @@ static int smack_mmap_file(struct file *file,
struct task_smack *tsp;
struct smack_known *okp;
struct inode_smack *isp;
+ struct superblock_smack *sbsp;
int may;
int mmay;
int tmay;
@@ -1714,6 +1721,10 @@ static int smack_mmap_file(struct file *file,
isp = file_inode(file)->i_security;
if (isp->smk_mmap == NULL)
return 0;
+ sbsp = file_inode(file)->i_sb->s_security;
+ if (sbsp->smk_flags & SMK_SB_UNTRUSTED &&
+ isp->smk_mmap != sbsp->smk_root)
+ return -EACCES;
mkp = isp->smk_mmap;
tsp = current_security();
@@ -3492,16 +3503,14 @@ static void smack_d_instantiate(struct dentry *opt_dentry, struct inode *inode)
if (rc >= 0)
transflag = SMK_INODE_TRANSMUTE;
}
- 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;
- }
+ /*
+ * 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 ||
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v3 0/7] User namespace mount updates
From: Al Viro @ 2015-11-17 17:05 UTC (permalink / raw)
To: Seth Forshee
Cc: Eric W. Biederman, linux-bcache, dm-devel, linux-raid, linux-mtd,
linux-fsdevel, linux-security-module, selinux, Serge Hallyn,
Andy Lutomirski, linux-kernel
In-Reply-To: <1447778351-118699-1-git-send-email-seth.forshee@canonical.com>
On Tue, Nov 17, 2015 at 10:39:03AM -0600, Seth Forshee wrote:
> Hi Eric,
>
> Here's another update to my patches for user namespace mounts, based on
> your for-testing branch. These patches add safeguards necessary to allow
> unprivileged mounts and update SELinux and Smack to safely handle
> device-backed mounts from unprivileged users.
>
> The v2 posting received very little in the way of feedback, so changes
> are minimal. I've made a trivial style change to the Smack changes at
> Casey's request, and I've added Stephen's ack for the SELinux changes.
Would you mind explaining which filesystem types do you plan to allow?
SELinux and the rest of Linux S&M bunch do fuck-all for attacks via
handcrafted fs image fed to the code in fs driver that does not expect
a given kind of inconsistencies.
As it is, validation of on-disk metadata is not particularly strong;
what's more, protection against concurrent malicious *changes* of
fs image (via direct writes by root) is simply inexistent.
So what is that about?
^ permalink raw reply
* Re: [PATCH v3 0/7] User namespace mount updates
From: Seth Forshee @ 2015-11-17 17:25 UTC (permalink / raw)
To: Al Viro
Cc: Eric W. Biederman, linux-bcache, dm-devel, linux-raid, linux-mtd,
linux-fsdevel, linux-security-module, selinux, Serge Hallyn,
Andy Lutomirski, linux-kernel, Theodore Ts'o
In-Reply-To: <20151117170556.GV22011@ZenIV.linux.org.uk>
On Tue, Nov 17, 2015 at 05:05:56PM +0000, Al Viro wrote:
> On Tue, Nov 17, 2015 at 10:39:03AM -0600, Seth Forshee wrote:
> > Hi Eric,
> >
> > Here's another update to my patches for user namespace mounts, based on
> > your for-testing branch. These patches add safeguards necessary to allow
> > unprivileged mounts and update SELinux and Smack to safely handle
> > device-backed mounts from unprivileged users.
> >
> > The v2 posting received very little in the way of feedback, so changes
> > are minimal. I've made a trivial style change to the Smack changes at
> > Casey's request, and I've added Stephen's ack for the SELinux changes.
>
> Would you mind explaining which filesystem types do you plan to allow?
> SELinux and the rest of Linux S&M bunch do fuck-all for attacks via
> handcrafted fs image fed to the code in fs driver that does not expect
> a given kind of inconsistencies.
>
> As it is, validation of on-disk metadata is not particularly strong;
> what's more, protection against concurrent malicious *changes* of
> fs image (via direct writes by root) is simply inexistent.
>
> So what is that about?
The first target is fuse, which won't be vulnerable to those attacks.
Shortly after that I plan to follow with support for ext4. I've been
fuzzing ext4 for a while now and it has held up well, and I'm currently
working on hand-crafted attacks. Ted has commented privately (to others,
not to me personally) that he will fix bugs for such attacks, though I
haven't seen any public comments to that effect.
Seth
^ permalink raw reply
* Re: [PATCH v3 0/7] User namespace mount updates
From: Serge E. Hallyn @ 2015-11-17 17:45 UTC (permalink / raw)
To: Seth Forshee
Cc: Al Viro, Eric W. Biederman, linux-bcache, dm-devel, linux-raid,
linux-mtd, linux-fsdevel, linux-security-module, selinux,
Serge Hallyn, Andy Lutomirski, linux-kernel, Theodore Ts'o
In-Reply-To: <20151117172551.GA108807@ubuntu-hedt>
On Tue, Nov 17, 2015 at 11:25:51AM -0600, Seth Forshee wrote:
> On Tue, Nov 17, 2015 at 05:05:56PM +0000, Al Viro wrote:
> > On Tue, Nov 17, 2015 at 10:39:03AM -0600, Seth Forshee wrote:
> > > Hi Eric,
> > >
> > > Here's another update to my patches for user namespace mounts, based on
> > > your for-testing branch. These patches add safeguards necessary to allow
> > > unprivileged mounts and update SELinux and Smack to safely handle
> > > device-backed mounts from unprivileged users.
> > >
> > > The v2 posting received very little in the way of feedback, so changes
> > > are minimal. I've made a trivial style change to the Smack changes at
> > > Casey's request, and I've added Stephen's ack for the SELinux changes.
> >
> > Would you mind explaining which filesystem types do you plan to allow?
> > SELinux and the rest of Linux S&M bunch do fuck-all for attacks via
> > handcrafted fs image fed to the code in fs driver that does not expect
> > a given kind of inconsistencies.
> >
> > As it is, validation of on-disk metadata is not particularly strong;
> > what's more, protection against concurrent malicious *changes* of
> > fs image (via direct writes by root) is simply inexistent.
> >
> > So what is that about?
>
> The first target is fuse, which won't be vulnerable to those attacks.
>
> Shortly after that I plan to follow with support for ext4. I've been
> fuzzing ext4 for a while now and it has held up well, and I'm currently
> working on hand-crafted attacks. Ted has commented privately (to others,
> not to me personally) that he will fix bugs for such attacks, though I
> haven't seen any public comments to that effect.
Hi,
Not privately, but during the 2014 kernel summit. The only documentation
of it I've seen is at the bottom of Paul's summary at
http://lwn.net/Articles/609376/ .
^ permalink raw reply
* Re: [PATCH v3 0/7] User namespace mount updates
From: Al Viro @ 2015-11-17 17:55 UTC (permalink / raw)
To: Seth Forshee
Cc: Eric W. Biederman, linux-bcache, dm-devel, linux-raid, linux-mtd,
linux-fsdevel, linux-security-module, selinux, Serge Hallyn,
Andy Lutomirski, linux-kernel, Theodore Ts'o
In-Reply-To: <20151117172551.GA108807@ubuntu-hedt>
On Tue, Nov 17, 2015 at 11:25:51AM -0600, Seth Forshee wrote:
> Shortly after that I plan to follow with support for ext4. I've been
> fuzzing ext4 for a while now and it has held up well, and I'm currently
> working on hand-crafted attacks. Ted has commented privately (to others,
> not to me personally) that he will fix bugs for such attacks, though I
> haven't seen any public comments to that effect.
_Static_ attacks, or change-image-under-mounted-fs attacks?
^ permalink raw reply
* Re: [PATCH v3 7/7] Smack: Handle labels consistently in untrusted mounts
From: Casey Schaufler @ 2015-11-17 18:24 UTC (permalink / raw)
To: Seth Forshee, Eric W. Biederman
Cc: Serge Hallyn, James Morris, linux-security-module, dm-devel,
linux-kernel, linux-raid, linux-bcache, linux-mtd, Alexander Viro,
selinux, linux-fsdevel, Andy Lutomirski, Serge E. Hallyn
In-Reply-To: <1447778351-118699-8-git-send-email-seth.forshee@canonical.com>
On 11/17/2015 8:39 AM, Seth Forshee wrote:
> The SMACK64, SMACK64EXEC, and SMACK64MMAP labels are all handled
> differently in untrusted mounts. This is confusing and
> potentically problematic. Change this to handle them all the same
> way that SMACK64 is currently handled; that is, read the label
> from disk and check it at use time. For SMACK64 and SMACK64MMAP
> access is denied if the label does not match smk_root. To be
> consistent with suid, a SMACK64EXEC label which does not match
> smk_root will still allow execution of the file but will not run
> with the label supplied in the xattr.
>
> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Casey Schaufler <casey@schaufler-ca.com>
> ---
> security/smack/smack_lsm.c | 29 +++++++++++++++++++----------
> 1 file changed, 19 insertions(+), 10 deletions(-)
>
> diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
> index 621200f86b56..9b7ff781df9a 100644
> --- a/security/smack/smack_lsm.c
> +++ b/security/smack/smack_lsm.c
> @@ -891,6 +891,7 @@ static int smack_bprm_set_creds(struct linux_binprm *bprm)
> struct inode *inode = file_inode(bprm->file);
> struct task_smack *bsp = bprm->cred->security;
> struct inode_smack *isp;
> + struct superblock_smack *sbsp;
> int rc;
>
> if (bprm->cred_prepared)
> @@ -900,6 +901,11 @@ static int smack_bprm_set_creds(struct linux_binprm *bprm)
> if (isp->smk_task == NULL || isp->smk_task == bsp->smk_task)
> return 0;
>
> + sbsp = inode->i_sb->s_security;
> + if ((sbsp->smk_flags & SMK_SB_UNTRUSTED) &&
> + isp->smk_task != sbsp->smk_root)
> + return 0;
> +
> if (bprm->unsafe & (LSM_UNSAFE_PTRACE | LSM_UNSAFE_PTRACE_CAP)) {
> struct task_struct *tracer;
> rc = 0;
> @@ -1703,6 +1709,7 @@ static int smack_mmap_file(struct file *file,
> struct task_smack *tsp;
> struct smack_known *okp;
> struct inode_smack *isp;
> + struct superblock_smack *sbsp;
> int may;
> int mmay;
> int tmay;
> @@ -1714,6 +1721,10 @@ static int smack_mmap_file(struct file *file,
> isp = file_inode(file)->i_security;
> if (isp->smk_mmap == NULL)
> return 0;
> + sbsp = file_inode(file)->i_sb->s_security;
> + if (sbsp->smk_flags & SMK_SB_UNTRUSTED &&
> + isp->smk_mmap != sbsp->smk_root)
> + return -EACCES;
> mkp = isp->smk_mmap;
>
> tsp = current_security();
> @@ -3492,16 +3503,14 @@ static void smack_d_instantiate(struct dentry *opt_dentry, struct inode *inode)
> if (rc >= 0)
> transflag = SMK_INODE_TRANSMUTE;
> }
> - 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;
> - }
> + /*
> + * 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 ||
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* Re: [PATCH v3 0/7] User namespace mount updates
From: Seth Forshee @ 2015-11-17 18:34 UTC (permalink / raw)
To: Al Viro
Cc: Eric W. Biederman, linux-bcache, dm-devel, linux-raid, linux-mtd,
linux-fsdevel, linux-security-module, selinux, Serge Hallyn,
Andy Lutomirski, linux-kernel, Theodore Ts'o
In-Reply-To: <20151117175506.GW22011@ZenIV.linux.org.uk>
On Tue, Nov 17, 2015 at 05:55:06PM +0000, Al Viro wrote:
> On Tue, Nov 17, 2015 at 11:25:51AM -0600, Seth Forshee wrote:
>
> > Shortly after that I plan to follow with support for ext4. I've been
> > fuzzing ext4 for a while now and it has held up well, and I'm currently
> > working on hand-crafted attacks. Ted has commented privately (to others,
> > not to me personally) that he will fix bugs for such attacks, though I
> > haven't seen any public comments to that effect.
>
> _Static_ attacks, or change-image-under-mounted-fs attacks?
Right now only static attacks, change-image-under-mounted-fs attacks
will be next.
^ permalink raw reply
* Re: [PATCH v3 0/7] User namespace mount updates
From: Austin S Hemmelgarn @ 2015-11-17 19:02 UTC (permalink / raw)
To: Al Viro, Seth Forshee
Cc: Eric W. Biederman, linux-bcache, dm-devel, linux-raid, linux-mtd,
linux-fsdevel, linux-security-module, selinux, Serge Hallyn,
Andy Lutomirski, linux-kernel, Theodore Ts'o
In-Reply-To: <20151117175506.GW22011@ZenIV.linux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1886 bytes --]
On 2015-11-17 12:55, Al Viro wrote:
> On Tue, Nov 17, 2015 at 11:25:51AM -0600, Seth Forshee wrote:
>
>> Shortly after that I plan to follow with support for ext4. I've been
>> fuzzing ext4 for a while now and it has held up well, and I'm currently
>> working on hand-crafted attacks. Ted has commented privately (to others,
>> not to me personally) that he will fix bugs for such attacks, though I
>> haven't seen any public comments to that effect.
>
> _Static_ attacks, or change-image-under-mounted-fs attacks?
To properly protect against attacks on mounted filesystems, we'd need
some new concept of a userspace immutable file (that is, one where
nobody can write to it except the kernel, and only the kernel can change
it between regular access and this new state), and then have the kernel
set an image (or block device) to this state when a filesystem is
mounted from it (this introduces all kinds of other issues too however,
for example stuff that allows an online fsck on the device will stop
working, as will many un-deletion tools).
The only other option would be to force the FS to cache all metadata in
memory, and validate between the cache and what's on disk on every
access, which is not realistic for any real world system.
It's unfeasible from a practical standpoint to expect filesystems to
assume that stuff they write might change under them due to malicious
intent of a third party. Some filesystems may be more resilient to this
kind of attack (ZFS and BTRFS in some configurations come to mind), but
a determined attacker can still circumvent those protections (on at
least BTRFS, it's not all that hard to cause a sub-tree of the
filesystem to disappear with at most two 64k blocks being written to the
block device directly, and there is no way that this can be prevented
short of what I suggest above).
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]
^ permalink raw reply
* Re: [PATCH v3 0/7] User namespace mount updates
From: Richard Weinberger @ 2015-11-17 19:12 UTC (permalink / raw)
To: Seth Forshee
Cc: Al Viro, Eric W. Biederman, linux-bcache,
device-mapper development, linux-raid@vger.kernel.org,
linux-mtd@lists.infradead.org, linux-fsdevel, LSM, selinux,
Serge Hallyn, Andy Lutomirski, LKML, Theodore Ts'o,
Octavian Purdila
In-Reply-To: <20151117183444.GB108807@ubuntu-hedt>
On Tue, Nov 17, 2015 at 7:34 PM, Seth Forshee
<seth.forshee@canonical.com> wrote:
> On Tue, Nov 17, 2015 at 05:55:06PM +0000, Al Viro wrote:
>> On Tue, Nov 17, 2015 at 11:25:51AM -0600, Seth Forshee wrote:
>>
>> > Shortly after that I plan to follow with support for ext4. I've been
>> > fuzzing ext4 for a while now and it has held up well, and I'm currently
>> > working on hand-crafted attacks. Ted has commented privately (to others,
>> > not to me personally) that he will fix bugs for such attacks, though I
>> > haven't seen any public comments to that effect.
>>
>> _Static_ attacks, or change-image-under-mounted-fs attacks?
>
> Right now only static attacks, change-image-under-mounted-fs attacks
> will be next.
Do we *really* need to enable unprivileged mounting of kernel filesystems?
What about just enabling fuse and implement ext4 and friends as fuse
filesystems?
Using the approaching Linux Kernel Libary[1] this is easy.
[1] https://lkml.org/lkml/2015/11/3/706
--
Thanks,
//richard
^ permalink raw reply
* Re: [PATCH v3 0/7] User namespace mount updates
From: Seth Forshee @ 2015-11-17 19:16 UTC (permalink / raw)
To: Austin S Hemmelgarn
Cc: Al Viro, Eric W. Biederman, linux-bcache, dm-devel, linux-raid,
linux-mtd, linux-fsdevel, linux-security-module, selinux,
Serge Hallyn, Andy Lutomirski, linux-kernel, Theodore Ts'o
In-Reply-To: <564B79B1.3040207@gmail.com>
On Tue, Nov 17, 2015 at 02:02:09PM -0500, Austin S Hemmelgarn wrote:
> On 2015-11-17 12:55, Al Viro wrote:
> >On Tue, Nov 17, 2015 at 11:25:51AM -0600, Seth Forshee wrote:
> >
> >>Shortly after that I plan to follow with support for ext4. I've been
> >>fuzzing ext4 for a while now and it has held up well, and I'm currently
> >>working on hand-crafted attacks. Ted has commented privately (to others,
> >>not to me personally) that he will fix bugs for such attacks, though I
> >>haven't seen any public comments to that effect.
> >
> >_Static_ attacks, or change-image-under-mounted-fs attacks?
> To properly protect against attacks on mounted filesystems, we'd
> need some new concept of a userspace immutable file (that is, one
> where nobody can write to it except the kernel, and only the kernel
> can change it between regular access and this new state), and then
> have the kernel set an image (or block device) to this state when a
> filesystem is mounted from it (this introduces all kinds of other
> issues too however, for example stuff that allows an online fsck on
> the device will stop working, as will many un-deletion tools).
Yeah, Serge and I were just tossing that idea around on irc. If we can
make that work then it's probably the best solution.
From a naive perspective it seems like all we really have to do is make
the block device inode immutable to userspace when it is mounted. And
the parent block device if it's a partition, which might be a bit
troublesome. We'd have to ensure that writes couldn't happen via any fds
already open when the device was mounted too.
We'd need some cooperation from the loop driver too I suppose, to make
sure the file backing the loop device is also immutable.
^ permalink raw reply
* Re: [PATCH v3 0/7] User namespace mount updates
From: Seth Forshee @ 2015-11-17 19:21 UTC (permalink / raw)
To: Richard Weinberger
Cc: Al Viro, Eric W. Biederman, linux-bcache,
device-mapper development, linux-raid@vger.kernel.org,
linux-mtd@lists.infradead.org, linux-fsdevel, LSM, selinux,
Serge Hallyn, Andy Lutomirski, LKML, Theodore Ts'o,
Octavian Purdila
In-Reply-To: <CAFLxGvx1UqJOhM3wqAGqT+TrkapeP1zkmg0a1K=DjySePx4mEA@mail.gmail.com>
On Tue, Nov 17, 2015 at 08:12:31PM +0100, Richard Weinberger wrote:
> On Tue, Nov 17, 2015 at 7:34 PM, Seth Forshee
> <seth.forshee@canonical.com> wrote:
> > On Tue, Nov 17, 2015 at 05:55:06PM +0000, Al Viro wrote:
> >> On Tue, Nov 17, 2015 at 11:25:51AM -0600, Seth Forshee wrote:
> >>
> >> > Shortly after that I plan to follow with support for ext4. I've been
> >> > fuzzing ext4 for a while now and it has held up well, and I'm currently
> >> > working on hand-crafted attacks. Ted has commented privately (to others,
> >> > not to me personally) that he will fix bugs for such attacks, though I
> >> > haven't seen any public comments to that effect.
> >>
> >> _Static_ attacks, or change-image-under-mounted-fs attacks?
> >
> > Right now only static attacks, change-image-under-mounted-fs attacks
> > will be next.
>
> Do we *really* need to enable unprivileged mounting of kernel filesystems?
> What about just enabling fuse and implement ext4 and friends as fuse
> filesystems?
> Using the approaching Linux Kernel Libary[1] this is easy.
I haven't looked at this project, but I'm guessing that programs must be
written specifically to make use of it? I.e. you can't just use the
mount syscall, and thus all existing software still doesn't work?
> [1] https://lkml.org/lkml/2015/11/3/706
> --
> Thanks,
> //richard
^ permalink raw reply
* Re: [PATCH v3 0/7] User namespace mount updates
From: Octavian Purdila @ 2015-11-17 19:25 UTC (permalink / raw)
To: Seth Forshee
Cc: Richard Weinberger, Al Viro, Eric W. Biederman, linux-bcache,
device-mapper development, linux-raid@vger.kernel.org,
linux-mtd@lists.infradead.org, linux-fsdevel, LSM, selinux,
Serge Hallyn, Andy Lutomirski, LKML, Theodore Ts'o
In-Reply-To: <20151117192141.GD108807@ubuntu-hedt>
On Tue, Nov 17, 2015 at 9:21 PM, Seth Forshee
<seth.forshee@canonical.com> wrote:
>
> On Tue, Nov 17, 2015 at 08:12:31PM +0100, Richard Weinberger wrote:
> > On Tue, Nov 17, 2015 at 7:34 PM, Seth Forshee
> > <seth.forshee@canonical.com> wrote:
> > > On Tue, Nov 17, 2015 at 05:55:06PM +0000, Al Viro wrote:
> > >> On Tue, Nov 17, 2015 at 11:25:51AM -0600, Seth Forshee wrote:
> > >>
> > >> > Shortly after that I plan to follow with support for ext4. I've been
> > >> > fuzzing ext4 for a while now and it has held up well, and I'm currently
> > >> > working on hand-crafted attacks. Ted has commented privately (to others,
> > >> > not to me personally) that he will fix bugs for such attacks, though I
> > >> > haven't seen any public comments to that effect.
> > >>
> > >> _Static_ attacks, or change-image-under-mounted-fs attacks?
> > >
> > > Right now only static attacks, change-image-under-mounted-fs attacks
> > > will be next.
> >
> > Do we *really* need to enable unprivileged mounting of kernel filesystems?
> > What about just enabling fuse and implement ext4 and friends as fuse
> > filesystems?
> > Using the approaching Linux Kernel Libary[1] this is easy.
>
> I haven't looked at this project, but I'm guessing that programs must be
> written specifically to make use of it? I.e. you can't just use the
> mount syscall, and thus all existing software still doesn't work?
>
The projects includes a lklfuse program that uses fuse to mount a
fileystem image.
^ permalink raw reply
* Re: [PATCH v3 0/7] User namespace mount updates
From: Richard Weinberger @ 2015-11-17 19:26 UTC (permalink / raw)
To: Seth Forshee
Cc: Al Viro, Eric W. Biederman, linux-bcache,
device-mapper development, linux-raid@vger.kernel.org,
linux-mtd@lists.infradead.org, linux-fsdevel, LSM, selinux,
Serge Hallyn, Andy Lutomirski, LKML, Theodore Ts'o,
Octavian Purdila
In-Reply-To: <20151117192141.GD108807@ubuntu-hedt>
Am 17.11.2015 um 20:21 schrieb Seth Forshee:
> On Tue, Nov 17, 2015 at 08:12:31PM +0100, Richard Weinberger wrote:
>> On Tue, Nov 17, 2015 at 7:34 PM, Seth Forshee
>> <seth.forshee@canonical.com> wrote:
>>> On Tue, Nov 17, 2015 at 05:55:06PM +0000, Al Viro wrote:
>>>> On Tue, Nov 17, 2015 at 11:25:51AM -0600, Seth Forshee wrote:
>>>>
>>>>> Shortly after that I plan to follow with support for ext4. I've been
>>>>> fuzzing ext4 for a while now and it has held up well, and I'm currently
>>>>> working on hand-crafted attacks. Ted has commented privately (to others,
>>>>> not to me personally) that he will fix bugs for such attacks, though I
>>>>> haven't seen any public comments to that effect.
>>>>
>>>> _Static_ attacks, or change-image-under-mounted-fs attacks?
>>>
>>> Right now only static attacks, change-image-under-mounted-fs attacks
>>> will be next.
>>
>> Do we *really* need to enable unprivileged mounting of kernel filesystems?
>> What about just enabling fuse and implement ext4 and friends as fuse
>> filesystems?
>> Using the approaching Linux Kernel Libary[1] this is easy.
>
> I haven't looked at this project, but I'm guessing that programs must be
> written specifically to make use of it? I.e. you can't just use the
> mount syscall, and thus all existing software still doesn't work?
You can easy bridge fuse and the LKL, I did already a hacky PoC. Worked nicely.
Octavian's tree has some nice examples, and AFAIK he is currently working
on a "mount any kernel fs via fuse" tool.
Thanks,
//richard
^ permalink raw reply
* Re: [PATCH v3 0/7] User namespace mount updates
From: Al Viro @ 2015-11-17 19:30 UTC (permalink / raw)
To: Austin S Hemmelgarn
Cc: Seth Forshee, Eric W. Biederman, linux-bcache, dm-devel,
linux-raid, linux-mtd, linux-fsdevel, linux-security-module,
selinux, Serge Hallyn, Andy Lutomirski, linux-kernel,
Theodore Ts'o
In-Reply-To: <564B79B1.3040207@gmail.com>
On Tue, Nov 17, 2015 at 02:02:09PM -0500, Austin S Hemmelgarn wrote:
> >_Static_ attacks, or change-image-under-mounted-fs attacks?
> To properly protect against attacks on mounted filesystems, we'd
> need some new concept of a userspace immutable file (that is, one
> where nobody can write to it except the kernel, and only the kernel
> can change it between regular access and this new state), and then
> have the kernel set an image (or block device) to this state when a
> filesystem is mounted from it (this introduces all kinds of other
> issues too however, for example stuff that allows an online fsck on
> the device will stop working, as will many un-deletion tools).
>
> The only other option would be to force the FS to cache all metadata
> in memory, and validate between the cache and what's on disk on
> every access, which is not realistic for any real world system.
Doctor, it hurt when I do it...
IOW, the other option is to refuse attempting this insanity. Fuse probably
can be handled, but being able to mount (with kernel-space drivera) an
arbitrary ext4 image is equivalent to being able to do anything and it's
going to stay that way for the forseeable future. You are talking about
a large pile of code that deals with rather convoluted data structure,
had not been written with validation in mind *and* keeps being developed.
What's more, that code runs with maximal priveleges there are.
This is absolutely insane, no matter how much LSM snake oil you slatter on
the whole thing. All of a sudden you are exposing a huge attack surface
in the place where it would hurt most and as the consolation we are offered
basically "Ted is willing to fix holes when they are found".
I know that security community tends to be less than sane, but this really
takes the damn cake.
Al, still not quite able to believe this is not a badly mistimed AFD posting...
^ permalink raw reply
* Re: [PATCH v3 0/7] User namespace mount updates
From: Richard Weinberger @ 2015-11-17 20:12 UTC (permalink / raw)
To: Octavian Purdila, Seth Forshee
Cc: Al Viro, Eric W. Biederman, linux-bcache,
device-mapper development, linux-raid@vger.kernel.org,
linux-mtd@lists.infradead.org, linux-fsdevel, LSM, selinux,
Serge Hallyn, Andy Lutomirski, LKML, Theodore Ts'o
In-Reply-To: <CAE1zotLNq1v_ZegT9LyFsTiHWQnOAow+KKQFFvOYKUyRWPjfGA@mail.gmail.com>
Am 17.11.2015 um 20:25 schrieb Octavian Purdila:
> On Tue, Nov 17, 2015 at 9:21 PM, Seth Forshee
> <seth.forshee@canonical.com> wrote:
>>
>> On Tue, Nov 17, 2015 at 08:12:31PM +0100, Richard Weinberger wrote:
>>> On Tue, Nov 17, 2015 at 7:34 PM, Seth Forshee
>>> <seth.forshee@canonical.com> wrote:
>>>> On Tue, Nov 17, 2015 at 05:55:06PM +0000, Al Viro wrote:
>>>>> On Tue, Nov 17, 2015 at 11:25:51AM -0600, Seth Forshee wrote:
>>>>>
>>>>>> Shortly after that I plan to follow with support for ext4. I've been
>>>>>> fuzzing ext4 for a while now and it has held up well, and I'm currently
>>>>>> working on hand-crafted attacks. Ted has commented privately (to others,
>>>>>> not to me personally) that he will fix bugs for such attacks, though I
>>>>>> haven't seen any public comments to that effect.
>>>>>
>>>>> _Static_ attacks, or change-image-under-mounted-fs attacks?
>>>>
>>>> Right now only static attacks, change-image-under-mounted-fs attacks
>>>> will be next.
>>>
>>> Do we *really* need to enable unprivileged mounting of kernel filesystems?
>>> What about just enabling fuse and implement ext4 and friends as fuse
>>> filesystems?
>>> Using the approaching Linux Kernel Libary[1] this is easy.
>>
>> I haven't looked at this project, but I'm guessing that programs must be
>> written specifically to make use of it? I.e. you can't just use the
>> mount syscall, and thus all existing software still doesn't work?
>>
>
> The projects includes a lklfuse program that uses fuse to mount a
> fileystem image.
Cool. I gave it a try.
It seems to work fine, but only if I run it in foreground (using -d)
otherwise fuse blocks every filesystem request.
Thanks,
//richard
^ permalink raw reply
* Re: [PATCH v3 0/7] User namespace mount updates
From: Austin S Hemmelgarn @ 2015-11-17 20:39 UTC (permalink / raw)
To: Al Viro
Cc: Seth Forshee, Eric W. Biederman, linux-bcache, dm-devel,
linux-raid, linux-mtd, linux-fsdevel, linux-security-module,
selinux, Serge Hallyn, Andy Lutomirski, linux-kernel,
Theodore Ts'o
In-Reply-To: <20151117193012.GX22011@ZenIV.linux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 3607 bytes --]
On 2015-11-17 14:30, Al Viro wrote:
> On Tue, Nov 17, 2015 at 02:02:09PM -0500, Austin S Hemmelgarn wrote:
>
>>> _Static_ attacks, or change-image-under-mounted-fs attacks?
>> To properly protect against attacks on mounted filesystems, we'd
>> need some new concept of a userspace immutable file (that is, one
>> where nobody can write to it except the kernel, and only the kernel
>> can change it between regular access and this new state), and then
>> have the kernel set an image (or block device) to this state when a
>> filesystem is mounted from it (this introduces all kinds of other
>> issues too however, for example stuff that allows an online fsck on
>> the device will stop working, as will many un-deletion tools).
>>
>> The only other option would be to force the FS to cache all metadata
>> in memory, and validate between the cache and what's on disk on
>> every access, which is not realistic for any real world system.
>
> Doctor, it hurt when I do it...
>
> IOW, the other option is to refuse attempting this insanity. Fuse probably
> can be handled, but being able to mount (with kernel-space drivera) an
> arbitrary ext4 image is equivalent to being able to do anything and it's
> going to stay that way for the forseeable future. You are talking about
> a large pile of code that deals with rather convoluted data structure,
> had not been written with validation in mind *and* keeps being developed.
> What's more, that code runs with maximal priveleges there are.
Without factoring in unprivileged mounts, for cases when mounting from a
block device, you shouldn't have to worry about a malicious third party,
because their ability to modify it under the filesystem implies that
they either already have root privileges, or they have direct access to
hardware, and in both cases, your system is already compromised to a
degree that makes the reliability of your filesystem irrelevant. Under
the same circumstances with filesystem images, the same statement applies.
However, while unprivileged mounts make validation more important, there
is still the fact that if you don't trust someone, then you shouldn't be
letting them have access to your system. No amount of sandboxing short
of full isolation can solve that, period. Yes people will try to crack
the system, but no matter how much sandboxing there is, it will not be
unbreakable unless nobody can access it.
The attack surface is already there, it's just hard to get to. There's
a reason I never mount anything I didn't create myself and can't prove
chain of custody on without at least running fsck on it first, and then
only mount it with the kernel if there isn't a FUSE driver for it that I
trust (and GRUB provides a lot of those).
>
> This is absolutely insane, no matter how much LSM snake oil you slatter on
> the whole thing. All of a sudden you are exposing a huge attack surface
> in the place where it would hurt most and as the consolation we are offered
> basically "Ted is willing to fix holes when they are found".
For the context of static image attacks, anything that's found _needs_
to be fixed regardless, and unless you can find some way to actually
prevent attacks on mounted filesystems that doesn't involve a complete
re-write of the filesystem drivers, then there's not much we can do
about it. Yes, unprivileged mounts expose an attack surface, but so
does userspace access to the network stack, and so do a lot of other
features that are considered essential in a modern general purpose
operating system.
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]
^ permalink raw reply
* Re: [PATCH v3 0/7] User namespace mount updates
From: Austin S Hemmelgarn @ 2015-11-17 20:54 UTC (permalink / raw)
To: Seth Forshee
Cc: Al Viro, Eric W. Biederman, linux-bcache, dm-devel, linux-raid,
linux-mtd, linux-fsdevel, linux-security-module, selinux,
Serge Hallyn, Andy Lutomirski, linux-kernel, Theodore Ts'o
In-Reply-To: <20151117191606.GC108807@ubuntu-hedt>
[-- Attachment #1: Type: text/plain, Size: 2288 bytes --]
On 2015-11-17 14:16, Seth Forshee wrote:
> On Tue, Nov 17, 2015 at 02:02:09PM -0500, Austin S Hemmelgarn wrote:
>> On 2015-11-17 12:55, Al Viro wrote:
>>> On Tue, Nov 17, 2015 at 11:25:51AM -0600, Seth Forshee wrote:
>>>
>>>> Shortly after that I plan to follow with support for ext4. I've been
>>>> fuzzing ext4 for a while now and it has held up well, and I'm currently
>>>> working on hand-crafted attacks. Ted has commented privately (to others,
>>>> not to me personally) that he will fix bugs for such attacks, though I
>>>> haven't seen any public comments to that effect.
>>>
>>> _Static_ attacks, or change-image-under-mounted-fs attacks?
>> To properly protect against attacks on mounted filesystems, we'd
>> need some new concept of a userspace immutable file (that is, one
>> where nobody can write to it except the kernel, and only the kernel
>> can change it between regular access and this new state), and then
>> have the kernel set an image (or block device) to this state when a
>> filesystem is mounted from it (this introduces all kinds of other
>> issues too however, for example stuff that allows an online fsck on
>> the device will stop working, as will many un-deletion tools).
>
> Yeah, Serge and I were just tossing that idea around on irc. If we can
> make that work then it's probably the best solution.
>
> From a naive perspective it seems like all we really have to do is make
> the block device inode immutable to userspace when it is mounted. And
> the parent block device if it's a partition, which might be a bit
> troublesome. We'd have to ensure that writes couldn't happen via any fds
> already open when the device was mounted too.
>
> We'd need some cooperation from the loop driver too I suppose, to make
> sure the file backing the loop device is also immutable.
>
From a completeness perspective, you'd also need to hook into DM, MD,
and bcache to handle their backing devices. There's not much we could
do about iSCSI/ATAoE/NBD devices, and I think being able to restrict
stuff calling mount from a userns to only be able to use FUSE would
still be useful (FWIW, GRUB2 has a tool to use FUSE for testing it's own
filesystem drivers, which I use regularly when I just need a read-only
mount).
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]
^ permalink raw reply
* Re: [PATCH v3 0/7] User namespace mount updates
From: Al Viro @ 2015-11-17 21:05 UTC (permalink / raw)
To: Austin S Hemmelgarn
Cc: Seth Forshee, Eric W. Biederman, linux-bcache, dm-devel,
linux-raid, linux-mtd, linux-fsdevel, linux-security-module,
selinux, Serge Hallyn, Andy Lutomirski, linux-kernel,
Theodore Ts'o
In-Reply-To: <564B9074.5030305@gmail.com>
On Tue, Nov 17, 2015 at 03:39:16PM -0500, Austin S Hemmelgarn wrote:
> >This is absolutely insane, no matter how much LSM snake oil you slatter on
> >the whole thing. All of a sudden you are exposing a huge attack surface
> >in the place where it would hurt most and as the consolation we are offered
> >basically "Ted is willing to fix holes when they are found".
> For the context of static image attacks, anything that's found
> _needs_ to be fixed regardless, and unless you can find some way to
> actually prevent attacks on mounted filesystems that doesn't involve
> a complete re-write of the filesystem drivers, then there's not much
> we can do about it. Yes, unprivileged mounts expose an attack
> surface, but so does userspace access to the network stack, and so
> do a lot of other features that are considered essential in a modern
> general purpose operating system.
"X is exposes an attack surface. Y exposes a diferent attack surface.
Y is considered important. Therefore X is important enough to implement it"
Right...
^ permalink raw reply
* Re: [PATCH v3 0/7] User namespace mount updates
From: Seth Forshee @ 2015-11-17 21:32 UTC (permalink / raw)
To: Austin S Hemmelgarn
Cc: Al Viro, Eric W. Biederman, linux-bcache, dm-devel, linux-raid,
linux-mtd, linux-fsdevel, linux-security-module, selinux,
Serge Hallyn, Andy Lutomirski, linux-kernel, Theodore Ts'o
In-Reply-To: <564B941A.2070601@gmail.com>
On Tue, Nov 17, 2015 at 03:54:50PM -0500, Austin S Hemmelgarn wrote:
> On 2015-11-17 14:16, Seth Forshee wrote:
> >On Tue, Nov 17, 2015 at 02:02:09PM -0500, Austin S Hemmelgarn wrote:
> >>On 2015-11-17 12:55, Al Viro wrote:
> >>>On Tue, Nov 17, 2015 at 11:25:51AM -0600, Seth Forshee wrote:
> >>>
> >>>>Shortly after that I plan to follow with support for ext4. I've been
> >>>>fuzzing ext4 for a while now and it has held up well, and I'm currently
> >>>>working on hand-crafted attacks. Ted has commented privately (to others,
> >>>>not to me personally) that he will fix bugs for such attacks, though I
> >>>>haven't seen any public comments to that effect.
> >>>
> >>>_Static_ attacks, or change-image-under-mounted-fs attacks?
> >>To properly protect against attacks on mounted filesystems, we'd
> >>need some new concept of a userspace immutable file (that is, one
> >>where nobody can write to it except the kernel, and only the kernel
> >>can change it between regular access and this new state), and then
> >>have the kernel set an image (or block device) to this state when a
> >>filesystem is mounted from it (this introduces all kinds of other
> >>issues too however, for example stuff that allows an online fsck on
> >>the device will stop working, as will many un-deletion tools).
> >
> >Yeah, Serge and I were just tossing that idea around on irc. If we can
> >make that work then it's probably the best solution.
> >
> > From a naive perspective it seems like all we really have to do is make
> >the block device inode immutable to userspace when it is mounted. And
> >the parent block device if it's a partition, which might be a bit
> >troublesome. We'd have to ensure that writes couldn't happen via any fds
> >already open when the device was mounted too.
> >
> >We'd need some cooperation from the loop driver too I suppose, to make
> >sure the file backing the loop device is also immutable.
> >
> From a completeness perspective, you'd also need to hook into DM,
> MD, and bcache to handle their backing devices. There's not much we
> could do about iSCSI/ATAoE/NBD devices, and I think being able to
But really no one would be able to mount any of those without
intervention from a privileged user anyway. The same is true today of
loop devices, but I have some patches to change that.
> restrict stuff calling mount from a userns to only be able to use
> FUSE would still be useful (FWIW, GRUB2 has a tool to use FUSE for
> testing it's own filesystem drivers, which I use regularly when I
> just need a read-only mount).
Agreed, fuse alone is very useful, though there is a performance
penalty.
^ permalink raw reply
* Re: [PATCH v3 0/7] User namespace mount updates
From: Octavian Purdila @ 2015-11-17 22:00 UTC (permalink / raw)
To: Richard Weinberger
Cc: Seth Forshee, Al Viro, Eric W. Biederman, linux-bcache,
device-mapper development, linux-raid@vger.kernel.org,
linux-mtd@lists.infradead.org, linux-fsdevel, LSM, selinux,
Serge Hallyn, Andy Lutomirski, LKML, Theodore Ts'o
In-Reply-To: <564B8A20.9090607@nod.at>
On Tue, Nov 17, 2015 at 10:12 PM, Richard Weinberger <richard@nod.at> wrote:
> Am 17.11.2015 um 20:25 schrieb Octavian Purdila:
>> On Tue, Nov 17, 2015 at 9:21 PM, Seth Forshee
>> <seth.forshee@canonical.com> wrote:
>>>
>>> On Tue, Nov 17, 2015 at 08:12:31PM +0100, Richard Weinberger wrote:
>>>> On Tue, Nov 17, 2015 at 7:34 PM, Seth Forshee
>>>> <seth.forshee@canonical.com> wrote:
>>>>> On Tue, Nov 17, 2015 at 05:55:06PM +0000, Al Viro wrote:
>>>>>> On Tue, Nov 17, 2015 at 11:25:51AM -0600, Seth Forshee wrote:
>>>>>>
>>>>>>> Shortly after that I plan to follow with support for ext4. I've been
>>>>>>> fuzzing ext4 for a while now and it has held up well, and I'm currently
>>>>>>> working on hand-crafted attacks. Ted has commented privately (to others,
>>>>>>> not to me personally) that he will fix bugs for such attacks, though I
>>>>>>> haven't seen any public comments to that effect.
>>>>>>
>>>>>> _Static_ attacks, or change-image-under-mounted-fs attacks?
>>>>>
>>>>> Right now only static attacks, change-image-under-mounted-fs attacks
>>>>> will be next.
>>>>
>>>> Do we *really* need to enable unprivileged mounting of kernel filesystems?
>>>> What about just enabling fuse and implement ext4 and friends as fuse
>>>> filesystems?
>>>> Using the approaching Linux Kernel Libary[1] this is easy.
>>>
>>> I haven't looked at this project, but I'm guessing that programs must be
>>> written specifically to make use of it? I.e. you can't just use the
>>> mount syscall, and thus all existing software still doesn't work?
>>>
>>
>> The projects includes a lklfuse program that uses fuse to mount a
>> fileystem image.
>
> Cool. I gave it a try.
> It seems to work fine, but only if I run it in foreground (using -d)
> otherwise fuse blocks every filesystem request.
>
Now it should work in the background as well, thanks for reporting the issue.
^ permalink raw reply
* Re: [PATCH v3 0/7] User namespace mount updates
From: Seth Forshee @ 2015-11-17 22:01 UTC (permalink / raw)
To: Al Viro
Cc: Austin S Hemmelgarn, Eric W. Biederman, linux-bcache, dm-devel,
linux-raid, linux-mtd, linux-fsdevel, linux-security-module,
selinux, Serge Hallyn, Andy Lutomirski, linux-kernel,
Theodore Ts'o
In-Reply-To: <20151117210542.GY22011@ZenIV.linux.org.uk>
On Tue, Nov 17, 2015 at 09:05:42PM +0000, Al Viro wrote:
> On Tue, Nov 17, 2015 at 03:39:16PM -0500, Austin S Hemmelgarn wrote:
>
> > >This is absolutely insane, no matter how much LSM snake oil you slatter on
> > >the whole thing. All of a sudden you are exposing a huge attack surface
> > >in the place where it would hurt most and as the consolation we are offered
> > >basically "Ted is willing to fix holes when they are found".
None of the LSM changes are intended to protect against attacks from
these sorts of attacks at all, so that's irrelevant.
As I said before, I'm also working to find holes up front. That plus a
commitment from the maintainer seems like a good start at least. What
bar would you set for a given filesystem to be considered "safe enough"?
> > For the context of static image attacks, anything that's found
> > _needs_ to be fixed regardless, and unless you can find some way to
> > actually prevent attacks on mounted filesystems that doesn't involve
> > a complete re-write of the filesystem drivers, then there's not much
> > we can do about it. Yes, unprivileged mounts expose an attack
> > surface, but so does userspace access to the network stack, and so
> > do a lot of other features that are considered essential in a modern
> > general purpose operating system.
>
> "X is exposes an attack surface. Y exposes a diferent attack surface.
> Y is considered important. Therefore X is important enough to implement it"
>
> Right...
That isn't the argument he made. I would summarize the argument as,
"Saying that X exposes an attack surface isn't by itself enough to
reject X, otherwise we wouldn't expose anything (such as example Y)."
You believe that the attack surface is too large, and that's
understandable. Is it your opinion that this is a fundamental problem
for an in-kernel filesystem driver, i.e. that we can never be confident
enough in an in-kernel filesystem parser to allow untrusted data? If
not, what would it take to establish a level of confidence that you
would be comfortable with?
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox