Current state of trace mode?

[Joshua Root]

On 2012-9-4 03:11 , Jordan K. Hubbard wrote:
> 
> On Sep 2, 2012, at 7:37 AM, Joshua Root <jmr at macports.org
> <mailto:jmr at macports.org>> wrote:
> 
>> I completely agree, it would be better for the OS to provide the
>> mechanisms. Please make it happen. ;-)
> 
> I'll see what I can do. :-)
> 
> Just to make sure we're up-to-date and in sync on the mission goals:  
> MacPorts would like to be able to know, for a process and any and all of
> its decedents (e.g. for the port(1) command and any direct or indirect
> child process of it), what files are opened (and the method of access
> requested) or created (including links).  Is that it?  Do you also care
> about files merely being stat'd or otherwise having their metadata
> interrogated?  How about execs?  Do you need to know what tools are
> being exec'd from any and all locations?

At a high level, this is what MacPorts wants:
 * to deny write access to everything outside ${workpath} for most
phases, excepting also a handful of other places on a per-phase basis
(like ${distpath} for fetch).
 * to deny read access to any file installed by a port that is not a
direct or indirect dependency of the port being built -- ideally it
looks to the build system like the files don't even exist.
 * to deny read access to everything else that isn't part of the base OS
(e.g. /usr/local, /Library/Frameworks).

We don't actually need to *know* what is being attempted, the OS just
has to allow or disallow it according to the rules we set up. Having the
info available on request would be good for debugging though. That said,
we definitely care about stat and exec.

For port(1) itself we ideally want the permissions to be dynamically
modifiable, i.e. we can get back permissions that we gave up while
running a phase in the portfile. But for the child processes it should
be locked in for the lifetime of the process. If we have to, I guess we
could use helper processes instead of changing the access of port(1),
but that's a fair bit of extra work.

> My own thinking is that file opens (of any type), file creation and
> execs are important and everything else can be ignored by the MAC
> policy.  I'm also assuming that a userland agent will be making all the
> enforcement decisions rather than having those decisions made by the
> KExt itself, though if there is a hard-and-fast set of policies that can
> be enforced by the KExt that would simplify things considerably since no
> separate IPC mechanism and way of lock-stepping port(1) (who has to
> report policy violations) and the hypothetical port-trace daemon would
> be required.

I guess it depends on how efficiently we can represent the policy. It
would be nice to just make one call to set it up and then forget about
it until it needs changing. Probably impossible to do the checks that
depend on registry information that way though.

Stuff like "no write access outside these three directories" could
easily be set up beforehand though. So with that sort of simple rule and
maybe a built-in rule covering "base OS", it should just be the
port-provided paths and other less common ones that have to be referred
to userland for a decision.

- Josh