Comment 8 for bug 1575593

I've uploaded man-db 2.8.1-1 to Debian, and that will shortly be synced into bionic; this uses a combination of strategies involving seccomp and AppArmor to confine the processes that parse manual pages.

How much do we care about backporting some or all of this to earlier series before allowing snaps to make manual pages available? Considerations here:

 * The AppArmor support is probably relatively easy to backport. It isn't upstream as yet, since AppArmor profiles tend to have a lot of hardcoded distribution-specific paths and I haven't figured out how to sensibly distribute them upstream. It does a reasonable job of protecting some of the most complex pieces, such as /usr/bin/troff, though mainly only in terms of forbidding them from writing to anywhere interesting on the filesystem (they could still open network connections or whatever). It doesn't generally protect components of man-db itself.
 * The seccomp support is upstream (technically as of 2.8.0, but 2.8.1 fixes several serious problems). It uses a pretty restrictive filter for most things, basically just allowing processes to operate on themselves and to do the sorts of things you find in data-transforming pipes, and a slightly more permissive filter that allows limited file creation for the various groff processes that need the ability to create temporary files. It would be very invasive and difficult to try to backport this.
 * This is all proactive hardening: I don't think there's been an actual reported vulnerability in any of the relevant code for 15 years or more. Of course it's possible that that might change if it were a way out of snap confinement rather than an interesting curiosity.