Add security section

[mrunalp]

This is WIP for adding security settings as discussed in the meeting.

The settings are based on security profiles in nsinit and Seccomp configuration in opencontainers/runc#70

[wking]

Probably a good time to migrate these to the new Markdown paragraph format (#82).

[wking]

On Thu, Jul 30, 2015 at 01:46:35PM -0700, Mrunal Patel wrote:

The settings are based on security profiles in nsinit and Seccomp
configuration in #70

I think you meant opencontainers/runc#70.

I realize this spec isn't going to be a tutorial on container
security, but linking to something more specific than each tool's main
page would be nice (although I also like having main-page links). In
particular, notes about what sort of strings are valid would be
welcome (like the current the CAP_ note for Linux capabilities). So
there's no need to explain the security model, but we do need to
explain the mapping from the security model to the configuration JSON.

For example, the ‘3’ value for the
security.seccomp.syscalls[name=getcwd].action, seems like it's the
decimal version of the SECCOMP_RET_ACTION portion of SECCOMP_RET_TRAP.
It would be nice to allow string forms there ("action": "trap"?),
but if we're going to have folks matching kernel #defines, we should
explain the mapping.

[mrunalp]

@wking Yeah, I will flesh out the Seccomp section some more.

[philips]

I like adding the apparmor, selinux, seccomp and capabilities stuff but I don't see any reason to group them in a security section. rlimits may be thought of as a security mechanism to avoid denial-of-service to the rest of the system, for example.

[mrunalp]

Got rid of the separate Security struct.

[philips]

Overall this change makes sense to me.

[lizf-os]

There are two seccomp.h that are visible to users. One is exported by linux kernel and the other is defined by libseccomp. I think we should mention libseccomp?

[mrunalp]

@lizf-os Updated to mention that we use the header from libseccomp.

[LK4D4]

@mrunalp IIRC we also have MountLabel for SELinux, should it be part of specs.Mount?

[mrunalp]

@LK4D4 Yes, I think we should probably add that as well. I think I will do a follow-on PR for that.

[vbatts]

overall looks fine. rebase needed though.

[mrunalp]

Rebased.

[vbatts]

LGTM

[crosbymichael]

LGTM