Always use ambient capabilities if no new privileges set, not otherwise

[justincormack]

Currently we have a build flag to enable ambient capabilities. However this
is not a good situation as it means different installations of runc may
have significantly different behaviour, which can cause security issues.

The reason we introduced this was because that enabling ambient capabilities
at all times caused issues with some use cases. There are essentially two
ways that capabilities are used, which can be characterised as

• "modern" applications which want to grant capabilities directly to
  applictions, including when they run as a non root user
• "traditional" which look more like a traditional Linux distro and wish
  to mediate capabilities for non root users via suid files or with
  filesystem capabilities.

Granting ambient capabilities causes an issue with the second case as the
capabilities are immediately granted to non root processes, rather than
only being granted when suid files or files with capabilities are executed,
for example sudo.

This PR removes the build flag, so that all builds are the same. In order
to accomodate both types of use case, it makes use of the fact that of the
"no new privileges" flag is set in the config, then it is no longer possible
for suid or filesystem capabilities to have any effect, so the second use
case is not possible. So we only apply ambient capabilities if this is the
case.

So traditional applications that want to use suid binaries or fs caps should
not set the no new privileges flag in the config, and there will be no change
in behaviour.

Applications that wish to run as a non root user, and grant cpabilities that
may be directly used can set the no new provileges flag, and then they
will be granted ambient privileges, if the kernel version supports them
(since 4.3). Old kernel versions are uncapable of granting direct capabilities
to non root processes.

The changes that are required for applications using runc after this commit
are:

• if they were using the old "ambient" build flag, they should set "no new
  privileges" if they were not before.
• programs using the build without ambient capabilities (such as Docker) can
  use this build. If run without no new capabilities, there will be no change,
  but with this flag they can grant capabiltiies directly to non root
  processes. They may wish to consider which capabilties are granted by
  default in this case; I will make changes to Docker for this.

Having all builds have the same security setup is the only safe setup, at
present it is easy for a user to accidentally use a build with a different
flag setting, causing unexpected privileges to be granted. The setup as
in this commit should give a sane setup for all kinds of use case with a
single binary build. I will prepare a PR for the runtime specification
that says this behaviour is correct.

Signed-off-by: Justin Cormack justin.cormack@docker.com

[justincormack]

cc @crosbymichael @LK4D4 @mrunalp

[justincormack]

Corresponding spec PR at opencontainers/runtime-spec#668

[justincormack]

Docker PR moby/moby#30382 for testing this code.

[justincormack]

Closing until OCI spec resolved for capabilities

[redbaron]

Since opencontainers/runtime-spec#675 was merged, should discussion here be reopened?

[cyphar]

runc has explicit ambient capability support now, as of opencontainers/runtime-spec#675 -- so I believe this issue has effectively been solved (though now-a-days we should probably drop the ambient buildtag now that we have explicit support for it).