[MacPorts] #39850: Sandbox denies access when prefix/portdbpath not normalised

[MacPorts]

#39850: Sandbox denies access when prefix/portdbpath not normalised
-------------------------+----------------------------
  Reporter:  jwhowse4@…  |      Owner:  cal@…
      Type:  defect      |     Status:  closed
  Priority:  Normal      |  Milestone:  MacPorts 2.3.0
 Component:  base        |    Version:  2.2.0
Resolution:  fixed       |   Keywords:
      Port:              |
-------------------------+----------------------------

Comment (by cal@…):

 Replying to [comment:75 keybounce@…]:
 > (Is it full lisp/scheme? What dialect?

 I don't know. Find out by trying, I guess?

 > Does this mean that any time a program attempts to run, a different
 program is run before it to modify its execution environment?

 No, not in the general case. If you want a sandbox you'll have to apply it
 manually by running `sandbox-exec -p $profile` – there's no automatism
 here.
 In the case of MacPorts, yes, the sandbox profile string is parsed by
 sandbox-exec each time a MacPorts port executes a command. But, Portfiles
 can already execute arbitrary code, so I don't see how that is less secure
 than what we already have. This is not meant as a security device in
 MacPorts, but as a way to prevent installation routines from doing stuff
 we don't want them to.

 > Can you just imagine the infection vector this can provide?)

 Why would you give a user permission to edit sandbox profiles used by
 privilege levels he doesn't have?

 > Third: sandbox-simplify: That command is not referenced from sandbox,
 sandboxd, sandbox-exec, etc -- yet it speaks volumes.

 If you mean "it speaks volumes" by its name and because you think
 simplifying a sandbox definition is bad per se, I think you're wrong. This
 command is intended to produce a first draft of a sandbox definition for
 software $x after getting a trace of its behavior in a controlled
 environment. Say you want to set up a sandbox for a GUI tool, so you run
 it with tracing enabled, do some (hopefully representative) stuff with it,
 close it and take a look at the trace output. `sandbox-simplify` is
 supposed to turn this into a more generic and more useful profile (because
 otherwise you might end up with a sandbox that only allows users to open
 the file you used while tracing, but not any other file). The command is a
 tool for developers to get started with sandboxing, it is not meant to
 replace the work of a developer to verify the rules are sane and needed.

 > Fourth: It looks like making symbolic links work is as simple as
 mentioning it in a
 > {{{
 > (allow file-read-metadata
 >        (literal "/etc")
 >        (literal "/tmp")
 > ...
 > }}}
 > block.

 Yes, but that only means you can read where the symlinks point. Opening a
 file after following the symlink (e.g. in `/private/etc`) will still be
 denied.

 > Fifth: I wonder if it's possible to make a system-specific version of
 system.sb or application.sb (normally in that /System directory) and solve
 all of these issues, even for Apple software updates ... (would be
 wonderful for getting stuff that does not belong on root off of it.)

 That's out of the scope of MacPorts, but I think it would just cause
 failures rather than getting anything moved.

-- 
Ticket URL: <https://trac.macports.org/ticket/39850#comment:76>
MacPorts <http://www.macports.org/>
Ports system for OS X