config: base GID must be present in the supplementary GIDs array

Currently, the spec is unclear whether the list of [supplementary GIDs][POSIX-sgids-def]
used to create a container process should include the 'base' GID
implicitly, or whether the config needs to specify this explicitly if
desired.

While [per POSIX][POSIX-sgids-rat] it is permissible for a system to
include or exclude the base GID from the list of supplementary GIDs, in
all Runtime Spec platforms the base GID is always added, and omitting it
can have [real security consequences][benthams-gaze] as fully dropping a
group is not typically allowed in Unix.

This recently led to a number of CVEs in OCI Runtime Spec
implementations, as it was concluded that it is necessary for a Unix
container to always include the base GID in the list of supplementary
GIDs, as originally established by 4.4BSD.

Some of the CVEs include:
* [Podman (CVE-2022-2989)][CVE-2022-2989]
* [Moby (CVE-2022-36109)][CVE-2022-36109]
* [Buildah (CVE-2022-2990)][CVE-2022-2990]
* [CRI-O (CVE-2022-2995)][CVE-2022-2995]

Some examples of how existing implementations handle this:
* util-linux [calls][util-linux] [initgroups(3)][initgroups.3-linux]
  with the user's primary GID.
* shadowutils (Linux) [calls][shadowutils]
  [initgroups(3)][initgroups.3-linux] with the user's primary GID.
* FreeBSD [calls][freebsd-setusercontext]
  [initgroups(3)][initgroups.3-freebsd] with the user's GID from the
  password file (aka the primary GID).
* Solaris [calls][solaris-setup_credentials]
  [initgroups(3)][initgroups.3-solaris] with the user's primary GID.
* Z/OS's session creation code is not available; however
  [initgroups(3)][initgroups.3-zos] specifies a convention of including
  including the real group ID from the user database (aka the primary
  GID).
* OpenSSH [calls][openssh] initgroups(3) with the user's primary GID; on
  all of the above platforms this will have the same result as a
  login(1), including the primary GID in the list of supplementary GIDs.

While login(1) has generally been used as the example above, the same
holds true for su(1) and other methods of starting a new session
(including OpenSSH, as explained above).

Given this seems clearly desirable and the OCI runtime is effectively
the equivalent of login(1)/su(1)/any other program that sets up a new
session, the OCI runtime is the best place to ensure that the list of
supplementary group IDs contains the base GID.

[POSIX-sgids-def]: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_378
[POSIX-sgids-rat]: https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap03.html#tag_21_03_00_73

[CVE-2022-2989]: https://access.redhat.com/security/cve/cve-2022-2989
[CVE-2022-36109]: GHSA-rc4r-wh2q-q6c4
[CVE-2022-2990]: https://access.redhat.com/security/cve/cve-2022-2990
[CVE-2022-2995]: https://access.redhat.com/security/cve/cve-2022-2995
[benthams-gaze]: https://www.benthamsgaze.org/2022/08/22/vulnerability-in-linux-containers-investigation-and-mitigation/

[util-linux]: https://github.com/util-linux/util-linux/blob/96ccdc00e1fcf1684f9734a189baf90e00ff0c9a/login-utils/login.c#L1443
[shadowutils]: https://github.com/shadow-maint/shadow/blob/eaebea55a495a56317ed85e959b3599f73c6bdf2/libmisc/setugid.c#L55
[freebsd-setusercontext]: https://github.com/freebsd/freebsd-src/blob/eeaf9d562fe137e0c52b8c346742dccfc8bde015/lib/libutil/login_class.c#L486
[solaris-setup_credentials]: https://github.com/illumos/illumos-gate/blob/d9c3e05c2d8261e3f133b5e96a300b4fa6c0f1b7/usr/src/cmd/login/login.c#L1926
[openssh]: https://github.com/openssh/openssh-portable/blob/25bd659cc72268f2858c5415740c442ee950049f/session.c#L1379
[initgroups.3-linux]: https://man7.org/linux/man-pages/man3/initgroups.3.html
[initgroups.3-freebsd]: https://www.freebsd.org/cgi/man.cgi?initgroups(3)
[initgroups.3-solaris]: https://illumos.org/man/3C/initgroups
[initgroups.3-zos]: https://www.ibm.com/docs/en/zos/2.2.0?topic=functions-initgroups-initialize-supplementary-group-id-list-process

Signed-off-by: Bjorn Neergaard <[email protected]>

config.md

@@ -226,10 +226,16 @@ The user for the process is a platform-specific structure that allows specific c
 
 For POSIX platforms the `user` structure has the following fields:
 
-* **`uid`** (int, REQUIRED) specifies the user ID in the [container namespace](glossary.md#container-namespace).
-* **`gid`** (int, REQUIRED) specifies the group ID in the [container namespace](glossary.md#container-namespace).
+* **`uid`** (int, REQUIRED) specifies the user ID (UID) in the [container namespace](glossary.md#container-namespace).
+* **`gid`** (int, REQUIRED) specifies the group ID (GID) in the [container namespace](glossary.md#container-namespace).
 * **`umask`** (int, OPTIONAL) specifies the [umask][umask_2] of the user. If unspecified, the umask should not be changed from the calling process' umask.
-* **`additionalGids`** (array of ints, OPTIONAL) specifies additional group IDs in the [container namespace](glossary.md#container-namespace) to be added to the process.
+* **`additionalGids`** (array of ints, OPTIONAL) specifies additional group IDs in the [container namespace](glossary.md#container-namespace) to be added to the list of supplementary group IDs.
+
+On a POSIX platform, processes have both a 'base' GID (as specified in the `gid` field), and an array of supplementary group IDs as described in [IEEE Std 1003.1-2008][ieee-1003.1.2008-xbd-c3.378].
+Runtimes MUST ensure that all group IDs specified by `gid` and `additionalGids` are present in the array of supplementary group IDs.
+Runtimes SHOULD preserve the order of `additionalGids`; if the base GID (as specified in the `gid` field) is absent from `additionalGids`, it SHOULD be positioned at the start of the supplementary group ID array.
+
+Entities which create a container using a runtime on a POSIX platform SHOULD duplicate the base GID (as specified in the `gid` field) as `additionalGids[0]`; this maximizes compatibility and consistency when using runtimes that target a previous version of this specification.
 
 _Note: symbolic name for uid and gid, such as uname and gname respectively, are left to upper levels to derive (i.e. `/etc/passwd` parsing, NSS, etc)_
 
@@ -986,6 +992,7 @@ Here is a full example `config.json` for reference.
 [ieee-1003.1-2008-xbd-c8.1]: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_01
 [ieee-1003.1-2008-functions-exec]: http://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html
 [naming-a-volume]: https://aka.ms/nb3hqb
+[ieee-1003.1-2008-xbd-c3.378]: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_378
 
 [capabilities.7]: http://man7.org/linux/man-pages/man7/capabilities.7.html
 [mount.2]: http://man7.org/linux/man-pages/man2/mount.2.html