The Linux sandbox's filesystem broker has, of necessity, acquired a lot of functionality and attack surface since the original version. I'd once hoped that some of that code could be removed (bug 1380701) but that probably won't happen any time soon, if ever (bug 1380701 comment #23). However, some of these things could be turned off on a per-policy basis to limit what's exposed to a given process that doesn't need them.

For example:

• Individual syscalls, such as: rename, link, symlink.
  • The ability to create semi-arbitrary symlinks is especially dangerous, mainly because of the next item, and it's only been observed being used by PulseAudio, which is remoted by default.
  • If Mesa is the only user of rename, then that will be leaving content processes eventually.
  • Fontconfig and link is… odd, because we don't allow write permission on anything font-related as far as I can see, so whatever it's doing should fail anyway. Possibly that could just return a permission error and everything would be fine.
• In case where all three of the above syscalls are blocked, then the code for parsing two paths from the request can be locked out.
• The various symlink-related hacks: canonicalizing paths, propagating permissions from a symlink to its target, caching readlink results to de-canonicalize paths, maybe more I'm forgetting. For simple policies we might not need any of this.
• Write access in general: flag a policy to assert that rules aren't added with MAY_WRITE or MAY_CREATE (or remove the flags, but it's probably reasonable to just release-assert), so that policies which are currently read-only don't quietly become non-read-only without considering the implications.

Some of this is applicable to current policies. But all of it, I think, would apply to a minimal “utility process” policy (i.e., what RDD used to be before it added things like system library loading and GPU access), which might need only things like /proc/<own pid>/smaps for the memory reporter.