Open Stack

On 20 November 2015 at 18:32, Ben Nemec <openstack at nemebean.com> wrote:

> On 11/19/2015 06:00 AM, Lucas Alvares Gomes wrote:
> > Hi,
> >
> >> Also keep in mind that DEBUG logging, while still should have some
> masking
> >> of data, since it is explicitly called out (or should be) as not safe
> for
> >> production, can contain some " sensitive" data. Credentials should
> still be
> >> scrubbed, but I would say the swift temp URL is something that may line
> up
> >> with this more flexible level of filtering logs.
> >>
> >> Now, if the service (and I don't think ironic suffers from this issue)
> is
> >> only really runnable with debug on (because there is no useful
> information
> >> otherwise) then I would aim to fix that before putting even potentially
> >> sensitive data in DEBUG.
> >>
> >> The simple choice is if there is even a question, don't log it (or log
> it in
> >> a way that obscures the data but still shows unique use).
> >>
> >
> > I agree with Morgan's statement here.
> >
> > And just throwing an idea in the wind here, we could make use of the
> > python logging filters to create a filter for sensitive information.
> > We probably need one already to avoid having to do things like [1] in
> > the code.
>
> We actually have a thing to do that:
>
> https://github.com/openstack/oslo.utils/blob/master/oslo_utils/strutils.py#L215
>
> You might need to add a new key to the list of things to mask, but I
> think it should be able to handle masking the log message for you.  I
> don't know whether configdrive is a globally sensitive key, but if not
> then we probably need to revisit the question of whether to allow
> extending the key list dynamically in the consuming application instead
> of having only the one hard-coded list.  More context here:
> https://bugs.launchpad.net/oslo.utils/+bug/1407811
>
>
The problem is that the developer WANTS to see the temporary URL, so
masking it defeats the whole purpose.

The only thing I was thinking of (besides the developer modifying their
code to spit it out) is to have some additional level of debugging that
doesn't filter anything sensitive and/or add a config in ironic to log
'only-in-non-production-environments-shows-sensitive-info' with some big
warning...

My take on this (thanks everyone) is that it is a potential security risk
to expose the URL in the logging, so we shouldn't allow it without some
other way (besides expecting/documenting INFO level or higher) to prevent
it from showing up in production.

--ruby
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151123/7b8fc1e3/attachment.html>