Summary: | sys-kernel/hardened-sources-2.6.38-r2 seems to break sys-apps/sandbox | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Xake <kanelxake> |
Component: | New packages | Assignee: | The Gentoo Linux Hardened Kernel Team (OBSOLETE) <hardened-kernel+disabled> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | blueness, pageexec, spender, taaroa |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | kernel config for hardened 2.6.38-r2 |
Description
Xake
2011-05-03 21:22:54 UTC
hardened-2.6.38 seems to work, 2.6.38-r1 seems broken. Maybe this backtrace says something to someone, but it seems like sandbox uses ptrace(PTRACE_PEEKUSER) to find out what "personality" a process have (or rather if the process is 32-bit or 64-bit), and seems to think in this case that the process is 32-bit (which it is not) and calls sb_abort. So what makes this happends with newer patches? grsec returning something wrong, or denies some access that sandbox does not handle? Tested the latest, grsecurity-2.2.2-2.6.38.4-201105021909.patch, and got the same result. #0 0x00006cd6b89d9655 in raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 resultvar = 0 pid = <value optimized out> selftid = <value optimized out> #1 0x00006cd6b89da955 in abort () at abort.c:92 save_stage = 2 act = {__sigaction_handler = {sa_handler = 0x1071, sa_sigaction = 0x1071}, sa_mask = {__val = {7811907410160, 119669484148651, 0, 1, 119669486273440, 136569913344912, 7811904476699, 0, 12678774269484397441, 119669486264512, 7811904482013, 4, 12678774269484397441, 2, 119669484148651, 0}}, sa_flags = -641029235, sa_restorer = 0x6cd6b93820c0 <path.7201>} sigs = {__val = {32, 0 <repeats 15 times>}} #2 0x00006cd6b9173758 in sb_abort () at ../../sandbox-2.5/libsandbox/libsandbox.c:490 No locals. #3 0x00006cd6b917565d in pers_is_32 () at ../../sandbox-2.5/libsandbox/trace/linux/x86_64.c:21 No locals. #4 0x00006cd6b9175fba in trace_check_personality (filename=<value optimized out>, argv=<value optimized out>) at ../../sandbox-2.5/libsandbox/trace/linux/x86_64.c:27 No locals. #5 lookup_syscall (filename=<value optimized out>, argv=<value optimized out>) at ../../sandbox-2.5/libsandbox/trace.c:203 No locals. #6 trace_loop (filename=<value optimized out>, argv=<value optimized out>) at ../../sandbox-2.5/libsandbox/trace.c:425 ret = <value optimized out> nr = <value optimized out> se = <value optimized out> tbl_at_fork = 0x6cd6b9381820 regs = {r15 = 0, r14 = 0, r13 = 0, r12 = 0, rbp = 0, rbx = 0, r11 = 512, r10 = 0, r9 = 0, r8 = 0, rax = 0, rcx = 0, rdx = 0, rsi = 0, rdi = 0, orig_rax = 59, rip = 3832113568, cs = 35, eflags = 512, rsp = 4117279968, ss = 43} before_syscall = true exec_state = 2 #7 trace_main (filename=<value optimized out>, argv=<value optimized out>) at ../../sandbox-2.5/libsandbox/trace.c:491 sa = {__sigaction_handler = {sa_handler = 0x6cd6b9175b70 <trace_child_signal>, sa_sigaction = 0x6cd6b9175b70 <trace_child_signal>}, sa_mask = {__val = {12678774269484397441, 0, 119669488293544, 0, 12678774269484397441, 7, 0, 7811907490112, 12678774269484397441, 7811907465040, 0, 7811907490112, 119669484124042, 0, 7811904476699, 119669484148935}}, sa_flags = 268435460, sa_restorer = 0} old_sa = {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = {__val = {0, 7811904508352, 119669476417548, 7811907479616, 119669479501408, 7811907479664, 7811907376120, 7811907446192, 7811907452672, 7811904508352, 119669479501408, 7811907381392, 0, 7811907446192, 119669479501408, 7811907381392}}, sa_flags = 335544320, sa_restorer = 0x6cd6b89d96d0 <__restore_rt>} __func__ = "trace_main" #8 0x00006cd6b9176a98 in sb_check_exec (filename=0x71ad9f89140 "/lib/ld-linux.so.2", argv=0x71ad9f82f50) at ../../sandbox-2.5/libsandbox/wrapper-funcs/__wrapper_exec.c:68 fd = 3 elf = <value optimized out> st = {st_dev = 64769, st_ino = 4718674, st_nlink = 1, st_mode = 33261, st_uid = 0, st_gid = 0, __pad0 = 0, st_rdev = 0, st_size = 117948, st_blksize = 4096, st_blocks = 232, st_atim = {tv_sec = 1304450545, tv_nsec = 615956084}, st_mtim = {tv_sec = 1304359127, tv_nsec = 0}, st_ctim = {tv_sec = 1304359180, tv_nsec = 591716768}, __unused = {0, 0, 0}} #9 0x00006cd6b917abc3 in execve_DEFAULT (path=0x71ad9f89140 "/lib/ld-linux.so.2", argv=0x71ad9f82f50, envp=0x71ad9f7eef0) at ../../sandbox-2.5/libsandbox/wrapper-funcs/__wrapper_exec.c:214 result = -1 my_env = 0x71ad9f7eef0 old_errno = 0 check_path = 0x71ad9f89140 "/lib/ld-linux.so.2" Confirmed that this happens with 2.6.32-hardened-r45 as well which is based on grsecurity-2.2.2-2.6.32.39-201104232142. I'll try to bisect this later, in the mean time, cc-ing upstream. They may see what's going on just from the bt. does this happen only on 64 bit kernels? This seems to be affecting multilib only then? I've tested on two amd64 no-multilib systems, one with .38-hardened and the other with .38-hardened-r2 and I can't reproduce the issue. (In reply to comment #4) > does this happen only on 64 bit kernels? We need a better testcase for this, since what sandbox does is essentially: switch (do_peekuser(8 * CS)) { case 0x23: return true; case 0x33: return false; default: sb_abort(); } Where do_peekuser essentially does ptrace(PTRACE_PEEKUSER, 8 * CS, trace_pid, NULL) Now these functions are never executed on a no-multilib system (the bool pers_is_32 is forced to false), and on a x86 the file containing them should not even be launched. So we need a testcase that always runt a ptrace. I have not had the time to do this yet, tho. @pax, spender Have you done anything with permissions wrt ptrace? It seems like I get "permission denied" for different stuff when I try to launch ptrace against it (have yet to try it on a non-hardened kernel). I think this is related: While playing around a bit with this I noticed some things, and tried run "strace /lib/ld-linux.so.2" only to find strange messages. With old grsecurity patch I more or less just get [ Process PID=... runs in 32 bit mode. ] before the output from ld-linux.so.2, and after that I get exit_group(127). With newer grsecurity patches I get the first output, but before ld-linux.so.2 prints its output I also get some: "Unknown value CS=0x... while detecting personlaity of process PID..." and after the output from ld-linux.so.2 I do not get exit_group(127), but instead two more of those messages. For the first to strace reports a value of CS being 0x282, while for the rest the value is 0x246. Since sandbox seems to mess with ptrace and CS to when trying to figure out personality, I thought this may be of importance. (In reply to comment #8) > With newer grsecurity patches I get the first output, but before ld-linux.so.2 > prints its output I also get some: "Unknown value CS=0x... while detecting > personlaity of process PID..." and after the output from ld-linux.so.2 I do not > get exit_group(127), but instead two more of those messages. > For the first to strace reports a value of CS being 0x282, while for the rest > the value is 0x246. ok, this makes me think that the recent changes related to RANDKSTACK on amd64 are causing this, i'll invesitage. Here's what clues I have: 1) I confirmed as radegand saw that it only affects 64-bit multilib. Running echo "main(){}" > test.c && gcc -o test test.c && sandbox /lib/ld-2.11.3.so --verify ./test on nomultilib works. 2) You can turn off all GRSEC/PAX features and you still hit this error on recent patches >=201104191737, both for the .32 and .38 branches. You do not hit this error on previous. (My usual technique is to isolate which feature causes the problem before jumping into the ifnef maze.) Not sure where to start with this. (In reply to comment #10) > Here's what clues I have: > > 1) I confirmed as radegand saw that it only affects 64-bit multilib. Running > > echo "main(){}" > test.c && gcc -o test test.c && sandbox /lib/ld-2.11.3.so > --verify ./test > > on nomultilib works. > That is as I pointed out because on anything but multilib this logic is turned off. "strace /lib/ld-linux.so.2" seems to be a better indicator. see also [url=https://bugs.gentoo.org/show_bug.cgi?id=365915]#365915[/url] (In reply to comment #8) > With newer grsecurity patches I get the first output, but before ld-linux.so.2 > prints its output I also get some: "Unknown value CS=0x... while detecting > personlaity of process PID..." and after the output from ld-linux.so.2 I do not > get exit_group(127), but instead two more of those messages. > For the first to strace reports a value of CS being 0x282, while for the rest > the value is 0x246. > > Since sandbox seems to mess with ptrace and CS to when trying to figure out > personality, I thought this may be of importance. see https://bugs.gentoo.org/attachment.cgi?id=272157 i fixed the 32 bit userland breakage, the next grsec patch will have the fix. (In reply to comment #14) > i fixed the 32 bit userland breakage, the next grsec patch will have the fix. Thank you.:-) We close this when blueness has bumped the sources in portage and confirmed the fix. Okay confirmed that hardened-sources-2.6.38-r4 is fixed. I have removed -r2. I will test -r3 in a minute and remove it too if its also broken. I'll close this for now. Thanks pipacs :) hardened-sources-2.6.38-r3 is broken too. Its out. grsecurity-2.2.2-2.6.38.6-201105111839 please add this and retest. |