[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110304161640.GA25667@openwall.com>
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.
