runtime-config-linux: Require libseccomp constants

[wking]

Don't punt readers to libseccomp, because this spec is supposed to be
a self-sufficient contract between the bundle-author and the
runtime. The bundle-author shouldn't care if the runtime uses
libseccomp, or which version of libseccomp it uses. But they can rely
on the listed constants being supported (and we may want to bring over
brief descriptions to go along with the constants themselves).

Runtime authors, on the other hand, may want to know that v2.2.3 of
libseccomp provides all the required constants. I've added links to
the libseccomp 2.2.3 header from which these constants were extracted,
and that should be enough of a hint for bundle authors to use a
compatible libseccomp version (if they want to use libseccomp at all).

Spun off from #200, which has since landed.

[mheon]

I don't know if we should make the set of valid constants listed here a hard requirement for implementation (mostly with regards to architectures). I can see some implementations of the spec only supporting x86-64, and thus would never require the MIPS architecture constants, for example.

Perhaps there should be a requirement that all constants be recognized, but a note that there is no guarantee an implementation supports all architectures?

[wking]

On Wed, Sep 23, 2015 at 02:36:36PM -0700, Matthew Heon wrote:

Perhaps there should be a requirement that all constants be
recognized, but a note that there is no guarantee an implementation
supports all architectures?

That sounds reasonable. What about actions? I see runC doesn't
support trace 1. On the other hand, that means that there will be
an out-of-spec contract between the runtime and bundle author 2,
and I don't think we have good tooling now to figure out if a
particular bundle is compatible with a particular runtime (short of
passing the config to the runtime and checking for errors ;). This
sort of optional-feature stuff is why I floated a more flexible
feature-flags scheme in #15, and if we want to commit to an
optional-spec-support path, I'd like to see us using something like
that to explicitly tag the optional feature blocks.

[mheon]

On actions: I think it's reasonable to make implementing all of them mandatory. They currently encompass the entirety of what the Linux kernel can do on a Seccomp rule match, and I don't believe there are plans to add more any time soon, so this should remain a fairly stable part of the API. As you mentioned, this would require that runC also implement trace, but that should be simple to do.

Seccomp as a whole would be a good candidate for being an optional feature, if a set of feature flags were to emerge. We already have runC builds with no Seccomp integration present, and not all are going to link against the latest libseccomp (which mostly limits the architectures which can be used with the library).

[wking]

Looking back at #200, I realize now that libseccomp architecture is not going to be a bundle-author decision, and will likely be filled in by the runtime-caller before invoking the runtime. Maybe this should be a more generic “kernel architecture” field (and not seccomp-specific?). Then we don't have to worry about requiring support, since the runtime is clearly independent of the kernel architecture (and matching bundles with compatible kernels is the job of some out-of-scope external tooling, see #73).

[crosbymichael]

NOTLGTM

We were talking about defining our own const and this goes the opposite way and introduces wording like MUST that I don't think should be there.

[mrunalp]

Agree.