Re: thoughts on kernel security issues

From: Linus Torvalds
Date: Fri Jan 14 2005 - 10:47:27 EST




On Fri, 14 Jan 2005, Horst von Brand wrote:
>
> But you can trivially run an executable via e.g.:
>
> /lib/ld-2.3.4.so some-nice-proggie

I thought we fixed this, and modern ld-so's will fail on this if
"some-nice-proggie" cannot be mapped executably. Which is exactly what
we'd do.

[ scrounge scrounge ]

Yup, just checked - it's exactly the same case as MNT_NOEXEC, which indeed
used to have exactly that bug.

So the implementation of what I suggested (and no, I'm not at all
guaranteeing that this is a wonderful idea, I'm sure others have tried it
and it probably sucks) would be something like

--- 1.161/mm/mmap.c 2005-01-12 08:26:28 -08:00
+++ edited/mm/mmap.c 2005-01-14 07:37:51 -08:00
@@ -882,9 +882,12 @@
if (!file->f_op || !file->f_op->mmap)
return -ENODEV;

- if ((prot & PROT_EXEC) &&
- (file->f_vfsmnt->mnt_flags & MNT_NOEXEC))
- return -EPERM;
+ if (prot & PROT_EXEC) {
+ if (file->f_vfsmnt->mnt_flags & MNT_NOEXEC)
+ return -EPERM;
+ if (!capability(CAP_CAN_RUN_NONROOT) && file->f_dentry->d_inode->i_uid)
+ return -EPERM;
+ }
}
/*
* Does the application expect PROT_READ to imply PROT_EXEC?

(or just add a security hook there - it's not like this couldn't be a
SELinux thing..)

And no, this doesn't trap mprotect(), but that's not the point. The point
of this is not to make it impossible to execute code on purpose by some
existing binary - it's to make it impossible for some people to compile or
download their own binaries.

(Side note: this is probably useful for MIS kind of things - if you don't
want your users to download games etc, you'd want soemthing like that. Of
course, MNT_NOEXEC in that case is fairly easy, and the "run programs
capability" is more a "this also works for arbitrary servers etc" things).

Alan's point about perl is well taken, though. Perl is a pretty damn
generic interpreter, and unlike most interpreters exposes everything. And
I doubt it uses "mmap(.. PROT_EXEC)" to map in the file ;)

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