Bug#701112: (no subject)
In debian/nginx-common.preinst: # http://bugs.debian.org/701112 if [ `stat -c '%U:%G.%a' /var/log/nginx` == 'root:root.755' ]; then chown root:adm /var/log/nginx chmod 750 /var/log/nginx fi This has been changed. I will create a NEWS entry and push. It will be resolved in the next upload. -- Michael Lustfield -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#701112: (no subject)
On 12/03/13 13:57, Michael Lustfield wrote: > precautionary - That would mean we assume that making the change won't > break anything. We're setting this for new installs but forcing it on > already deployed systems wouldn't be a good idea. We could add a NEWS > entry to recommend making this change. It's definitely not a good idea > to force it to happen. I think there is a duty to fix it on upgrade, otherwise having installed will not be an indication that the system is patched for CVE-2013-0337. Of course if owner/group/permissions were changed in any way since the older nginx package version was installed, I would leave them alone. Otherwise, if removing world read/execute permissions, changing the owner/group to www-data:adm eliminates most risk of anything breaking. The only problem I foresee is the last (unlikely, and inherently secure) example I gave in [#44], where world readable logs are assumed. That could be so easily fixed by adding appropriate users into the adm group, or overriding owner/group/permissions of /var/log/nginx afterward. [#44]: http://bugs.debian.org/701112#44 Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#701112: (no subject)
precautionary - That would mean we assume that making the change won't break anything. We're setting this for new installs but forcing it on already deployed systems wouldn't be a good idea. We could add a NEWS entry to recommend making this change. It's definitely not a good idea to force it to happen. On Tue, Mar 12, 2013 at 7:53 AM, Steven Chamberlain wrote: > Hi, > > On 12/03/13 03:33, Michael Lustfield wrote: > > In debian/nginx-common.postinst we have: > > > > configure) > > logdir="/var/log/nginx" > > # Ensure existance and right state of log files and directory > > if [ ! -d "$logdir" -a ! -L "$logdir" ]; then > > mkdir "$logdir" > > chown www-data:adm $logdir > > chmod 0750 $logdir > > fi > > > This should create the log directory if it doesn't already exist. We're > not > > enforcing this because the permissions could be changed. Is there any > better > > way to handle this than what we're doing now? I haven't tested, but it > seems > > that this should work. I'm sure I'm missing something... > > Else if it already exists as a directory, and are upgrading from package > version 1.2.1-2.2 or earlier, do a precautionary `chmod o-rx`? > > If ownership is still 'root:root', should chown to 'www-data:adm' so > that log parsers retain access. Maybe a NEWS entry could advise about > adding things into that group if they don't run as root or www-data but > still need to be able to read the nginx logs? > > > Some test cases I can think of are: > > * no log parsers in use - chmod o-rx is the important thing to do > > * logwatch - runs as root? changing the ownership/perms doesn't matter > > * awstats - the log parser part (update.sh) runs as user www-data > > * other CGI/PHP apps running as user www-data > > * other CGI/PHP apps running under separate uids - should be added to a > group that has read access. If the admin already changed the user or > group of /var/log/nginx, respect that, otherwise chgrp to adm and > suggest they add their log parsers into that group if necessary. The > alternative would be to just keep wide-open access... > > > Wide-open HTTP logs could be a breach of privacy, reveals usernames for > HTTP authentication, IP addresses of visitors, search queries or other > HTML form input with a GET action, locations of potentially sensitive > documents that would be otherwise impractical to guess, and provides a > catalogue of installed web apps that would likely assist an attacker if > this were some kind of shared host with other users. > > Thanks, > Regards, > -- > Steven Chamberlain > ste...@pyro.eu.org >
Bug#701112: (no subject)
Hi, On 12/03/13 03:33, Michael Lustfield wrote: > In debian/nginx-common.postinst we have: > > configure) > logdir="/var/log/nginx" > # Ensure existance and right state of log files and directory > if [ ! -d "$logdir" -a ! -L "$logdir" ]; then > mkdir "$logdir" > chown www-data:adm $logdir > chmod 0750 $logdir > fi > This should create the log directory if it doesn't already exist. We're not > enforcing this because the permissions could be changed. Is there any better > way to handle this than what we're doing now? I haven't tested, but it seems > that this should work. I'm sure I'm missing something... Else if it already exists as a directory, and are upgrading from package version 1.2.1-2.2 or earlier, do a precautionary `chmod o-rx`? If ownership is still 'root:root', should chown to 'www-data:adm' so that log parsers retain access. Maybe a NEWS entry could advise about adding things into that group if they don't run as root or www-data but still need to be able to read the nginx logs? Some test cases I can think of are: * no log parsers in use - chmod o-rx is the important thing to do * logwatch - runs as root? changing the ownership/perms doesn't matter * awstats - the log parser part (update.sh) runs as user www-data * other CGI/PHP apps running as user www-data * other CGI/PHP apps running under separate uids - should be added to a group that has read access. If the admin already changed the user or group of /var/log/nginx, respect that, otherwise chgrp to adm and suggest they add their log parsers into that group if necessary. The alternative would be to just keep wide-open access... Wide-open HTTP logs could be a breach of privacy, reveals usernames for HTTP authentication, IP addresses of visitors, search queries or other HTML form input with a GET action, locations of potentially sensitive documents that would be otherwise impractical to guess, and provides a catalogue of installed web apps that would likely assist an attacker if this were some kind of shared host with other users. Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#701112: (no subject)
In debian/nginx-common.postinst we have: configure) logdir="/var/log/nginx" # Ensure existance and right state of log files and directory if [ ! -d "$logdir" -a ! -L "$logdir" ]; then mkdir "$logdir" chown www-data:adm $logdir chmod 0750 $logdir fi This should create the log directory if it doesn't already exist. We're not enforcing this because the permissions could be changed. Is there any better way to handle this than what we're doing now? I haven't tested, but it seems that this should work. I'm sure I'm missing something... -- Michael Lustfield -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
