1. 15 Feb, 2019 1 commit
  2. 14 Feb, 2019 3 commits
  3. 13 Feb, 2019 2 commits
  4. 12 Feb, 2019 6 commits
  5. 11 Feb, 2019 14 commits
    • Merge pull request #2844 from brauner/2019-02-11/licensing+ · b88ccedc
      Stéphane Graber authored
      string_utils.h: fix wrong licensing
    • string_utils.h: fix wrong licensing · 84fa5aca
      Christian Brauner authored
      liblxc has always been meant to be LGPLv2.1+ as reflected by the many
      downstreams projects and bindings which are themselves under LGPLv2.1+ or other
      licenses which would be incompatible with linking against a GPLv2+ library.
      
      It's pretty normal for a library to be LGPL while binaries are GPL as a GPL
      library would only ever be usable by other GPL-only projects, which isn't the
      case for very many of the liblxc downstreams.
      
      The issue here is really carelessness. None of those GPL headers were put there
      intentionally, instead being wrongly copy/pasted from other parts of the
      codebase which is indeed intended to be GPLv2+. This is also made clear in our
      CONTRIBUTING file in this repository:
      
      Licensing for new files:
      ------------------------
      
      LXC is made of files shipped under a few different licenses.
      
      Anything that ends up being part of the LXC library needs to be released
      under LGPLv2.1+ or a license compatible with it (though the latter will
      only be accepted for cases where the code originated elsewhere and was
      imported into LXC).
      
      Language bindings for the libraries need to be released under LGPLv2.1+.
      
      Anything else (non-libraries) needs to be Free Software and needs to be
      allowed to link with LGPLv2.1+ code (if needed). LXC upstream prefers
      LGPLv2.1+ or GPLv2 for those.
      
      When introducing a new file into the project, please make sure it has a
      copyright header making clear under which license it's being released
      and if it doesn't match the criteria described above, please explain
      your decision on the lxc-devel mailing-list when submitting your patch.
      
      This is intended to switch over files to LGPLv2.1+ to which end we have
      collected ACKs from relevant people.
      /* Affected People */
      Christian Brauner <christian.brauner@ubuntu.com>
      Fabrice Fontaine <fontaine.fabrice@gmail.com>
      Josh Soref <jsoref@gmail.com>
      Signed-off-by: 's avatarChristian Brauner <christian.brauner@ubuntu.com>
      Acked-by: 's avatarFabrice Fontaine <fontaine.fabrice@gmail.com>
      Acked-by: 's avatarJosh Soref <jsoref@gmail.com>
    • Merge pull request #2843 from brauner/2019-02-11/fix_licensing_brauner · 9581e697
      Stéphane Graber authored
      fix licensing headers
    • syscall_wrappers: fix wrong licensing · 7043a15d
      Christian Brauner authored
      /* Affected People */
      Christian Brauner <christian.brauner@ubuntu.com>
      Aleksa Sarai <cyphar@cyphar.com>
      Signed-off-by: 's avatarChristian Brauner <christian.brauner@ubuntu.com>
    • ringbuf.h: fix wrong licensing · c423a0a7
      Christian Brauner authored
      /* Affected People */
      Christian Brauner <christian.brauner@ubuntu.com>
      Signed-off-by: 's avatarChristian Brauner <christian.brauner@ubuntu.com>
    • memory_utils: fix wrong licensing · cd4a865d
      Christian Brauner authored
      /* Affected People */
      Christian Brauner <christian.brauner@ubuntu.com>
      Signed-off-by: 's avatarChristian Brauner <christian.brauner@ubuntu.com>
    • rexec: fix wrong licensing · 2b3153a8
      Christian Brauner authored
      /* Affected People */
      Christian Brauner <christian.brauner@ubuntu.com>
      Aleksa Sarai <asarai@suse.de>
      Signed-off-by: 's avatarChristian Brauner <christian.brauner@ubuntu.com>
      Acked-by: 's avatarAleksa Sarai <cyphar@cyphar.com>
    • api_extensions: fix wrong licensing · 3877934c
      Christian Brauner authored
      /* Affected People */
      Christian Brauner <christian.brauner@ubuntu.com>
      Signed-off-by: 's avatarChristian Brauner <christian.brauner@ubuntu.com>
    • file_utils.h: fix wrong licensing · 6aae19f7
      Christian Brauner authored
      /* Affected People */
      Christian Brauner <christian.brauner@ubuntu.com>
      Signed-off-by: 's avatarChristian Brauner <christian.brauner@ubuntu.com>
    • compiler: fix wrong licensing · b80e01bd
      Christian Brauner authored
      /* Affected People */
      Christian Brauner <christian.brauner@ubuntu.com>
      Signed-off-by: 's avatarChristian Brauner <christian.brauner@ubuntu.com>
    • api_extensions: fix wrong licensing · 7fd02ed7
      Christian Brauner authored
      /* Affected People */
      Christian Brauner <christian.brauner@ubuntu.com>
      Signed-off-by: 's avatarChristian Brauner <christian.brauner@ubuntu.com>
    • Merge pull request #2841 from brauner/2019-02-11/fix_android · 9c63d38c
      Stéphane Graber authored
      include: add fexecve() for Android's Bionic
    • CVE-2019-5736 (runC): rexec callers as memfd · 6400238d
      Christian Brauner authored
      Adam Iwaniuk and Borys Popławski discovered that an attacker can compromise the
      runC host binary from inside a privileged runC container. As a result, this
      could be exploited to gain root access on the host. runC is used as the default
      runtime for containers with Docker, containerd, Podman, and CRI-O.
      
      The attack can be made when attaching to a running container or when starting a
      container running a specially crafted image.  For example, when runC attaches
      to a container the attacker can trick it into executing itself. This could be
      done by replacing the target binary inside the container with a custom binary
      pointing back at the runC binary itself. As an example, if the target binary
      was /bin/bash, this could be replaced with an executable script specifying the
      interpreter path #!/proc/self/exe (/proc/self/exec is a symbolic link created
      by the kernel for every process which points to the binary that was executed
      for that process). As such when /bin/bash is executed inside the container,
      instead the target of /proc/self/exe will be executed - which will point to the
      runc binary on the host. The attacker can then proceed to write to the target
      of /proc/self/exe to try and overwrite the runC binary on the host. However in
      general, this will not succeed as the kernel will not permit it to be
      overwritten whilst runC is executing. To overcome this, the attacker can
      instead open a file descriptor to /proc/self/exe using the O_PATH flag and then
      proceed to reopen the binary as O_WRONLY through /proc/self/fd/<nr> and try to
      write to it in a busy loop from a separate process. Ultimately it will succeed
      when the runC binary exits. After this the runC binary is compromised and can
      be used to attack other containers or the host itself.
      
      This attack is only possible with privileged containers since it requires root
      privilege on the host to overwrite the runC binary. Unprivileged containers
      with a non-identity ID mapping do not have the permission to write to the host
      binary and therefore are unaffected by this attack.
      
      LXC is also impacted in a similar manner by this vulnerability, however as the
      LXC project considers privileged containers to be unsafe no CVE has been
      assigned for this issue for LXC. Quoting from the
      https://linuxcontainers.org/lxc/security/ project's Security information page:
      
      "As privileged containers are considered unsafe, we typically will not consider
      new container escape exploits to be security issues worthy of a CVE and quick
      fix. We will however try to mitigate those issues so that accidental damage to
      the host is prevented."
      
      To prevent this attack, LXC has been patched to create a temporary copy of the
      calling binary itself when it starts or attaches to containers. To do this LXC
      creates an anonymous, in-memory file using the memfd_create() system call and
      copies itself into the temporary in-memory file, which is then sealed to
      prevent further modifications. LXC then executes this sealed, in-memory file
      instead of the original on-disk binary. Any compromising write operations from
      a privileged container to the host LXC binary will then write to the temporary
      in-memory binary and not to the host binary on-disk, preserving the integrity
      of the host LXC binary. Also as the temporary, in-memory LXC binary is sealed,
      writes to this will also fail.
      
      Note: memfd_create() was added to the Linux kernel in the 3.17 release.
      Signed-off-by: 's avatarChristian Brauner <christian.brauner@ubuntu.com>
      Co-Developed-by: 's avatarAlesa Sarai <asarai@suse.de>
      Acked-by: 's avatarSerge Hallyn <serge@hallyn.com>
      Signed-off-by: 's avatarChristian Brauner <christian.brauner@ubuntu.com>
  6. 10 Feb, 2019 6 commits
  7. 09 Feb, 2019 8 commits