executing user owned scripts but nothing else (owned by use)

[ever]

hi..
i know about trusted path execution and it is almost what i was looking for.
my users should be able to execute binaries installed in system (root owned) directories. they must not execute self compiled files.
i would like them to use scripts though. shell scripts, php scripts, perl scripts...
do you see any way this could be done? ofcourse they could do stuff like
"php somefile.php"
"bash something.sh"

but this is only the second best solution in my opinion.

[katmai]

try mounting /home and /tmp with nosuid and noexec

[PaX Team]

i would like them to use scripts though. shell scripts, php scripts, perl scripts...
do you see any way this could be done?

what would be the difference between executing compiled code vs. scripts? sure, it may be more work to develop an exploit for a local bug in the latter, but beyond that, i don't see much difference between machine code and powerful interpreters like perl or php.

[PaX Team]

try mounting /home and /tmp with nosuid and noexec

and how will that prevent stuff like

Code: Select all

perl -e 'print "hello world\n"'

?

[aldee]

Running something like

Code: Select all

/lib/ld-linux.so.2 /tmp/a.out

will circumvent the noexec mount option for binaries as well. noexec adds nothing but another layer of obscurity.

[Kp]

Running something like

Code: Select all

/lib/ld-linux.so.2 /tmp/a.out

will circumvent the noexec mount option for binaries as well. noexec adds nothing but another layer of obscurity.

When will people let this belief die? That was once true, but is not true in modern glibc. On a stock 2.6.x kernel (without even GRsecurity patches):

Code: Select all

~> file /tmp/a.out
/tmp/a.out: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), stripped
~> /tmp/a.out
-bash: /tmp/a.out: Permission denied
~> /lib/ld-linux.so.2 /tmp/a.out
/tmp/a.out: error while loading shared libraries: /tmp/a.out: failed to map segment from shared object: Operation not permitted
~> strace -o /dev/tty /lib/ld-linux.so.2 /tmp/a.out &>/dev/null
execve("/lib/ld-linux.so.2", ["/lib/ld-linux.so.2", "/tmp/a.out"], [/* 46 vars */]) = 0
brk(0)                                  = 0x8001b000
open("/tmp/a.out", O_RDONLY)            = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0\3\0\1\0\0\0\240\203"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=3500, ...}) = 0
mmap2(0x8048000, 4096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0) = -1 EPERM (Operation not permitted)
close(3)                                = 0
writev(2, [{"/tmp/a.out", 10}, {": ", 2}, {"error while loading shared libra"..., 36}, {": ", 2}, {"/tmp/a.out", 10}, {": ", 2}, {"failed to map segment from share"..., 40}, {": ", 2}, {"Operation not permitted", 23}, {"\n", 1}], 10) = 128
exit_group(127)                         = ?


[PaX Team]

Running something like

Code: Select all

/lib/ld-linux.so.2 /tmp/a.out

will circumvent the noexec mount option for binaries as well. noexec adds nothing but another layer of obscurity.

When will people let this belief die? That was once true, but is not true in modern glibc. On a stock 2.6.x kernel (without even GRsecurity patches):

you're right that this technique no longer works but it's not because of glibc, but the kernel itself (notice how the mmap(PROT_EXEC) syscall fails, if glibc/ld.so was doing the enforcement, it wouldn't have issued it to begin with). second, up until 2.6.19 or .18, i forget, you could still circumvent it by a tricky ret-to-libc attack to abuse mprotect (that path has been fixed in PaX for some years already). so right now a noexec mount is effective against machine code execution, but it won't help with anything at a higher abstraction level, protection against that needs userland changes as well and i don't know of anyone working on such.

[aldee]

I stand corrected and admit to not having followed the issue as of recent. It's apparently trivial to patch binaries to run in a non-PaX-secured noexec environment though (e. g. see here, archive.org still has the patched binary test file if somebody wants to check it out with a vanilla kernel) <- well, it appears that this was fixed very recently in the vanilla kernel as well, if I got PaX Team's post right ;-).

[Kp]

Running something like

Code: Select all

/lib/ld-linux.so.2 /tmp/a.out

will circumvent the noexec mount option for binaries as well. noexec adds nothing but another layer of obscurity.

When will people let this belief die? That was once true, but is not true in modern glibc. On a stock 2.6.x kernel (without even GRsecurity patches):

you're right that this technique no longer works but it's not because of glibc, but the kernel itself (notice how the mmap(PROT_EXEC) syscall fails, if glibc/ld.so was doing the enforcement, it wouldn't have issued it to begin with). second, up until 2.6.19 or .18, i forget, you could still circumvent it by a tricky ret-to-libc attack to abuse mprotect (that path has been fixed in PaX for some years already). so right now a noexec mount is effective against machine code execution, but it won't help with anything at a higher abstraction level, protection against that needs userland changes as well and i don't know of anyone working on such.

I stand corrected. I was thinking that older loaders might not have specified PROT_EXEC in the mmap call, since it was historically unnecessary (at least on x86 systems). If the linker had requested PROT_READ without PROT_EXEC, the mapping would succeed as mere data. Subsequent execution would depend on whether NX was enforced against data mappings.