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

Discuss usability issues, general maintenance, and general support issues for a grsecurity-enabled system.

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

Postby ever » Fri Dec 15, 2006 3:32 pm

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.
ever
 
Posts: 1
Joined: Fri Dec 15, 2006 3:17 pm

Postby katmai » Tue Dec 19, 2006 3:28 am

try mounting /home and /tmp with nosuid and noexec :)
katmai
 

Re: executing user owned scripts but nothing else (owned by

Postby PaX Team » Thu Dec 21, 2006 9:42 am

ever wrote: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
 
Posts: 2310
Joined: Mon Mar 18, 2002 4:35 pm

Postby PaX Team » Thu Dec 21, 2006 9:45 am

katmai wrote: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"'
? ;-)
PaX Team
 
Posts: 2310
Joined: Mon Mar 18, 2002 4:35 pm

Postby aldee » Thu Dec 21, 2006 12:12 pm

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.
aldee
 
Posts: 25
Joined: Tue Aug 15, 2006 11:41 am

noexec does work

Postby Kp » Thu Dec 21, 2006 11:55 pm

aldee wrote: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)                         = ?
Kp
 
Posts: 46
Joined: Tue Sep 20, 2005 12:56 am

Re: noexec does work

Postby PaX Team » Fri Dec 22, 2006 5:42 am

Kp wrote:
aldee wrote: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.
PaX Team
 
Posts: 2310
Joined: Mon Mar 18, 2002 4:35 pm

Postby aldee » Fri Dec 22, 2006 5:51 am

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 ;-).
aldee
 
Posts: 25
Joined: Tue Aug 15, 2006 11:41 am

Re: noexec does work

Postby Kp » Sat Dec 23, 2006 1:26 pm

PaX Team wrote:
Kp wrote:
aldee wrote: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.
Kp
 
Posts: 46
Joined: Tue Sep 20, 2005 12:56 am


Return to grsecurity support