On 03.01.2011 16:05, Piotr K. wrote:
master process running as root open/write files in /var/log/nginx
- if nginx user have write permissions to this directory,
700 nginx:nginx - such setup is vulnerable by symlink attack
better approach set permissions 750 root:nginx /var/log/nginx
or 750 root:www-logs /var/log/nginx and add user nginx to group www-logs
Now when you mention it, if nginx worker have read perms there (as you
suggested above), then if user symlink to any log, he will be able fetch
it via nginx which is security hole.
nginx was primary developed on FreeBSD, and FreeBSD mount has option
-o nosymfollow - Do not follow symlinks on the mounted file system.
so, user vhosts on FreeBSD can be located on file system mounted
with -o nosymfollow option, and there is no security hole in this case.
but if nginx log files will have permissons nginx:root 244
in this case nginx worker processes can only write(append)
to log files, and can’t read anything from it, even via symlink -
it this case 403 Forbidden will be returned to access via symlink.
but nginx source need to be patched for 244 logfile permissions,
and this is can’t be done via logrotate create 0244 nginx root
directive, because nginx master process after USR1 signal
explicitly reset logfiles permissioons to S_IRUSR|S_IWUSR
other approach - set permissions to 0700 root:root
and always use slow reload configuration operation
instead of fast log files reopening via USR1 signal.
nginx workers also write to log files.
In what cases?
in many cases, when it need write something to access/error log files.
And direct or somehow ‘via master proicess’?
direct.
You need at least 711, otherwise workers won’t be able to open
files in that directory.
So nginx’ workers need exec permission on logdir?
yes.
Exec on dir will allow only chdir there, why worker have to chdir there?
allow chdir and “access files in that directory by name”.
nginx workers open log files only for append, and never for read.
The only problem is that after SIGUSR1 nginx worker need access to
logs (shouldn’t), where on restart/reload nginx can handle it without
access to logs by workers, which as I said above, is [in my opinion]
security hole.
Igor say in russian mail list:
http://nginx.org/pipermail/nginx-ru/2010-December/038658.html
in my translation:
“open log files by the master process and transmit descriptors
to workers, not changing the permissions, - it’s for nginx 2.0”
–
Best regards,
Gena
