Docker security - Revision history

Mike at 14:07, 21 March 2023

2023-03-21T14:07:58Z

← Older revision		Revision as of 14:07, 21 March 2023
Line 22:		Line 22:
	<pre>		<pre>
	{		{
	"userns-remap": "dockeruser"		"userns-remap": "dockeruser",
			"log-driver": "journald",
			"log-opts": {
			"tag": "{{.Name}}"
			},
			"bip": "172.19.0.1/16",
			"dns" : [ "8.8.6.6" , "8.8.8.8" ]
	}		}
	</pre>Where you force a namsspace onto docker, where it runs as the user named - dockeruser, and as no more priviliges than a normal user.		</pre>Where you force a namsspace onto docker, where it runs as the user named - dockeruser, and as no more priviliges than a normal user.

Mike at 12:14, 4 January 2023

2023-01-04T12:14:21Z

← Older revision		Revision as of 12:14, 4 January 2023
Line 15:		Line 15:


	Always remember that Docker is NOT virtualization, and it runs in scope of your system.. ~~I have~~ not ~~yet found any mechanism for preventing system~~ access, ~~though name spaces~~ may ~~resolve this~~.
			Always remember that Docker is NOT virtualization, and it runs in scope of your system..

			A solutino to this is to create the file /etc/docker/daemon.json containing

			<pre>
			{
			"userns-remap": "dockeruser"
			}
			</pre>Where you force a namsspace onto docker, where it runs as the user named - dockeruser, and as no more priviliges than a normal user.

			However you also need to create the user by<pre>
			useradd dockeruser
			</pre>And then validate that the correct entries are created in /etc/subuid, and /etc/subgid<pre>
			# grep dockeruser /etc/subuid
			dockeruser:1476256:65536
			# grep dockeruser /etc/subgid
			dockeruser:1476256:65536
			</pre>However all volumes will need to be owned by the above UID, or they will not be able to access the files..

			Thus you will need to apply the following on each volume<pre>
			chown -R 1476256:1476256 .
			</pre>In my case with the above /etc/subuid, and /etc/subgid.

			Now the same test as above fails.<pre>
			# docker run --rm -v /etc:/mnt/etc/ httpd:2.4 cat /mnt/etc/shadow
			cat: /mnt/etc/shadow: Permission denied
			</pre>As it should..

			However Namespaces are relatively new implementations, and they're not complete, and therefore it may be circumventable.

			This is however a much better situation than before.

			Do not let people get access to docker unless you trust them, or the machine is nothing important, and can easily be recreated.

Mike at 10:52, 4 January 2023

2023-01-04T10:52:25Z

← Older revision		Revision as of 10:52, 4 January 2023
Line 13:		Line 13:

	Thus you must remember that any memer of the "docker" group, is per defintiion now root on your system.		Thus you must remember that any memer of the "docker" group, is per defintiion now root on your system.


			Always remember that Docker is NOT virtualization, and it runs in scope of your system.. I have not yet found any mechanism for preventing system access, though name spaces may resolve this.

Mike at 10:51, 4 January 2023

2023-01-04T10:51:11Z

← Older revision		Revision as of 10:51, 4 January 2023
Line 4:		Line 4:

	<pre>		<pre>
	mike@Server~~.ttsh.dk~~:~/docker$ docker run --rm -v /etc:/mnt/etc/ httpd:2.4 cat /mnt/etc/shadow		mike@Server:~/docker$ docker run --rm -v /etc:/mnt/etc/ httpd:2.4 cat /mnt/etc/shadow
	root:(obfuscated by author)::0:99999:7:::		root:(obfuscated by author)::0:99999:7:::
	bin:*:18358:0:99999:7:::		bin:*:18358:0:99999:7:::

Mike at 10:50, 4 January 2023

2023-01-04T10:50:41Z

← Older revision		Revision as of 10:50, 4 January 2023
Line 9:		Line 9:
	daemon:*:18358:0:99999:7:::		daemon:*:18358:0:99999:7:::
	</pre>		</pre>

			This should NEVER be possible for a user to access private files, a simpilar proces could be used to create a new root user, with a known password, thus elevating a user to root user.

			Thus you must remember that any memer of the "docker" group, is per defintiion now root on your system.

Mike: Security issues using docker in a multiuser environment.

2023-01-04T10:49:20Z

Security issues using docker in a multiuser environment.

New page

Docker is actually a major security risk on a system where you allow users to start and stop docker containers. A docker container per default uses root as the running user, and thus starting a docker container using some trickeries as a normal user, will compromise system security..

For instance if I wish to compromise system passwords, I can simply do

<pre>
mike@Server.ttsh.dk:~/docker$ docker run --rm -v /etc:/mnt/etc/ httpd:2.4 cat /mnt/etc/shadow
root:(obfuscated by author)::0:99999:7:::
bin:*:18358:0:99999:7:::
daemon:*:18358:0:99999:7:::
</pre>