[MacPorts] #39850: Sandbox denies access when prefix/portdbpath not normalised
MacPorts
noreply at macports.org
Sun Mar 23 06:00:12 PDT 2014
#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
More information about the macports-tickets
mailing list