Date: Fri, 4 Mar 2011 19:16:40 +0300 From: Solar Designer <solar@...nwall.com> To: Florian Zumbiehl <florz@...rz.de>, oss-security@...ts.openwall.com Cc: "Steven M. Christey" <coley@...us.mitre.org>, Stefan Fritsch <sf@...itsch.de>, Jan Kaluza <jkaluza@...hat.com>, Paul Martin <pm@...ian.org>, Petr Uzel <petr.uzel@...e.cz>, Thomas Biege <thomas@...e.de>, Jan Lieskovsky <jlieskov@...hat.com> Subject: Re: CVE Request -- logrotate -- nine issues Hi Florian - Thank you for explaining your rationale behind this. Here's my take on it: On Fri, Mar 04, 2011 at 04:14:00PM +0100, Florian Zumbiehl wrote: > In which scenarios exactly logrotate is supposed to be safe to use is > mostly undefined. Maybe. We just need to (hopefully) agree on what is common, expected, correct - and this may be changing over the years. Apply our common sense and experience. > However, it is currently a common setup (as in: what distributions do out > of the box) to have a daily logrotate cron job run as root that rotates > the logs of all the services and to have log directories owned by service > users Arguably, these are bugs in those service packages, which I'd call vulnerabilities. At least that's the policy for Owl (our Linux distro) so far. We don't have any service-writable log file directories. I reported one of those issues against nginx-0.6.39-2.el5 (a Red Hat distro package) to the package maintainer a year ago, and was told the issue was fixed in response to my report (by chown'ing the nginx logs directory). IMO, such a fix was the only right thing to do. > (so they can create missing log files, for example). I think that services should either do that before they drop root at startup, or they should not do it at all (leave it to logrotate). However, if it's somehow desired that a service running as non-root be able to create log files (other than just at startup?), then the correct approach would be to run a dedicated instance of logrotate for that service under the service pseudo-user. Don't mix the pseudo-user and root for the same task (dealing with log files of the same service), which creates unnecessary risks. > In such setups, the service user can elevate its privileges to root > or corrupt root-owned files using the various bugs. Indeed. A vulnerability in the service package, in my opinion. Now that would require CVE id assignment and a fix to the package, whereas logrotate could merely use some hardening with no CVE ids (except for issue #8, which was different). What do you say? Alexander
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.