docker
docker copied to clipboard
lack of security best practices in docker container (chmod 777)
There are files and directories with chmod 777 in the container. chmod 777 or chmod 666 should never be done in production because that means that files can be replaced by any user or application vulnurability in the system! Not even /tmp is chmod 777 for good reasons.
Some files are chmod -R 777 from the entrypoint.sh script. A fact that should be removed as well.
Files in /var/www/html are writeable by the www-data user. Programs on your system should not be able to be modified by the user they are executed with. If an attacker is able to replace a running binaries through vulnerabilities those open permissions can be used to do privilege escalation.
Thank you for your report! Some Friendica files need to be writable by the user executing the script because we are storing temporary files or saving images locally for example. But most don't.
can you give me an example of chmod 777 files/folders except the view/smarty3
folder, which is needed because smarty3 is using this directory for caching as well (which therefore requires the 777 permission)
No, it does not require 777 permission! Nothing requires 777 permission! Ever, Period!
If smarty3 really needs the smarty3 folder for caching it certainly only needs write permissions for smarty3 on that directory not 777.
I usually use find and ps to investigate the insides of my containers with podman-exec. I will come back with more details in the next comment.
Basically as I use docker.io/library/friendica:latest the first thing I do after podman-exec into it is:
root@friendica:/var/www/html# ps -eaf
UID PID PPID C STIME TTY TIME CMD
root 1 0 0 Sep10 ? 00:00:05 apache2 -DFOREGROUND
www-data 93 1 0 Sep10 ? 00:00:11 apache2 -DFOREGROUND
www-data 95 1 0 Sep10 ? 00:00:06 apache2 -DFOREGROUND
www-data 96 1 0 Sep10 ? 00:00:07 apache2 -DFOREGROUND
www-data 97 1 0 Sep10 ? 00:00:09 apache2 -DFOREGROUND
www-data 98 1 0 Sep10 ? 00:00:07 apache2 -DFOREGROUND
www-data 132 1 0 Sep10 ? 00:00:07 apache2 -DFOREGROUND
www-data 291 1 0 Sep10 ? 00:00:05 apache2 -DFOREGROUND
www-data 292 1 0 Sep10 ? 00:00:06 apache2 -DFOREGROUND
www-data 311 1 0 Sep10 ? 00:00:05 apache2 -DFOREGROUND
www-data 312 1 0 Sep12 ? 00:00:00 apache2 -DFOREGROUND
root 313 0 0 20:42 pts/0 00:00:00 bash
root 317 313 0 20:43 pts/0 00:00:00 ps -eaf
The things we learn here is that it is using apache and apache does chown() to www-data as soon as it has claimed port 80. We need that Information later.
Let us have a look for any obvious permissions:
root@friendica:/var/www/html# find / -type d -perm 0777 2>/dev/null
/run/lock/apache2
/run/apache2
/usr/src/friendica/view/smarty3
/var/log/apache2
/var/www/html
/var/www/html/view/smarty3
root@friendica:/var/www/html# find / -type f -perm 0777 2>/dev/null
/var/www/html/view/smarty3/.gitignore
drwxrwxrwx 2 www-data www-data 6 Sep 3 16:26 /run/lock/apache2 This one should be at least chmod 755 ; chown www-data.root however in my opinion chmod 700 ; chown www-data.www-data will work fine as well.
drwxrwxrwx 1 www-data www-data 25 Sep 10 16:09 /run/apache2 run apache containd the pid of the running apache process which is written when apache is still root, so chown root.root ; chmod 755 is what debian sets on this one.
drwxrwxrwx 2 www-data www-data 72 Sep 3 16:26 /var/log/apache2 This should be chown root:adm ; chmod 750 apache2 will open those logs when it is still root. This makes it impossible for processes running as www-data to modify apache logs, making it harder for attackers to hide their footprints.
drwxrwxrwx 1 www-data www-data 430 Sep 10 16:09 /var/www/html This should be chown root:root chmod 755 as with all the files in there chmod 644 readable for the www-data user but not writeable.
Now the Exception: drwxrwxrwx 1 www-data www-data 36 Sep 10 16:20 /var/www/html/view/smarty3 This one really is fine with chown www-data:www-data ; chmod 755 as this is some cached data it could be considered placing it elsewhere in the system. I would do:
find /var/www/html/view/smarty3 -type d -exec chmod 755 {} \;
find /var/www/html/view/smarty3 -type f -exec chmod 644 {} \;
to fix up permissions recursively.
/usr/src/friendica/view/smarty3 regular 755 is ok. It hat a .gitignore file with wrong permissions inside, too.
** /*.sh ** Those files are 775 I dont think that this make a real world difference, but chmod 755 is a bit better, too, I guess.
So far all my findings I hope it helps.
Pinging @tobiasd as this seems interesting for him too.
Thank you for your detailed elaboration! I'll take a deeper look later