Begin trace collection at boot (or early in boot)

[arunthomas]

We currently start trace collection well after the system is booted, so we miss open() events. As a result, we do not capture paths for some files. TA2s would like to see paths for all files that are accessed.

Some options:

• We could start collection early in the boot process and cache UUID-filepath mappings
• We could create an interface that would return the file paths associated with a UUID.

Each option has its complications.

[rwatson]

While filesystem UUIDs do uniquely identify files, they are not currently designed to allow efficient lookup to get from UUID to underlying filesystem object. For example, while we could add a set of calls along the lines of uuid_open(2), uuid_stat(2), uuid_getpath(2), etc, that's not really what it's currently designed to do (unlike, say, NFS file handles, from which we derive UUIDs -- but using a cryptographic hash as described in the UUID spec). We could change the way we generate UUIDs -- e.g., to directly embed rather than hash the file handle -- but I'm not yet convinced this is a path we want to pursue. I think I'd be tempted to try and pursue a way to journal traces we need during early boot so that they are available later -- even if they are just a list of name->UUID bindings as they become visible, rather than the full trace we might want later once the system is live?

[arunthomas]

Starting collection early (using anonymous tracing) is the approach will we try to take for engagement 2.

[arunthomas]

Essentially, we want to capture open events and possibly fork to capture UUID-path mappings and UUID-cmdline mappings.

[gvnn3]

The anonymous tracing does work within the cadets and dtrace branches. The Oracle docs cover this briefly https://docs.oracle.com/cd/E18752_01/html/819-5488/gcgln.html

In our case I gather we'll want to use a script, so I'm suggesting we modify audit.d and call it boot.d at which point we do

# dtrace -ACs boot.d # shutdown -r now ... # dtrace -ae > somefile

If we want the tracing to continue after we do the collection then leave the -e off of the last command:

# dtrace -a > somefile

[rwatson]

Just to confirm: do we believe this works fine with JSON output?

[gvnn3]

Right now we're depending on the fact that the script itself dumps out json output, but I'm working on the question of why the anonymous printout seems to miss the -O json flag.

[gvnn3]

I've added a simple boot.d script to capture all exec's and namei lookups. The format ought to be the same as the CADETS trace format but Amanda or Arun should check on that. The usage is listed in the script and is also shown above, in my earlier comment..

[gvnn3]

Process and thread UUIDs are now part of the script, and verified in a boot environment.

[rwatson]

With 139f028de2a35b7721c02db30d9c895bd3176c95 merged, we now support dtaudit probes during early boot.