Open Stack

On 06/12/2014 12:37 AM, Kuvaja, Erno wrote:
> Hi all,
> 
>  
> 
> I do agree with Bryan that it would be better not to log point 2 at all
> and I would suggest that if we provide this functionality to turn such
> on we should also make those logs at that point root/admin readable only.

I would really prefer that we just don't have an option to allow logging
of things like credentials (passwords/tokens) in the first place.  This
seems like something that we should be firmly against.

> 
>  
> 
> I would also like to add an item to Sensitive/Confidential data list.
> One should never log any URI or full request object. These might contain
> user sensitive information like credentials, data locations etc.
> 
>  
> 
> Just a side note on the log levels. Lots of OPS are telling that
> currently getting anything valuable from the logs, they need to run the
> services on DEBUG log level. Based on this I really like the statement
> that DEBUG level should still never compromise the security of the
> information.

+1.

> 
>  
> 
> -          Erno (LP: jokke)
> 
>  
> 
> *From:*Bryan D. Payne [mailto:bdpayne at acm.org]
> *Sent:* 11 June 2014 17:00
> *To:* Paul Montgomery
> *Cc:* openstack-security at lists.openstack.org
> *Subject:* Re: [Openstack-security] Secure Logging Recommendations
> 
>  
> 
> Paul,
> 
>  
> 
> I really like this.  Here's a few additional thoughts:
> 
>  
> 
> 1) On the implementation side, doing this in Oslo seems like a good
> plan.  At least doing as much of the security sensitive filtering stuff
> there.  This is something we are basically asking all projects to do, so
> Oslo is the right answer.
> 
>  
> 
> 2) On this point:
> 
>  
> 
> "If confidential/sensitive data MUST be logged for root cause analysis,
> create an Oslo Config setting that disables security features, vividly
> informs the operator of this fact and make sure that the description
> accurately describes that this option should not be used for normal
> production purposes."
> 
>  
> 
> I think that it would be nice if we just didn't do this at all.  But, I
> understand the realities and we are likely to be more successful in our
> goals here if we can accommodate something like this.  To that end, I
> could say that when the system is operating in this mode, we
> should prefix EVERY log line with a short string that makes it clear
> that this mode is for debug/test and that it shouldn't be used for
> production purposes.
> 
>  
> 
> 3) CADF is interesting and appears to be getting some traction.  I am
> not too familiar with this standard, though.  It may be useful to have
> these logging guidelines reviewed by someone who has more familiarity
> with CADF to make sure that everything lines up nicely.
> 
>  
> 
> 4) OSSG hasn't traditionally been through a process of "blessing"
> a document such as this.  However, I would argue that it would be a good
> idea for us to figure out how to do this.  I think that providing
> guidelines such as this are a valuable "next step" towards increasing
> influence and interactions with the dev teams.
> 
>  
> 
> Cheers,
> 
> -bryan
> 
>  
> 
>  
> 
> On Fri, Jun 6, 2014 at 8:00 AM, Paul Montgomery
> <paul.montgomery at rackspace.com <mailto:paul.montgomery at rackspace.com>>
> wrote:
> 
>     I created a first pass document describing some potential solutions
>     to OpenStack sensitive data logging leaks (such as credentials or
>     auth tokens):
> 
>      
> 
>     https://wiki.openstack.org/wiki/Security/Guidelines/logging_guidelines
> 
>      
> 
>     I would appreciate reviews and discussions in order to gain approval
>     of the OSSG and the security-minded community before making
>     recommendations to other projects (especially in the "Possible
>     Implementation Options" section).
> 
>      
> 
>     Thanks!
> 
>     ---paulmo
> 
>      
> 
> 
>     _______________________________________________
>     Openstack-security mailing list
>     Openstack-security at lists.openstack.org
>     <mailto:Openstack-security at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
> 
>  
> 
> 
> 
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>