chore(deps): update dependency containers/podman-tui to v1.1.0

[uniget-bot]

This PR contains the following updates:

Package	Update	Change
containers/podman-tui	minor	1.0.1 -> 1.1.0

---

Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.

---

Release Notes

containers/podman-tui (containers/podman-tui)

v1.1.0

Compare Source

• Bump github.com/containers/podman from 5.0.3 to 5.1.0
• Bump github.com/containers/buildah from 1.35.4 to 1.36.0
• Bump github.com/containers/storage from 1.53.0 to 1.54.0
• Bump github.com/containers/common from 0.58.3 to 0.59.0
• Bump github.com/BurntSushi/toml from 1.3.2 to 1.4.0
• Bump github.com/rs/zerolog from 1.32.0 to 1.33.0

---

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR has been generated by Renovate Bot.

[nicholasdille-bot]

Auto-approved because label type/renovate is present.

[github-actions]

🔍 Vulnerabilities of ghcr.io/uniget-org/tools/podman-tui:1.1.0

📦 Image Reference ghcr.io/uniget-org/tools/podman-tui:1.1.0

digest	sha256:7f0757ae6148f83fbf5d8db60b7bce7abdfe65c4a4689d61b5d02157f84c1ceb
vulnerabilities
platform	linux/amd64
size	13 MB
packages	73

github.com/opencontainers/runc 1.1.1-0.20220617142545-8b9452f75cbc (golang) pkg:golang/github.com/opencontainers/runc@1.1.1-0.20220617142545-8b9452f75cbc OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities Affected range <1.2.0-rc.1 Fixed version 1.2.0-rc.1 CVSS Score 7.2 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H Description Withdrawn Advisory This advisory has been withdrawn because it was incorrectly attributed to runc. Please see the issue here for more information. Original Description A flaw was found in cri-o, where an arbitrary systemd property can be injected via a Pod annotation. Any user who can create a pod with an arbitrary annotation may perform an arbitrary action on the host system. This issue has its root in how runc handles Config Annotations lists. OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities Affected range <1.2.0-rc.1 Fixed version 1.2.0-rc.1 CVSS Score 7.2 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H Description On CRI-O, an arbitrary systemd property can be injected via a Pod annotation: --- apiVersion: v1 kind: Pod metadata: name: poc-arbitrary-systemd-property-injection annotations: </blockquote> </details> <a href="https://scout.docker.com/v/CVE-2023-27561?s=gitlab&n=runc&ns=github.com%2Fopencontainers&t=golang&vr=%3C%3Dv1.1.4"><img alt="high 7.0: CVE--2023--27561" src="https://img.shields.io/badge/CVE--2023--27561-lightgrey?label=high%207.0&labelColor=e25d68"/></a> <i>OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities</i> <table> <tr><td>Affected range</td><td><code><=v1.1.4</code></td></tr> <tr><td>Fixed version</td><td><strong>Not Fixed</strong></td></tr> <tr><td>CVSS Score</td><td><code>7</code></td></tr> <tr><td>CVSS Vector</td><td><code>CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H</code></td></tr> </table> <details><summary>Description</summary> <blockquote> runc through 1.1.4 has Incorrect Access Control leading to Escalation of Privileges, related to libcontainer/rootfs_linux.go. To exploit this, an attacker must be able to spawn two containers with custom volume-mount configurations, and be able to run custom images. NOTE: this issue exists because of a CVE-2019-19921 regression. </blockquote> </details> <a href="https://scout.docker.com/v/CVE-2023-28642?s=github&n=runc&ns=github.com%2Fopencontainers&t=golang&vr=%3C1.1.5"><img alt="medium 6.1: CVE--2023--28642" src="https://img.shields.io/badge/CVE--2023--28642-lightgrey?label=medium%206.1&labelColor=fbb552"/></a> <i>Improper Preservation of Permissions</i> <table> <tr><td>Affected range</td><td><code><1.1.5</code></td></tr> <tr><td>Fixed version</td><td><code>1.1.5</code></td></tr> <tr><td>CVSS Score</td><td><code>6.1</code></td></tr> <tr><td>CVSS Vector</td><td><code>CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:L</code></td></tr> </table> <details><summary>Description</summary> <blockquote> ### Impact It was found that AppArmor, and potentially SELinux, can be bypassed when `/proc` inside the container is symlinked with a specific mount configuration. ### Patches Fixed in runc v1.1.5, by prohibiting symlinked `/proc`: https://github.com/opencontainers/runc/pull/3785 This PR fixes CVE-2023-27561 as well. ### Workarounds Avoid using an untrusted container image. </blockquote> </details> <a href="https://scout.docker.com/v/CVE-2022-29162?s=github&n=runc&ns=github.com%2Fopencontainers&t=golang&vr=%3C1.1.2"><img alt="medium 5.9: CVE--2022--29162" src="https://img.shields.io/badge/CVE--2022--29162-lightgrey?label=medium%205.9&labelColor=fbb552"/></a> <i>Incorrect Default Permissions</i> <table> <tr><td>Affected range</td><td><code><1.1.2</code></td></tr> <tr><td>Fixed version</td><td><code>1.1.2</code></td></tr> <tr><td>CVSS Score</td><td><code>5.9</code></td></tr> <tr><td>CVSS Vector</td><td><code>CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L</code></td></tr> </table> <details><summary>Description</summary> <blockquote> ### Impact A bug was found in runc where `runc exec --cap` executed processes with non-empty inheritable Linux process capabilities, creating an atypical Linux environment and enabling programs with inheritable file capabilities to elevate those capabilities to the permitted set during execve(2). This bug did not affect the container security sandbox as the inheritable set never contained more capabilities than were included in the container's bounding set. ### Patches This bug has been fixed in runc 1.1.2. Users should update to this version as soon as possible. This fix changes `runc exec --cap` behavior such that the additional capabilities granted to the process being executed (as specified via `--cap` arguments) do not include inheritable capabilities. In addition, `runc spec` is changed to not set any inheritable capabilities in the created example OCI spec (`config.json`) file. ### Credits The opencontainers project would like to thank [Andrew G. Morgan](https://github.com/AndrewGMorgan) for responsibly disclosing this issue in accordance with the [opencontainers org security policy](https://github.com/opencontainers/.github/blob/master/SECURITY.md). ### For more information If you have any questions or comments about this advisory: * [Open an issue](https://github.com/opencontainers/runc/issues/new) * Email us at [security@opencontainers.org](mailto:security@opencontainers.org) if you think you’ve found a security bug </blockquote> </details> <a href="https://scout.docker.com/v/CVE-2023-25809?s=github&n=runc&ns=github.com%2Fopencontainers&t=golang&vr=%3C1.1.5"><img alt="low 2.5: CVE--2023--25809" src="https://img.shields.io/badge/CVE--2023--25809-lightgrey?label=low%202.5&labelColor=fce1a9"/></a> <i>Improper Preservation of Permissions</i> <table> <tr><td>Affected range</td><td><code><1.1.5</code></td></tr> <tr><td>Fixed version</td><td><code>1.1.5</code></td></tr> <tr><td>CVSS Score</td><td><code>2.5</code></td></tr> <tr><td>CVSS Vector</td><td><code>CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:N/I:N/A:L</code></td></tr> </table> <details><summary>Description</summary> <blockquote> ### Impact It was found that rootless runc makes `/sys/fs/cgroup` writable in following conditons: 1. when runc is executed inside the user namespace, and the `config.json` does not specify the cgroup namespace to be unshared (e.g.., `(docker|podman|nerdctl) run --cgroupns=host`, with Rootless Docker/Podman/nerdctl) 2. or, when runc is executed outside the user namespace, and `/sys` is mounted with `rbind, ro` (e.g., `runc spec --rootless`; this condition is very rare) A container may gain the write access to user-owned cgroup hierarchy `/sys/fs/cgroup/user.slice/...` on the host . Other users's cgroup hierarchies are not affected. ### Patches v1.1.5 (planned) ### Workarounds - Condition 1: Unshare the cgroup namespace (`(docker|podman|nerdctl) run --cgroupns=private)`. This is the default behavior of Docker/Podman/nerdctl on cgroup v2 hosts. - Condition 2 (very rare): add `/sys/fs/cgroup` to `maskedPaths` </blockquote> </details> </details></td></tr> </table>

[github-actions]

Attempting automerge. See https://github.com/uniget-org/tools/actions/runs/9336917782.

[github-actions]

PR is clean and can be merged. See https://github.com/uniget-org/tools/actions/runs/9336917782.