NaCl mac sandbox file. To be used with sandbox-exec.

NaCl mac sandbox file. To be used with sandbox-exec.

[Mark Mentovai, 2009-11-10 02:12:44]

Jeremy wrote Chrome's .sb files, I'm adding him to this in case he wants to take
a look too.

http://codereview.chromium.org/379019/diff/1/2
File src/trusted/sandbox/mac/nacl-sandbox.sb (right):

http://codereview.chromium.org/379019/diff/1/2#newcode1
Line 1: ;;
Needs lice: Copyright 2009 blahblah blah blah.

http://codereview.chromium.org/379019/diff/1/2#newcode8
Line 8: (debug deny)
Is this going to be loaded by Chrome?  Jeremy put an ;ENABLE_LOGGING thing
before this line in Chrome's sandbox files, so that Chrome's sandbox file loader
can find it and adjust it at runtime depending on whether sandbox logging is
desired.

See chrome/common/sandbox_mac.mm sandbox::EnableSandbox at line 133 in the
current revision (r31091).

http://codereview.chromium.org/379019/diff/1/2#newcode10
Line 10: (allow file-read-data (regex #"Frameworks/SDL.framework"))
Anchor the beginning and end with leading and trailing forward slashes.

Backslash the dot so that it does what you want in a regex.

http://codereview.chromium.org/379019/diff/1/2#newcode11
Line 11: (allow file-read-data (regex #".nexe$"))
Backslash the dot.

http://codereview.chromium.org/379019/diff/1/2#newcode12
Line 12: (allow process-exec (regex #"^.*sel_ldr$"))
What's up with ^.*?  Seems like you don't want to anchor with ^ at all.

On the other hand, you probably do want to anchor with a leading forward slash.

http://codereview.chromium.org/379019/diff/1/2#newcode20
Line 20: (regex 	#"^(/private)?/etc/localtime$"
There are other things that bsd.sb allows writes to that we might want to block.
 It allows access to any file named .CFUserTextEncoding.  Should we?

[jeremy, 2009-11-10 08:26:23]

Thanks for looking into this!

The Chrome renderer has pretty broad coverage in terms of system APIs and yet we
manage to keep the sandbox config file very small by "warming up" APIs that are
needed and only then enabling the Sandbox programmatically.

If that's not possible here I'd be grateful if you could explain the limitations
in more detail to give us a better picture.

http://codereview.chromium.org/379019/diff/1/2
File src/trusted/sandbox/mac/nacl-sandbox.sb (right):

http://codereview.chromium.org/379019/diff/1/2#newcode5
Line 5: ;; Run with sandbox-exec -f ./nacl-sandbox.sb -- sel_ldr -f module.nexe
In the rest of Chrome we turn on the Sandbox programmatically, could you do that
here too and add the code for that to this CL.

Also, rather than a whole custom sandbox definition, could you start off with
the contents of worker.sb and then add exceptions as needed.  This will also
help in the future when we hopefully have a common configuration we #include
from other configurations.

http://codereview.chromium.org/379019/diff/1/2#newcode8
Line 8: (debug deny)
Like Mark said, this is why I think it's best you start with worker.sb and add
exceptions as needed.

http://codereview.chromium.org/379019/diff/1/2#newcode10
Line 10: (allow file-read-data (regex #"Frameworks/SDL.framework"))
Are you sure you need this?  Can you load this programmatically before enabling
the Sandbox?  Same goes for the rest bellow - if you can access things before
turning on the Sandbox and remove these exceptions, that would be optimal.

http://codereview.chromium.org/379019/diff/1/2#newcode15
Line 15: (import "/usr/share/sandbox/bsd.sb")
Do you need all of this?  in Chrome we don't and we do alot of stuff in there. 
I recommend that you start from worker.sb and add exceptions as needed.

http://codereview.chromium.org/379019/diff/1/2#newcode28
Line 28: (allow mach-lookup (global-name
Why do you need all of these?  we make do without them in the renderer?