Hey All,
This is a brief update.
On Tue, Oct 17, 2017 at 05:01:33PM +0000, Shawn Webb wrote:
Known Issues
Enabling the sandbox while having Tor configured in transparent proxy mode is currently broken. We are researching what causes the breakage. Chances are that either Tor is trying to access the global namespace in transparent proxy mode or one or more file descriptors simply need to be granted one or more extra capabilities.
In discussions with a FreeBSD developer, the whitelist methodology for filesystem access that Tor uses and that I adopted isn't as strong as it could be. An attacker could potentially get around the whitelist scheme as currently implemented.
Instead, the code will be rewritten to pre-open expected directories when Tor starts up, and utilize openat(2) to open file descriptors. We can utilize the existing whitelisting API to perform that work, since the whitelisting API is called prior to entering capmode.
We will keep the sandbox_open abstraction, since that will do the work of matching up with directory descriptor matches the requested path.
Future Work
The read-only nature of the whitelist is only enforced via a logic operation. We plan to relocate the whitelist into a memory mapping that will turn read-only upon entering capmode.
This is nullified by the statement above.
The current implementation should be further abstracted in order for Tor to be able to pick at runtime the appropriate sandbox implementation. This would be similar to how Tor chooses which ed25519 implementation to use, donna or ref10.
This is mostly done. The FreeBSD/Capsicum side is done. However, the Linux/seccomp-filter side needs to be integrated.
Thanks,