Bug 265597 – sys-apps/sandbox-1.9: Funkadelic errors and errno values.

• Product: Portage Development
• Status: RESOLVED CANTFIX

[Description solar (RETIRED) 2009-04-10 01:36:58 UTC]

# few tests on the new sandbox-1.9 [cvs 1.3]
# First tests with hardened-uclibc-x86

# static test.
uClibc ~ # sandbox
...

[s] tinderbox ~ # /bin/bb --login
root@tinderbox $ touch /out.x
ACCESS DENIED  UTIME:        /out.x
[s] tinderbox ~ #

# POOF/POW WHAT? It kicks me right out of the sub execve() shell.
# it did not let me touch the file at least. but expected to boot me?

[s] tinderbox ~ # touch out.x
[s] tinderbox ~ # rm out.x 

# Ok both worked. good. next test.


# delete a file which does not exist.
[s] tinderbox ~ # rm /out.x
ACCESS DENIED  unlink:       /out.x
rm: cannot remove `/out.x': Permission denied
[s] tinderbox ~ # ls /out.x
ls: cannot access /out.x: No such file or directory

# Perm denied on a file that does not exist? that makes no sense.

# Expected error result.
rm: cannot remove `/out.x': No such file or directory


------

[s] tinderbox ~ # exit
sandbox:spawn_shell  process returned with failed exit status 2!
Cleaning up sandbox process
============================= Gentoo path sandbox ==============================
The protected environment has been shut down.
--------------------------- ACCESS VIOLATION SUMMARY ---------------------------
LOG FILE "/var/log/sandbox/sandbox-27951.log"

VERSION 1.0
FORMAT: F - Function called
FORMAT: S - Access Status
FORMAT: P - Path as passed to function
FORMAT: A - Absolute Path (not canonical)
FORMAT: R - Canonical Path
FORMAT: C - Command Line

F: UTIME
S: deny
P: /out.x
A: /out.x
R: /out.x
C: /bin/bb --login 

F: open_wr
S: deny
P: /out.x
A: /out.x
R: /out.x
C: touch /out.x 

F: utimes
S: deny
P: /out.x
A: /out.x
R: /out.x
C: touch /out.x 

F: open_wr
S: deny
P: /out.x
A: /out.x
R: /out.x
C: touch /out.x 

F: utimes
S: deny
P: /out.x
A: /out.x
R: /out.x
C: touch /out.x 

F: open_wr
S: deny
P: /out.x
A: /out.x
R: /out.x
C: touch /out.x 

F: utimes
S: deny
P: /out.x
A: /out.x
R: /out.x
C: touch /out.x 

F: UTIME
S: deny
P: /out.x
A: /out.x
R: /out.x
C: /bin/bb --login 

F: UTIME
S: deny
P: /out.x
A: /out.x
R: /out.x
C: /bin/bb --login 

F: open_wr
S: deny
P: /out.x
A: /out.x
R: /out.x
C: touch /out.x 

F: utimes
S: deny
P: /out.x
A: /out.x
R: /out.x
C: touch /out.x 

F: unlink
S: deny
P: /out.x
A: /out.x
R: /out.x
C: rm /out.x

[Comment 1 SpanKY 2009-04-10 04:55:30 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)

[Comment 2 SpanKY 2009-04-10 06:02:10 UTC]

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.

[Comment 3 solar (RETIRED) 2009-04-10 07:27:52 UTC]

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 :)

[Comment 4 SpanKY 2009-04-10 08:39:54 UTC]

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