Bug 1397647

Summary:	inconsistent/dangerous permissions on /var/log/nginx
Product:	Red Hat Software Collections	Reporter:	Doran Moppert <dmoppert>
Component:	nginx	Assignee:	Luboš Uhliarik <luhliari>
Status:	CLOSED NOTABUG	QA Contact:	BaseOS QE - Apps <qe-baseos-apps>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rh-nginx110	CC:	bperkins, jorton, thoger
Target Milestone:	beta
Target Release:	2.4
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-03-17 14:19:17 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Doran Moppert 2016-11-23 04:40:16 UTC

/var/log/nginx is owned by nginx:nginx, but files in there are created/opened as root:root by the supervisory process on startup.

This represents a possible privilege escalation from nginx to root.  Product Security has rated this as Low security impact (bug 1390182), but a permissions review for future packages is in order.

See also:  https://legalhackers.com/advisories/Nginx-Exploit-Deb-Root-PrivEsc-CVE-2016-1247.html

Comment 2 Joe Orton 2017-03-17 14:19:17 UTC

So far as I can tell this is a product of the nginx design.  nginx assumes that unprivileged child processes can open logs as writeable.  Note from http://nginx.org/en/docs/control.html -

""
Rotating Log-files

In order to rotate log files, they need to be renamed first. After that USR1 signal should be sent to the master process. The master process will then re-open all currently open log files and assign them an unprivileged user under which the worker processes are running, as an owner. After successful re-opening, the master process closes all open files and sends the message to worker process to ask them to re-open files. Worker processes also open new files and close old files right away. As a result, old files are almost immediately available for post processing, such as compression.
""

There is obviously a trade-off between a less flexible but more secure design for logging (as used by httpd), and a more flexible but less secure as used by nginx.  It does not appear that upstream treat this as a bug, so I don't see why we should.

Comment 3 Tomas Hoger 2017-03-17 14:33:02 UTC

It does not seem to me that the quoted part of the documentation explains why *the directory* should be writable to nginx user.  It says that the privileged master process creates log files and chowns them nginx user.  That should be enough for worker process to open/write them without needing write access to the directory.