Summary: | sys-apps/sandbox-1.9: Funkadelic errors and errno values. | ||
---|---|---|---|
Product: | Portage Development | Reporter: | solar (RETIRED) <solar> |
Component: | Sandbox | Assignee: | Sandbox Maintainers <sandbox> |
Status: | RESOLVED CANTFIX | ||
Severity: | normal | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
solar (RETIRED)
2009-04-10 01:36:58 UTC
attempting to rm a file (even one that does not exist) should throw an error. the package shouldnt have tried it in the first place since (1) it doesnt exist and (2) it's in a denied location. not sure why that shell exited immediately though ... i'll have to toy with that i have been testing sandbox from time to time on uClibc to make sure it works and 1.6+ should be exactly on par with glibc (all the getcwd probs of the past should be solved) oh, i think i know what's going on. your /bin/bb is a static binary right ? sandbox is wrapping that with ptrace and not LD_PRELOAD. ptrace catches the utime() syscall made on "/" but since the ptrace framework does not have a way to modify execution of the traced program, there's nothing we can do. we get notified that the traced program is making syscall XXX but our only options are to (1) allow it (continue execution) or (2) kill the program and thus prevent the syscall from occurring. we could do (3) allow the syscall to finish but then modify the return value from the kernel so the program thinks it failed, but the problem there is that we just allowed the syscall to happen. if that's something like "unlink(/some/file)", then we certainly dont want that. iirc, they're talking about adding another ptrace request to 2.6.30 or later where the program doing the tracing can signal the kernel to skip the syscall. but until that functionality exists, there's nothing we can do. Oddly enough it was uclibc that did not suffer from any getcwd/getwd calls. It was glibc and then azarah put some checks in for glibc which ended up being wrong or so on uclibc. Anyway it seems to be working pretty solid so far and I've yet to see any simple ways to outsmart it like unlike the older sandbox. Well I guess of course if one wanted to get sneaky enough and you don't trap it then one could create a semi untraceable process via the classic ptrace(PTRACE_TRACEME, 0, 0, 0)+forking tricks. ptrace framework.. <-- sure you can. See Phrack-059/12 But please don't :) there are plenty of ways to get out of the sandbox ... but i treat sandbox as a QA tool, not as a security tool ptrace currently does not follow vforks/forks. i plan on fixing this, i just havent gotten around to it yet. i'll check that out: less /usr/share/doc/phrack/p59-0x12.txt.lzma |