{
	"id": "454f8e5c-3cfa-4805-9fd6-eb6dd805daf1",
	"created_at": "2026-04-06T00:17:43.605096Z",
	"updated_at": "2026-04-10T03:20:42.152765Z",
	"deleted_at": null,
	"sha1_hash": "9f1f18c0df32cae7c6cb8e283e533db9f2448e1b",
	"title": "Why A Privileged Container in Docker Is a Bad Idea",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1469019,
	"plain_text": "Why A Privileged Container in Docker Is a Bad Idea\r\nBy By: David Fiser, Alfredo Oliveira Dec 20, 2019 Read time: 7 min (1974 words)\r\nPublished: 2019-12-20 · Archived: 2026-04-05 17:44:59 UTC\r\nPrivileged containers in Docker are, concisely put, containers that have all of the root capabilities of a host\r\nmachine, allowing the ability to access resources which are not accessible in ordinary containers. One use case of\r\na privileged container is running a Docker daemon inside a Docker container; another is where the container\r\nrequires direct hardware access. Originally, Docker-in-Docker was introduced for the development of Docker\r\nitself. Today, there are various use cases for running privileged containers, such as automating continuous\r\nintegration and delivery (CI/CD) tasks in the open-source automation server Jenkins. However, running privileged\r\ncontainers are not necessarily secure. In this blog post, we will explore how running a privileged yet unsecure\r\ncontainer may allow cybercriminals to gain a backdoor in an organization’s system.\r\nThe problems with privileged containers\r\nGenerally, Docker-in-Docker is used when there is a need to spawn another container while running an existing\r\ncontainer. However, there are some serious implications to using privileged containers without securing them.\r\nRunning a container with privileged flag allows internal teams to have critical access to the host’s resources — but\r\nby abusing a privileged container, cybercriminals can gain access to them as well. When an attacker abuses a\r\nprivileged container for an attack, it does not necessarily entail remote code execution. But when they do execute\r\ncode, the potential attack surface is wide. . As the privileged container is spawned because of the need for\r\nenhanced permissions, there is a large chance that an attacker will be able to run code as root. This implies that an\r\nattacker will be able to run full host root with all of the available capabilities, including  CAP_SYS_ADMIN. It’s\r\nnotable to mention that other isolation techniques such as cgroups, AppArmor, and SECcomp  are renounced or\r\ndisabled.\r\nFor malicious actors who gain access to exposed privileged containers, the possibilities for abuse are seemingly\r\nendless. Attackers can identify software running on the host to find and exploit vulnerabilities. They can also\r\nexploit container software vulnerabilities or misconfigurations, such as containers with weak credentials or no\r\nauthentication. Because an attacker has root access, malicious code or coin miners can be executed and effectively\r\nhidden.\r\nKeeping containers isolated\r\nA container, which contains an application’s fundamental components, is essentially an isolated environment. To\r\nbe able to isolate multiple processes running inside a single host, the container engine uses various kernel features.\r\nSince Docker containers run on top of a Linux environment, resource isolation features of the Linux kernel are\r\nused for them to run independently. One of these is called Linux namespaces. Table 1 shows the types of\r\nnamespaces.\r\nhttps://www.trendmicro.com/en_us/research/19/l/why-running-a-privileged-container-in-docker-is-a-bad-idea.html\r\nPage 1 of 6\n\nNamespace Use\r\nMNT (Mount) Manages file system mount points\r\nPID (Process) Isolates processes\r\nNET (Network) Manages network interfaces\r\nIPC (Inter-process communication) Manages access to IPC resources\r\nUTS (Host name) Isolates kernel and version identifiers\r\nCGROUPS Limits, isolates, and measures resource usage of several processes\r\nUser ID (User) Provides privilege isolation and user identification segregation\r\nTable 1. Types of Linux namespaces\r\nBy default, a Docker daemon, as well as a container process, runs with root permission. Creating another user and\r\nlowering permissions are still possible and are highly recommended from a security perspective.\r\nIn the case of privileged containers, having root access inside the container also means having root access in the\r\nhost. It should be noted, though, that the container process has a limited set of capabilities by default, as detailed\r\nin Table 2. However, privileged containers have all capabilities.\r\nCapability Permitted Operation\r\nCAP_AUDIT_WRITE Write records to the kernel’s auditing log\r\nCAP_CHOWN (Change owner)\r\nMake arbitrary changes to file UIDs and GIDs; change the owner and\r\ngroup of files, directories, and links\r\nCAP_DAC_OVERRIDE\r\n(Discretionary access control)\r\nBypass a file’s read, write, and execute permission checks\r\nCAP_FOWNER\r\nBypass permission checks on operations that normally require the file\r\nsystem UID of the process to match the UID of the file, excluding checks\r\nwhich are covered by CAP_DAC_OVERRIDE and\r\nCAP_DAC_READ_SEARCH\r\nCAP_FSETID\r\nWill not clear set-user-ID and set-group-ID mode bits even when a file is\r\nchanged\r\nCAP_KILL Bypass permission checks for sending signals\r\nCAP_MKNOD Create special files\r\nCAP_NET_BIND_SERVICE\r\nBind a socket to internet domain privileged ports (port numbers below\r\n1024)\r\nhttps://www.trendmicro.com/en_us/research/19/l/why-running-a-privileged-container-in-docker-is-a-bad-idea.html\r\nPage 2 of 6\n\nCAP_NET_RAW\r\nUse RAW and PACKET sockets and binds to any address for transparent\r\nproxying\r\nCAP_SETGID  \r\nMake arbitrary manipulations of process GIDs and supplementary GID\r\nlist\r\nCAP_SETPCAP\r\nIf file capabilities are supported (i.e., since Linux 2.6.24): add any\r\ncapability from the calling thread's bounding set to its inheritable set;\r\ndrop capabilities from the bounding set; make changes to the secure bits\r\nflags.   If file capabilities are not supported (i.e., kernels before Linux\r\n2.6.24): grant or remove any capability in the caller's permitted capability\r\nset to or from any other process\r\nCAP_SETUID  \r\nMake arbitrary manipulations of process UIDs, forge UID when passing\r\nsocket credentials via UNIX domain sockets, and write a user ID\r\nmapping in a user namespace\r\nCAP_SYS_CHROOT Use chroot and changes namespaces using setns.\r\nTable 2. Capabilities of a container run as root\r\nFor better security, Docker provides an option to run a container process under non-root user, using a USER\r\ndirective inside a Dockerfile. It should be noted that it is not using user namespaces, which allow the separation\r\nof the host’s root user and the container’s root user, by default. User namespaces can be configured in the Docker\r\ndaemon and may be used for many situations where root access would otherwise be needed. See Figure 1 and note\r\nthe numbers inside the square brackets.\r\nFigure 1. Screen capture that shows that user namespaces are not used by default\r\nHence, Docker does not use user namespaces until it is otherwise explicitly specified by the --userns-remap flag.\r\nInside the user namespace, the process can be granted with full operations privileges, but outside the user\r\nnamespace, the process is not. This means that outside a user namespace, a process can have an unprivileged user\r\nID, while inside it, it can have a user ID of 0.\r\nhttps://www.trendmicro.com/en_us/research/19/l/why-running-a-privileged-container-in-docker-is-a-bad-idea.html\r\nPage 3 of 6\n\nThis means that even if a process is running inside a new user namespace with CAP_SYS_ADMIN available and\r\nthe action taken requires elevated privileges, for example, installing a kernel module, then a parent user\r\nnamespace — which does not run under root user and does not have the required capability — is also checked for\r\nthe required privilege. If it is not found, then the whole action is denied.\r\nIt should be noted that while --userns-remap provides security enhancement, it is not the same as rootless docker,\r\nwhich is still an experimental feature at the time of writing. The Docker daemon, a parent container process, still\r\nruns under root.\r\nAttacks using privileged containers\r\nWith the capabilities of privileged containers, attackers can spawn them to try and gain root access to a user’s host\r\nenvironment.\r\nRecently we saw malicious activity in one of our honeypots showing attackers attempting to put their own SSH\r\npublic keys inside the host’s /root/authorized_keys via their spawned privileged container.\r\nFigure 2. Screen capture of a maliciously spawned privileged container’s code\r\nUpon further analysis, we discovered that the container the attackers spawned used the “/mnt” bind to attempt to\r\nbind it to the host root “/”. After which, we observed that the following commands were executed:\r\n\"Cmd\":[\"sh\",\"-c\",\"mkdir -pv /mnt/root/; mkdir -pv /mnt/root/.ssh/; ls -ld /mnt/root/.ssh/; chattr -i -a\r\n/mnt/root/.ssh/ /mnt/root/.ssh/authorized_keys\"]\r\nRemove immutable attributes and append those that are from the /mnt/root/.ssh and\r\n/mnt/root/.ssh/authorized_keys\r\nFigure 3. Screen capture showing the commands executed in the spawned privileged container\r\nIt should be noted that while the code in Figure 3 shows “Privileged: false,” because the new process is executed\r\nwithin the privileged container context, its capabilities match those of a previously spawned privileged container.\r\nBased on our analysis, the “/”,”/mnt/root” bind is equivalent to -v /:/mnt/root inside Docker CLI and the host’s\r\nfile system is accessible.\r\nThe attackers also tried to overwrite the authorized_keys file in SSH, as we can see from the API request shown in\r\nFigure 4.\r\nhttps://www.trendmicro.com/en_us/research/19/l/why-running-a-privileged-container-in-docker-is-a-bad-idea.html\r\nPage 4 of 6\n\nFigure 4. Screen capture of attempts to overwrite the authorized_keys\r\nThrough these examples, it’s apparent that despite the innate isolation, there are situations wherein cybercriminals\r\ncan escape the isolated containers and gain access to the host machine’s resources and make the user’s\r\ninfrastructure open to attacks.\r\nDocker’s --privileged flag effectively disables all isolation features. The containers may have different PID and\r\nMNT namespaces as well as cgroups profiles applied. But with the --privileged flag running on a Docker\r\ncontainer, a user — and inadvertently, an attacker — has access to the hard drives attached to the host.\r\nThe --privileged flag, together with root access, gives an attacker plenty of options on how to escape a “jailed”\r\nenvironment:\r\nMounting /dev/sda1 or a similar equivalent, allowing access to the host storage unit\r\nls –la /dev/\r\nmkdir /hdd \u0026 mount /dev/sda1 /hdd\r\nUsing cgroups notify_on_release and release_agent to spawn a shell within the host root\r\nDeploying a custom kernel module, with persistence on the host (e.g., reverse shell)\r\nSecurity recommendations for privileged Docker containers\r\nInterestingly, Tõnis Tiigi described an experimental rootless Docker mode that aims to allow users to run Docker\r\ndaemon without needing to have root privileges. Through the rootless mode, even if cybercriminals are able to\r\ninfiltrate the Docker daemon and containers, they will not have root access to the host.\r\nBeing in its early stages, the rootless mode does not support the complete Docker suite of features. Currently, the\r\nfollowing are not supported:\r\nCgroups (including docker top, which depends on the cgroups)\r\nAppArmor\r\nCheckpoint\r\nOverlay network\r\nExposing SCTP ports\r\nhttps://www.trendmicro.com/en_us/research/19/l/why-running-a-privileged-container-in-docker-is-a-bad-idea.html\r\nPage 5 of 6\n\nHowever, the rootless mode should be sufficient for many use cases that are unlikely to use these features,\r\nincluding builds in Jenkins.\r\nContainers are helpful for organizations who want to keep up with ever-increasing organizational demands. As\r\nmore and more businesses adopt the use of containers, more and more cybercriminals are banking on security\r\ngaps in such useful tools to advance their nefarious agenda.\r\nThough there is indeed a legitimate use for privileged containers, developers should exercise caution and restraint\r\nin using them. After all, privileged containers can be used as entry points for attacks and to spread malicious code\r\nor malware to compromised hosts.\r\nHowever, this doesn't mean that privileged containers should absolutely not be used. Organizations just need to\r\nmake sure that safeguards are set in place when running such containers in their environments.\r\nHere are some security recommendations for using privileged containers:\r\n1. Implement the principle of least privilege. Access to critical components like the daemon service that helps\r\nrun containers should be restricted. Network connections should also be encrypted.\r\n2. Containers should be configured so that access is granted only to trusted sources, which includes the\r\ninternal network. This includes implementing proper authentication procedures for the containers\r\nthemselves.\r\n3. Follow recommended best practices. Docker provides a comprehensive list of best practices and has built-in security features professionals can take advantage of, such as configuring Linux hosts to work better\r\nwith Docker via post-installation.\r\n4. Carefully assess needs. Does the use case absolutely have to run in Docker? Are there other container\r\nengines that do not run with root access and can do the job as effectively? Can it be done differently? Do\r\nyou accept the risks associated with this need?\r\n5. Security audits should be performed at regular intervals to check for any suspicious containers and images.\r\nTrend Micro helps DevOps teams to build securely, ship fast, and run anywhere. The Trend Micro™ Hybrid\r\nCloud Security solution provides powerful, streamlined, and automated security within the organization’s DevOps\r\npipeline and delivers multiple XGen™ threat defense techniques for protecting runtime physical, virtual, and\r\ncloud workloads.\r\nIt also adds protection for containers via the Trend Micro Deep Security™ solution, which has a Container\r\nControl feature which allows users to run containers based on parameters that users will configure. Additionally,\r\nDeep Security Smart Check scans Docker container images for malware and vulnerabilities at any interval in the\r\ndevelopment pipeline to prevent threats before they are deployed.\r\nSource: https://www.trendmicro.com/en_us/research/19/l/why-running-a-privileged-container-in-docker-is-a-bad-idea.html\r\nhttps://www.trendmicro.com/en_us/research/19/l/why-running-a-privileged-container-in-docker-is-a-bad-idea.html\r\nPage 6 of 6",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://www.trendmicro.com/en_us/research/19/l/why-running-a-privileged-container-in-docker-is-a-bad-idea.html"
	],
	"report_names": [
		"why-running-a-privileged-container-in-docker-is-a-bad-idea.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775434663,
	"ts_updated_at": 1775791242,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/9f1f18c0df32cae7c6cb8e283e533db9f2448e1b.pdf",
		"text": "https://archive.orkl.eu/9f1f18c0df32cae7c6cb8e283e533db9f2448e1b.txt",
		"img": "https://archive.orkl.eu/9f1f18c0df32cae7c6cb8e283e533db9f2448e1b.jpg"
	}
}