- the require analysis of the source text.
- the access analysis of free variables of the source text.
- import analysis of the source text.
I’ve started work on dumping source text authority usage and aggregating authority usage in https://github.com/bmeck/tofu .
For now I’ve been making separated tools to allow upgrades of authority aggregation/trust persistence to not be tied to analysis.
It seems like this is leading to the following set of tools:
- Authority dumper
A tool that crawls JS source text and dumps a summary of relevant usage of authority. It is not intended to be an enforcement or permissions tool.
Note that various forms of
Functionare non-trivial to make deniable due to
Function.prototype.constructorproperties. It is likely this tool will have to maintain a caveat that those properties are censored if we are to check for the ability to obtain
This does not currently seem to need to be cross module in nature of authority tracking.
- Authority permissions manager
This consumes the output of the dumper and generates a full manifest of authorities being used. This can/should be summarized for end users so they can quickly understand what authorities are in use.
Due to time it takes to crawl an entire production source tree (generally 10,000+ files, 5+ minutes on 8 core mid range machine); this has some interesting problems with cache behavior if multiple digest algorithms are used in the manifest. For now, limiting to a single algorithm in the manifest fixes the problem and keeps re-runs at around 1.5s. We could optimize more, but this seems sufficient for now.
How to share and compose manifests should be investigated. This would allow for much faster initial auditing. Doing this by using the integrity matching scheme of treating all shared integrities as having the same content seems sufficient, but I would be interested in how people think on this topic. This idea of integrity matching is already used to speed up re-runs under the term “integrity-folding”.
We need to setup a test fixture suite for these. I made some fixture work by hard coding stuff for the dumper, but having a larger test suite of canary apps would be ideal.
My work is being done with the assumption of being in the Node Core root realm and will merely be listing the caveats as it stands. This however, should be applicable to SES based environments without the caveats being in place.
In this vein, the caveats about
require()being obtained through evaluators seems something that might need to be put into Node core policy work and the ability to disable them on a per source text basis. This is unfortunate, but seems unavoidable for requirements of auditing purposes.
Attribution needs to be worked out for this tool since it relates to work from calls on Realms.