[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110304175817.GL24629@florz.florz.dyndns.org>
Date: Fri, 4 Mar 2011 18:58:17 +0100
From: Florian Zumbiehl <florz@...rz.de>
To: Solar Designer <solar@...nwall.com>
Cc: oss-security@...ts.openwall.com,
"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,
> 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.
Well, yeah, what other choice do we have? =:-)
> > (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).
Well, not doing it at all leaves a race condition where the service may
not be able to start or at least to log, lacking a log file, when
started while logrotate is running. At least given how logrotate currently
handles the creation of new log files (rename old file and create new one
afterwards, potentially even with temporarily restricted permissions,
which could also prevent an unprivileged process from opening the newly
created file) ...
Other than that, that doesn't sound unreasonable to me as a design
principle.
> 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.
Which is essentially how I think the fix should work (and it seems
like all parties involved in the discussion so far have agreed on that
in principle, even if not necessarily embracing it fully), though the
current plan is to implement this as a part of logrotate, basically
accepting the expectation that logrotate can be operated securely in
a manner similar to what's currently the case. Practically, that means
that it is planned to add a new config directive that allows to specify
the credentials to be used for manipulating specific sets of log files,
thus obviating the need for separate logrotate invocations but still
letting the kernel take care of separating privileges.
Now, I guess the major motivation for such an approach over executing
logrotate as the unprivileged user directly is backwards compatibility
and how much of a nightmare the transition will be, somehow implicitly
assuming that the similarity with the old mode of operation should
provide for an easier change.
However, this implicit assumption may actually be just that and nothing
more. Namely, there are some ideas how logrotate could guess the
credentials for some common setups when none have been specified in the
config file so as to avoid having to security-patch dozens of packages,
at least as a transitional mechanism. But it's rather unclear whether
any of that will actually work to a sufficient degree to be useful (and
the security of the heuristics to be used is what most of the remaining
contention as to how to fix is about).
If that doesn't work out and you have to patch dozens of packages in
order to change their logrotate configs, you probably may just as well
patch packages to switch to using their own logrotate instance. Or to a
different strategy for logfile handling altogether. In particular so,
given that quite a few of the affected packages in the case of debian
(and I guess it's similar for other distros) do a chown -R on the log
dir in their postinst scripts and thus will need a security patch for
that anyhow.
> > 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?
I guess I don't really have much of an opinion on that. The vulnerabilities
should be fixed, and probably in a way that breaks existing setups as
little as possible, I don't really care which side is declared defective
and subsequently fixed in order to achieve that ;-)
Florian
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.
