-
Notifications
You must be signed in to change notification settings - Fork 19
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
Comments
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 |
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:
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:
drwxrwxrwx 2 www-data www-data 6 Sep 3 16:26 /run/lock/apache2 drwxrwxrwx 1 www-data www-data 25 Sep 10 16:09 /run/apache2 drwxrwxrwx 2 www-data www-data 72 Sep 3 16:26 /var/log/apache2 drwxrwxrwx 1 www-data www-data 430 Sep 10 16:09 /var/www/html Now the Exception:
to fix up permissions recursively. /usr/src/friendica/view/smarty3 ** /*.sh ** 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 |
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.
The text was updated successfully, but these errors were encountered: