Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

lack of security best practices in docker container (chmod 777) #165

Open
zem opened this issue Sep 10, 2021 · 5 comments
Open

lack of security best practices in docker container (chmod 777) #165

zem opened this issue Sep 10, 2021 · 5 comments
Assignees

Comments

@zem
Copy link

zem commented Sep 10, 2021

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.

@zem zem changed the title severe lack of security best practices in docker container lack of security best practices in docker container (chmod 777) Sep 10, 2021
@MrPetovan
Copy link
Collaborator

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.

@nupplaphil
Copy link
Collaborator

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)

@zem
Copy link
Author

zem commented Sep 13, 2021

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.

@zem
Copy link
Author

zem commented Sep 13, 2021

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.

@nupplaphil
Copy link
Collaborator

Pinging @tobiasd as this seems interesting for him too.

Thank you for your detailed elaboration! I'll take a deeper look later

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants