RunRoot & mistaken IDs
by lejeczek
Hi guys.
I experience this:
-> $ podman images
WARN[0000] RunRoot is pointing to a path
(/run/user/1007/containers) which is not writable. Most
likely podman will fail.
Error: creating events dirs: mkdir /run/user/1007:
permission denied
-> $ id
uid=2001(podmania) gid=2001(podmania) groups=2001(podmania)
context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
I think it might have something to do with the fact that I
changed UID for the user, but why would this be?
How troubleshoot & fix it, ideally without system reboot?
many thanks, L.
9 months, 3 weeks
Re: [Vulnerability Report] ctr-cnt: Host containers count info leak
by wanglei (M)
Dear Akihiro Suda, Mrunal Patel:
Thank you for your reply and I respect your opinion.
For Docker, Containerd, Podman, and other runtimes, shall we add refcnt to maskedpath when setting spec?
From: Mrunal Patel [mailto:mpatel@redhat.com]
Send: 2024年1月26日 5:38
To: Akihiro Suda <suda.kyoto(a)gmail.com>
CC: wanglei (M) <wanglei249(a)huawei.com>; Security@Docker <security(a)docker.com>; security(a)containerd.io; podman(a)lists.podman.io; cncf-crio-security(a)lists.cncf.io; security(a)opencontainers.org; Heyuandong <heyuandong(a)huawei.com>
Subject: Re: [Vulnerability Report] ctr-cnt: Host containers count info leak
I agree that this isn't a vulnerability.
On Thu, Jan 25, 2024 at 1:29 PM Akihiro Suda <suda.kyoto(a)gmail.com<mailto:suda.kyoto@gmail.com>> wrote:
I don't think this is a vuln.
Containers have been leaking loadavg, memory usage, disk usage, and other resource counters too.
2024年1月25日(木) 18:09 'wanglei (M)' via OCI Security <security(a)opencontainers.org<mailto:security@opencontainers.org>>:
Dear Container Security Teams:
I hope this message finds you well. My name is LEI WANG, a container security newb. I am writing to report a security vulnerability about host containers count info leakage.
________________________________
1. Information
Item
Details
Note
Project
docker<https://github.com/moby/moby>
containerd<https://https/github.com/containerd/containerd>
podman<https://github.com/containers/podman>
crio
runc<https://github.com/opencontainers/runc>
Due to the widespread impact, we have also copied runc
…
If other container software is affected, please forward the email.
Affect Version
all
CVSS
4.3 CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N
Author
LEI WANG
Github-ID: ssst0n3<http://github.com/ssst0n3>
2. Original Features
Container runtimes manage the file system using graph drivers such as overlay and devicemapper, which are loaded as modules into the kernel.
The container runtime shares the host’s sysfs, where /sys/module/<MODULE_NAME>/refcnt represents the reference count of the corresponding module. The reference count of these modules typically matches the number of mounted file systems on the host, thereby leaking the number of running containers on the host.
3. Vulnerability
3.1 Description
Files such as /sys/module/overlay/refcnt reveal the number of containers running on the host because the sysfs of the host is shared when the container is running.
3.2 Impact
All versions of the all runtime are affected
* docker
* containerd
* cri-o
* podman
* …
Given the breadth of the impact on the runtime, it may be necessary to copy runc.
Disclosure of the number of containers running on a host can provide several potential advantages to an attacker:
1. Target value assessment: If an attacker knows that a system is running a large number of containers, the system may host multiple services or applications, indicating that the target is a high-value target.
2. Resource utilization and load information: The number of containers can give attackers some clues about system resource utilization and load. For example, a host running a large number of containers may have high resource usage, which may allow attackers to use this information to launch denial-of-service (DoS) or distributed denial-of-service (DDoS) attacks.
3. Attack vector identification: Knowing the number of containers may also help attackers infer potential attack vectors. For example, if many containers are running, attackers may assume that some of these containers may not have proper security configuration or timely software updates.
4. Penetration policy planning: Attackers may plan multi-phase attacks or select the most likely unhardened container intrusion based on the number of containers and their speculation about the system architecture.
3.3 CVSS
4.3 CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N<https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:...>
vector
score
reason
Attack Vector
Local
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Changed
Confidentiality
Low
Integrity
None
Availability
None
4. PoC
$ docker ps |wc -l
7
$ docker run -ti ubuntu cat /sys/module/overlay/refcnt
7
$ docker run -tid ubuntu bash
78f902370c4bc18b787b95bca5079c052b8b7acd3e43cb7ccff01d8c4c740094
$ docker run -ti ubuntu cat /sys/module/overlay/refcnt
8
5. Fixing Suggestion
Add refcnt to maskedpath by referring to the method of setting maskedpath in Docker.
https://github.com/moby/moby/blob/25.0/oci/defaults.go#L105-L116
MaskedPaths: []string{
"/proc/asound",
"/proc/acpi",
"/proc/kcore",
"/proc/keys",
"/proc/latency_stats",
"/proc/timer_list",
"/proc/timer_stats",
"/proc/sched_debug",
"/proc/scsi",
"/sys/firmware",
"/sys/devices/virtual/powercap",
},
6. Others
Should this issue be confirmed as a vulnerability, I kindly request assistance in obtaining a CVE-ID. I would appreciate it if the credit for this discovery could be assigned to my GitHub ID: ssst0n3. If you require any further assistance, please feel free to contact me at your convenience.
________________________________
Thank you for your time and attention to this matter. We look forward to your response and guidance on the next steps.
Best regards,
LEI WANG
--
To unsubscribe from this group and stop receiving emails from it, send an email to security+unsubscribe(a)opencontainers.org<mailto:security+unsubscribe@opencontainers.org>.
--
To unsubscribe from this group and stop receiving emails from it, send an email to security+unsubscribe(a)opencontainers.org<mailto:security+unsubscribe@opencontainers.org>.
9 months, 4 weeks
Re: [Vulnerability Report] ctr-cnt: Host containers count info leak
by Akihiro Suda
I don't think this is a vuln.
Containers have been leaking loadavg, memory usage, disk usage, and other
resource counters too.
2024年1月25日(木) 18:09 'wanglei (M)' via OCI Security <
security(a)opencontainers.org>:
> Dear Container Security Teams:
>
> I hope this message finds you well. My name is LEI WANG, a container
> security newb. I am writing to report a security vulnerability about host
> containers count info leakage.
> ------------------------------
> 1. Information
>
> *Item*
>
> *Details*
>
> *Note*
>
> Project
>
> docker <https://github.com/moby/moby>
>
> containerd <https://https/github.com/containerd/containerd>
>
> podman <https://github.com/containers/podman>
>
>
>
> crio
>
>
>
> runc <https://github.com/opencontainers/runc>
>
> Due to the widespread impact, we have also copied runc
>
> …
>
> If other container software is affected, please forward the email.
>
> Affect Version
>
> all
>
> CVSS
>
> 4.3 CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N
>
> Author
>
> LEI WANG
>
> Github-ID: ssst0n3 <http://github.com/ssst0n3>
> 2. Original Features
>
> Container runtimes manage the file system using graph drivers such as
> overlay and devicemapper, which are loaded as modules into the kernel.
>
> The container runtime shares the host’s sysfs, where
> /sys/module/<MODULE_NAME>/refcnt represents the reference count of the
> corresponding module. The reference count of these modules typically
> matches the number of mounted file systems on the host, thereby leaking the
> number of running containers on the host.
> 3. Vulnerability
> 3.1 Description
>
> Files such as /sys/module/overlay/refcnt reveal the number of containers
> running on the host because the sysfs of the host is shared when the
> container is running.
> 3.2 Impact
>
> All versions of the all runtime are affected
>
> - docker
> - containerd
> - cri-o
> - podman
> - …
>
> Given the breadth of the impact on the runtime, it may be necessary to
> copy runc.
>
> Disclosure of the number of containers running on a host can provide
> several potential advantages to an attacker:
>
> 1. *Target value assessment*: If an attacker knows that a system is
> running a large number of containers, the system may host multiple services
> or applications, indicating that the target is a high-value target.
>
> 2. *Resource utilization and load information*: The number of
> containers can give attackers some clues about system resource utilization
> and load. For example, a host running a large number of containers may have
> high resource usage, which may allow attackers to use this information to
> launch denial-of-service (DoS) or distributed denial-of-service (DDoS)
> attacks.
>
> 3. *Attack vector identification*: Knowing the number of containers
> may also help attackers infer potential attack vectors. For example, if
> many containers are running, attackers may assume that some of these
> containers may not have proper security configuration or timely software
> updates.
>
> 4. *Penetration policy planning*: Attackers may plan multi-phase
> attacks or select the most likely unhardened container intrusion based on
> the number of containers and their speculation about the system
> architecture.
> 3.3 CVSS
>
> 4.3 CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N
> <https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:...>
>
> *vector*
>
> *score*
>
> *reason*
>
> Attack Vector
>
> Local
>
> Attack Complexity
>
> Low
>
> Privileges Required
>
> None
>
> User Interaction
>
> None
>
> Scope
>
> Changed
>
> Confidentiality
>
> Low
>
> Integrity
>
> None
>
> Availability
>
> None
> 4. PoC
>
> $ docker ps |wc -l
>
> 7
>
> $ docker run -ti ubuntu cat /sys/module/overlay/refcnt
>
> 7
>
> $ docker run -tid ubuntu bash
>
> 78f902370c4bc18b787b95bca5079c052b8b7acd3e43cb7ccff01d8c4c740094
>
> $ docker run -ti ubuntu cat /sys/module/overlay/refcnt
>
> 8
>
> 5. Fixing Suggestion
>
> Add refcnt to maskedpath by referring to the method of setting maskedpath
> in Docker.
>
> https://github.com/moby/moby/blob/25.0/oci/defaults.go#L105-L116
>
> MaskedPaths: []string{
>
> "/proc/asound",
>
> "/proc/acpi",
>
> "/proc/kcore",
>
> "/proc/keys",
>
> "/proc/latency_stats",
>
> "/proc/timer_list",
>
> "/proc/timer_stats",
>
> "/proc/sched_debug",
>
> "/proc/scsi",
>
> "/sys/firmware",
>
> "/sys/devices/virtual/powercap",
>
> },
>
> 6. Others
>
> Should this issue be confirmed as a vulnerability, I kindly request
> assistance in obtaining a CVE-ID. I would appreciate it if the credit for
> this discovery could be assigned to my GitHub ID: ssst0n3. If you require
> any further assistance, please feel free to contact me at your convenience.
> ------------------------------
>
> Thank you for your time and attention to this matter. We look forward to
> your response and guidance on the next steps.
>
> Best regards,
>
> LEI WANG
>
>
>
> --
> To unsubscribe from this group and stop receiving emails from it, send an
> email to security+unsubscribe(a)opencontainers.org.
>
10 months
Podman v4.9.0 Released
by Ashley Cui
We’re excited to announce that Podman v4.9.0 has been released! Here's
what's new:
Features
- The podman farm suite of commands for multi-architecture builds is now
fully enabled and documented.
- Add a network recovery service to Podman Machine VMs using the QEMU
backend to detect and recover from an inoperable host networking issues
experienced by Mac users when running for long periods of time.
Bugfixes
- Fixed a bug where the HyperV provider for podman machine did not
forward the API socket to the host machine.
- Fixed a bug where improperly formatted annotations passed to podman
kube play could cause Podman to panic.
- Fixed a bug where podman system reset could fail if non-Podman
containers (e.g. containers created by Buildah) were present.
Misc
- Containers run in podman machine VMs now default to a PID limit of
unlimited, instead of 2048.
Try it out and let us know what you think!
--
Ashley Cui
10 months
scp'ing a podman image to another host
by Matthias Apitz
I have an image on RH 8.x which runs fine (containing a SuSE SLES and
PostgreSQL server):
$ podman images
REPOSITORY TAG IMAGE ID CREATED SIZE
localhost/suse latest c87c80c0911a 26 hours ago 6.31 GB
registry.suse.com/bci/bci-base 15.4 5bd0e4152d92 2 weeks ago 123 MB
I created a connection to another host as:
$ podman system connection list
Name URI Identity Default
srap57 ssh://apitzm@srap57dxr1.dev.xxxxxx.org:22/run/user/200007/podman/podman.sock true
To the other host I can SSH fine based on RSA public/private keys and
podman is installed there to:
$ ssh apitzm(a)srap57dxr1.dev.xxxxxx.org
Last login: Wed Jan 10 14:05:12 2024 from 10.201.64.28
apitzm@srap57dxr1:~> podman version
Client: Podman Engine
Version: 4.7.2
API Version: 4.7.2
Go Version: go1.21.4
Built: Wed Nov 1 13:00:00 2023
When I now copy over the image with:
$ podman image scp c87c80c0911a srap57::
it transfers the ~6 GByte (I can see them in /tmp as a big tar file of
tar files) and at the end it says:
...
Writing manifest to image destination
$
(i.e. the shell prompt is there again)
But on srap57dxr1.dev.xxxxxx.org I can't see anything of the image at the
end.
What I've done wrong?
Thanks
matthias
--
Matthias Apitz, ✉ guru(a)unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
I am not at war with Russia. Я не воюю с Россией.
Ich bin nicht im Krieg mit Russland.
10 months, 1 week
Running x86_64-based containers on Mac computers with an Apple silicon (M1) processor
by Matthias Apitz
Hello,
For the purpose of the Subject: there is a tutorial at IBM.com:
https://developer.ibm.com/tutorials/running-x86-64-containers-mac-silicon...
I've followed this tutorial, with a small exception, see below.
The first step is to 'init' the machine with:
$ podman machine init --image-path ~/yourFedoraImageFolder/fedora-coreos-39.20231204.3.3-qemu.x86_64.qcow2.xz intel
Extracting compressed file: intel_fedora-coreos-39.20231204.3.3-qemu.x86_64.qco…
Image resized.
Machine init complete
To start your machine run:
podman machine start intel
Which worked fine. Now, before starting the machine, the tutorial asks to remove the following
lines from the config file ~/.config/containers/podman/machine/qemu/intel.json:
"-machine",
"q35,accel=hvf:tcg",
"-cpu",
"host",
These line are not there 1:1 and I removed these lines:
$ diff .config/containers/podman/machine/qemu/intel.json .config/containers/podman/machine/qemu/intel.json.saved2
6a7,12
> "-accel",
> "hvf",
> "-accel",
> "tcg",
> "-cpu",
> "host",
which seems to me correct to remove the HVF QEMU accelerator which only
is supported on x86 chips.
Starting the machine now with:
$ podman machine start intel
Di 16 Jan 2024 12:23:33 CET
Starting machine "intel"
Waiting for VM ...
hangs for ever and the QEMU process has 100% CPU utilization:
top
PID COMMAND %CPU TIME #TH #WQ #PORT MEM PURG CMPRS PGRP
10802 qemu-system- 99.6 23:09.43 8/1 0 27 163M 0B 0B 10800
Any ideas? Thanks
matthias
--
Matthias Apitz, ✉ guru(a)unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
I am not at war with Russia. Я не воюю с Россией.
Ich bin nicht im Krieg mit Russland.
10 months, 1 week
processes running in a podman container are visible on the host
by Matthias Apitz
I've built an own podman image which boots a SuSE Linux, starts a
PostgreSQL dataserver and a SSH daemon to login into. The end of the
Dockerfile says:
...
# Start PostgreSQL server and SSH daemon on container start
#
COPY initSunRise.sh /usr/local/bin/initSunRise.sh
RUN chmod 0755 /usr/local/bin/initSunRise.sh
RUN mkdir /home/sisis/dump ; chown sisis:sisis /home/sisis/dump
COPY testdb.dmp.gz /home/sisis/dump
RUN chown sisis:sisis /home/sisis/dump/testdb.dmp.gz
RUN echo "/etc/init.d/postgres start" >> /usr/local/bin/start.sh
RUN echo "/usr/local/bin/initSunRise.sh" >> /usr/local/bin/start.sh
RUN echo "/usr/sbin/sshd -D" >> /usr/local/bin/start.sh
RUN chmod 0755 /usr/local/bin/start.sh
EXPOSE 22 8076 3045
ENTRYPOINT /usr/local/bin/start.sh
Before it starts the SSH daemon it fires up a shellscript /usr/local/bin/initSunRise.sh
which should fill the PostgreSQL server with a database.
When I now start the image on the server (also a SuSE SLES) with
podman run -p 2022:22 -t suse
Starting PostgreSQL: ok
nohup: appending output to 'nohup.out'
I can SSH into the system on port 2022 and see:
ssh -p 2022 root@srap57dxr1
root(a)srap57dxr1.dev.oclc.org's password:
Last login: Fri Jan 12 08:35:16 2024 from 10.0.2.100
3856d0d6b62d:~ #
3856d0d6b62d:~ # ps ax
PID TTY STAT TIME COMMAND
1 pts/0 Ss+ 0:00 /bin/sh -c /usr/local/bin/start.sh
30 ? S 0:00 /usr/local/sisis-pap/pgsql-15.1/bin/postmaster -D /da
33 ? Ss 0:00 postgres: logger
34 ? Ss 0:00 postgres: checkpointer
35 ? Ss 0:00 postgres: background writer
37 ? Ss 0:01 postgres: walwriter
38 ? Ss 0:00 postgres: autovacuum launcher
39 ? Ss 0:00 postgres: logical replication launcher
45 pts/0 S+ 0:00 sh -c gzip -dc /home/sisis/dump/testdb.dmp.gz | /usr/
46 pts/0 S+ 0:00 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startu
47 pts/0 S+ 0:09 gzip -dc /home/sisis/dump/testdb.dmp.gz
48 pts/0 S+ 0:04 /usr/local/sisis-pap/pgsql/bin/psql -Usisis sisis
49 ? Rs 1:28 postgres: sisis sisis [local] COPY
51 ? Rs 0:08 postgres: autovacuum worker sisis
52 ? Rs 0:00 sshd: root@pts/1
54 pts/1 Ss 0:00 -bash
This looks all fine 47 is the process which decompresses the dump and
pipes it to the proc 48 which is a SQL process loading the data into the
PostgreSQL server. This looks all fine to me and works as expected.
But, when I now to a 'ps ax' on the host server where the 'podman run ...'
runs, I see the same proceses with other PID as they would run on the
host and not in the container:
6322 pts/0 Sl+ 0:00 podman run -p 2022:22 -t suse
6337 pts/0 S 0:00 /usr/bin/slirp4netns --disable-host-loopback --mtu=65520 --enable-sandbox --enable-seccomp --enable-ipv6 -c -r 3 -e 4 --netns-type=path /data/guru/containers/tmp/netns/netns-23da4d70-34da-9034-917b-1e56362a5bbb tap0
6344 pts/0 Sl 0:00 rootlessport
6354 pts/0 Sl 0:00 rootlessport-child
6363 ? Ss 0:00 /usr/bin/conmon --api-version 1 -c 3856d0d6b62d01b46c17c160937ea6e9b8239ec64ce2c8e3ce3b4648652b47dc -u 3856d0d6b62d01b46c17c160937ea6e9b8239ec64ce2c8e3ce3b4648652b47dc -r /usr/bin/runc -b /home/apitzm/.local/share/containers/storage/overlay-containers/3856d0d6b62d01b46c17c160937ea6e9b8239ec64ce2c8e3ce3b4648652b47dc/userdata -p /home/apitzm/.local/share/containers/tmp/overlay-containers/3856d0d6b62d01b46c17c160937ea6e9b8239ec64ce2c8e3ce3b4648652b47dc/userdata/pidfile -n great_bouman --exit-dir /run/user/200007/libpod/tmp/exits --full-attach -l journald --log-level warning --syslog.....
...
6428 pts/0 S+ 0:00 sh -c gzip -dc /home/sisis/dump/testdb.dmp.gz | /usr/local/sisis-pap/pgsql/bin/psql -Usisis sisis >> /home/sisis/err 2>&1 ; /usr/local/sisis-pap/pgsql/bin/psql -Usisis sisis < ~sisis/sc/PosUpdSeq.sql >> /home/sisis/err 2>&1
6429 pts/0 S+ 0:00 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups
6430 pts/0 S+ 0:17 gzip -dc /home/sisis/dump/testdb.dmp.gz
6431 pts/0 S+ 0:06 /usr/local/sisis-pap/pgsql/bin/psql -Usisis sisis
6432 ? Rs 2:09 postgres: sisis sisis [local] COPY
See the gzip proc 6430 and the SQL proc 6431.
Is this correct so by intention that the processes which run in a
container are visible from outside?
Forgive me a maybe stupid question, I'm doing UNIX for 35 years and
podman for 35 days :-)
Thanks
matthias
--
Matthias Apitz, ✉ guru(a)unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
I am not at war with Russia. Я не воюю с Россией.
Ich bin nicht im Krieg mit Russland.
10 months, 1 week
can podman rootless support qemu-user-static for other arch?
by Larry Cai
Hi:
I have a use case to run an ARM based container inside podman on an x86
platform.
see https://github.com/multiarch/qemu-user-static
It works for me using rootful podman env
```
[root@podman-priv /]# podman run --rm --privileged
multiarch/qemu-user-static --reset -p yes[root@podman-priv /]# podman
run --rm -t arm32v6/alpine uname -marmv7l[root@podman-priv /]# podman
run --rm -t arm64v8/fedora uname -maarch64
```
but when I try this in rootless environment (i am not good at
technical detail in low level)
```
$ podman run --rm --privileged docker.io/multiarch/qemu-user-static
--reset -p yes
mount: permission denied (are you root?)
mount: permission denied (are you root?)
```
so my questions:
1. is it possible to enable this for rootless env? if not, can I use
sudo command to run it once
2. is it done in system level or needs to be done for each user if it
is the common env
Rgs, larry
10 months, 1 week
