Re: [openstack-dev] [Openstack-operators] FIPS Compliance

[Luke Hinds]

On Tue, Nov 6, 2018 at 2:04 PM Julia Kreger 
wrote:

>
>
> On Tue, Nov 6, 2018 at 5:07 AM Doug Hellmann 
> wrote:
>
>> Sean McGinnis  writes:
>>
>> > I'm interested in some feedback from the community, particularly those
>> running
>> > OpenStack deployments, as to whether FIPS compliance [0][1] is
>> something folks
>> > are looking for.
>> [trim]
>>
>> I know we've had some interest in it at different times. I think some of
>> the changes will end up being backwards-incompatible, so we may need a
>> "FIPS-mode" configuration flag for those, but in other places we could
>> just switch hashing algorithms and be fine.
>>
>> I'm not sure if anyone has put together the details of what would be
>> needed to update each project, but this feels like it could be a
>> candidate for a goal for a future cycle once we have that information
>> and can assess the level of effort.
>>
>> Doug
>>
>>
> +1 to a FIPS-mode. I think it would be fair to ask projects, to over the
> course of the next month or three, to evaluate their current standing and
> report what they perceive the effort to be.
>
> I think only then we can really determine if it is the right direction to
> take for a cycle goal.
>
> -Julia
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


Understand it's early to be discussing design, but would like to get it on
record  that if we can, we should try to use 'Algorithm Agility' rather
then all moving to the next one up and setting to SHA. That way we can
deal with what might seem unfathomable now, happening later (strong cryptos
getting cracked).
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][Election] Last days for PTL nomination

[Luke Hinds]

On Mon, 30 Jul 2018, 21:19 Jeremy Stanley,  wrote:

> On 2018-07-30 15:23:57 +0700 (+0700), Luke Hinds wrote:
> > Security is a SIG and no longer a project (changed as of rocky cycle).
>
> Technically it's still both at the moment, which is why I proposed
> https://review.openstack.org/586896 yesterday (tried to give you a
> heads up in IRC about that as well). A +1 from the current PTL of
> record on that change would probably be a good idea.
>

I am on PTO for the next two weeks,  is +1 in this email ok? I don't have
my launchpad credentials with me to SSO login to Gerrit.



-- 
> Jeremy Stanley
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][Election] Last days for PTL nomination

[Luke Hinds]

Hi,

Security is a SIG and no longer a project (changed as of rocky cycle).

Regards

Luke

On Mon, 30 Jul 2018, 08:36 Tony Breeds,  wrote:

> Hello all,
>
> A quick reminder that we are in the last hours for PTL candidate
> nominations.
>
> If you want to stand for PTL, don't delay, follow the instructions
> at [1] to make sure the community knows your intentions.
>
> Make sure your nomination has been submitted to the openstack/election
> repository and approved by election officials.
>
> Election statistics[2]:
> Nominations started   @ 2018-07-24 23:45:00 UTC
> Nominations end   @ 2018-07-31 23:45:00 UTC
> Nominations duration  : 7 days, 0:00:00
> Nominations remaining : 1 day, 22:12:07
> Nominations progress  :  72.50%
> ---
> Projects[2]   :65
> Projects with candidates  :29 ( 44.62%)
> Projects with election: 0 (  0.00%)
> ---
> Need election : 0 ()
> Need appointment  : 36 (Adjutant Blazar Cinder Designate
> Documentation Dragonflow Freezer Horizon
> Ironic Kolla Loci Manila Masakari
> Monasca Nova Octavia OpenStackAnsible
> OpenStackClient OpenStack_Helm Oslo
> Packaging_Rpm Puppet_OpenStack Qinling
> Rally RefStack Sahara Searchlight
> Security Solum Storlets Trove Vitrage
> Watcher Winstackers Zaqar Zun)
> ===
> Stats gathered@ 2018-07-30 01:32:53 UTC
>
>
> This means that with approximately 2 days left, 39 projects will
> be deemed leaderless.  In this case the TC will oversee PTL selection as
> described by [3].
>
> Thank you,
>
> [1] http://governance.openstack.org/election/#how-to-submit-your-candidacy
> [2] Assuming the open reviews below are validated
> https://review.openstack.org/#/q/is:open+project:openstack/election
> Which ATM includes:
> Magnum Tacker OpenStack_Charms Neutron Manilla Tripleo Barbican
> Murano
> [3]
> http://governance.openstack.org/resolutions/20141128-elections-process-for-leaderless-programs.html
>
> Yours Tony.
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OSSN-0084] Data retained after deletion of a ScaleIO volume

[Luke Hinds]

On Tue, Jul 10, 2018 at 9:08 PM, Jim Rollenhagen 
wrote:

> On Tue, Jul 10, 2018 at 3:28 PM, Martin Chlumsky <
> martin.chlum...@gmail.com> wrote:
>
>> It is the workaround that is right and the discussion part that is wrong.
>>
>> I am familiar with this bug. Using thin volumes *and/or* enabling zero
>> padding DOES ensure data contained
>> in a volume is actually deleted.
>>
>
> Great, that's super helpful. Thanks!
>
> Is there someone (Luke?) on the list that can send a correction for this
> OSSN to all the lists it needs to go to?
>
> // jim
>

It can, but I would want to be sure we get an agreed consensus. The note
has already gone through a review cycle where a cinder core approved the
contents:

https://review.openstack.org/#/c/579094/

If someone wants to put forward a patch with the needed amendments , I can
send out a correction to the lists.


>
>
>>
>> On Tue, Jul 10, 2018 at 10:41 AM Jim Rollenhagen 
>> wrote:
>>
>>> On Tue, Jul 10, 2018 at 4:20 AM, Luke Hinds  wrote:
>>>
>>>> Data retained after deletion of a ScaleIO volume
>>>> ---
>>>>
>>>> ### Summary ###
>>>> Certain storage volume configurations allow newly created volumes to
>>>> contain previous data. This could lead to leakage of sensitive
>>>> information between tenants.
>>>>
>>>> ### Affected Services / Software ###
>>>> Cinder releases up to and including Queens with ScaleIO volumes
>>>> using thin volumes and zero padding.
>>>>
>>>
>>> According to discussion in the bug, this bug occurs with ScaleIO volumes
>>> using thick volumes and with zero padding disabled.
>>>
>>> If the bug is with thin volumes and zero padding, then the workaround
>>> seems quite wrong. :)
>>>
>>> I'm not super familiar with Cinder, so could some Cinder folks check
>>> this out and re-issue a more accurate OSSN, please?
>>>
>>> // jim
>>>
>>>
>>>>
>>>> ### Discussion ###
>>>> Using both thin volumes and zero padding does not ensure data contained
>>>> in a volume is actually deleted. The default volume provisioning rule is
>>>> set to thick so most installations are likely not affected. Operators
>>>> can check their configuration in `cinder.conf` or check for zero padding
>>>> with this command `scli --query_all`.
>>>>
>>>>  Recommended Actions 
>>>>
>>>> Operators can use the following two workarounds, until the release of
>>>> Rocky (planned 30th August 2018) which resolves the issue.
>>>>
>>>> 1. Swap to thin volumes
>>>>
>>>> 2. Ensure ScaleIO storage pools use zero-padding with:
>>>>
>>>> `scli --modify_zero_padding_policy
>>>> (((--protection_domain_id  |
>>>> --protection_domain_name )
>>>> --storage_pool_name ) | --storage_pool_id )
>>>> (--enable_zero_padding | --disable_zero_padding)`
>>>>
>>>> ### Contacts / References ###
>>>> Author: Nick Tait
>>>> This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0084
>>>> Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1699573
>>>> Mailing List : [Security] tag on openstack-dev@lists.openstack.org
>>>> OpenStack Security Project : https://launchpad.net/~openstack-ossg
>>>>
>>>>
>>>> 
>>>> __
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe: openstack-dev-requ...@lists.op
>>>> enstack.org?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>> ____
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Luke Hinds | NFV Partner Engineering | CTO Office | Red Hat
e: lhi...@redhat.com | irc: lhinds @freenode | t: +44 12 52 36 2483
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OSSN-0084] Data retained after deletion of a ScaleIO volume

[Luke Hinds]

Data retained after deletion of a ScaleIO volume
---

### Summary ###
Certain storage volume configurations allow newly created volumes to
contain previous data. This could lead to leakage of sensitive
information between tenants.

### Affected Services / Software ###
Cinder releases up to and including Queens with ScaleIO volumes
using thin volumes and zero padding.

### Discussion ###
Using both thin volumes and zero padding does not ensure data contained
in a volume is actually deleted. The default volume provisioning rule is
set to thick so most installations are likely not affected. Operators
can check their configuration in `cinder.conf` or check for zero padding
with this command `scli --query_all`.

 Recommended Actions 

Operators can use the following two workarounds, until the release of
Rocky (planned 30th August 2018) which resolves the issue.

1. Swap to thin volumes

2. Ensure ScaleIO storage pools use zero-padding with:

`scli --modify_zero_padding_policy
(((--protection_domain_id  |
--protection_domain_name )
--storage_pool_name ) | --storage_pool_id )
(--enable_zero_padding | --disable_zero_padding)`

### Contacts / References ###
Author: Nick Tait
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0084
Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1699573
Mailing List : [Security] tag on openstack-dev@lists.openstack.org
OpenStack Security Project : https://launchpad.net/~openstack-ossg



signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder][security][api-wg] Adding http security headers

[Luke Hinds]

On Thu, Jul 5, 2018 at 6:17 PM, Doug Hellmann  wrote:

> Excerpts from Jim Rollenhagen's message of 2018-07-05 12:53:34 -0400:
> > On Thu, Jul 5, 2018 at 12:40 PM, Nishant Kumar E <
> > nishant.e.ku...@ericsson.com> wrote:
> >
> > > Hi,
> > >
> > >
> > >
> > > I have registered a blueprint for adding http security headers -
> > > https://blueprints.launchpad.net/cinder/+spec/http-security-headers
> > >
> > >
> > >
> > > Reason for introducing this change - I work for AT cloud project –
> > > Network Cloud (Earlier known as AT integrated Cloud). As part of
> working
> > > there we have introduced this change within all the services as kind
> of a
> > > downstream change but would like to see it a part of upstream
> community.
> > > While we did not face any major threats without this change but during
> our
> > > investigation process we found that if dealing with web services we
> should
> > > maximize the security as much as possible and came up with a list of
> HTTP
> > > security headers that we should include as part of the OpenStack
> services.
> > > I would like to introduce this change as part of cinder to start off
> and
> > > then propagate this to all the services.
> > >
> > >
> > >
> > > Some reference links which might give more insight into this:
> > >
> > >- https://www.owasp.org/index.php/OWASP_Secure_Headers_
> > >Project#tab=Headers
> > >- https://www.keycdn.com/blog/http-security-headers/
> > >- https://securityintelligence.com/an-introduction-to-http-
> > >response-headers-for-security/
> > >
> > > Please let me know if this looks good and whether it can be included as
> > > part of Cinder followed by other services. More details on how the
> > > implementation will be done is mentioned as part of the blueprint but
> any
> > > better ideas for implementation is welcomed too !!
> > >
> >
> > Wouldn't this be a job for the HTTP server in front of cinder (or
> whatever
> > service)? Especially "Strict-Transport-Security" as one shouldn't be
> > enabling that without ensuring a correct TLS config.
> >
> > Bonus points in that upstream wouldn't need any changes, and we won't
> need
> > to change every project. :)
> >
> > // jim
>
> Yes, this feels very much like something the deployment tools should
> do when they set up Apache or uWSGI or whatever service is in front
> of each API WSGI service.
>
> Doug
>
>
I agree, this should all be set within an installer, rather then the base
project itself. Horizon (or rather django) has directives to enable many of
the common security header fields, but rather than set these directly in
horizons local_settings, we patched the openstack puppet-horizon module.
Take for the following for example around X-Frame disabling:

https://github.com/openstack/puppet-horizon/blob/218c35ea7bc08dd88d936ab79b14e5ce2b94ea44/releasenotes/notes/disallow_iframe_embed-f0ffa1cabeca5b1e.yaml#L2

The same approach should be used elsewhere, with whatever the preferred
deployment tool is (puppet, chef, ansible etc).  That way if a decision is
made to roll out out TLS then can also toggle in certificate pinning etc in
the same tool flow.



> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo][tripleoclient] No more global sudo for "stack" on the undercloud

[Luke Hinds]

On Tue, Jun 5, 2018 at 3:44 PM, Cédric Jeanneret 
wrote:

> Hello guys!
>
> I'm currently working on python-tripleoclient in order to squash the
> dreadful "NOPASSWD:ALL" allowed to the "stack" user.
>
> The start was an issue with the rights on some files being wrong (owner
> by root instead of stack, in stack home). After some digging and poking,
> it appears the undercloud deployment is called with a "sudo openstack
> tripleo deploy" command - this, of course, creates some major issues
> regarding both security and right management.
>
> I see a couple of ways to correct that bad situation:
> - let the global "sudo" call, and play with setuid/setgid when we
> actually don't need the root access (as it's mentioned in this comment¹)
>
> - drop that global sudo call, and replace all the necessary calls by
> some "sudo" when needed. This involves the replacement of native python
> code, like "os.mkdir" and the like.
>
> The first one isn't a solution - code maintenance will not be possible,
> having to thing "darn, os.setuid() before calling that, because I don't
> need root" is the current way, and it just doesn't apply.
>
> So I started the second one. It's, of course, longer, not really nice
> and painful, but at least this will end to a good status, and not so bad
> solution.
>
> This also meets the current work of the Security Squad about "limiting
> sudo rights and accesses".
>
> For now I don't have a proper patch to show, but it will most probably
> appear shortly, as a Work In Progress (I don't think it will be
> mergeable before some time, due to all the constraints we have regarding
> version portability, new sudoer integration and so on).
>
> I'll post the relevant review link as an answer of this thread when I
> have something I can show.
>
> Cheers,
>
> C.
>
>
Hi Cédric,

Pleased to hear you are willing to take this on.

It makes sense we should co-ordinate efforts here as I have been looking at
the same item, but planned to start with heat-admin over on the overcloud.

Due to the complexity / level of coverage in the use of sudo, it makes
sense to have a spec where we can then get community consensus on the
approach selected. This is important as it looks like we will need to have
some sort of white list to maintain and make considerations around
functional test coverage in CI (in case someone writes something new
wrapped in sudo).

In regards to your suggested positions within python code such as the
client, its worth looking at oslo.privsep [1] where a decorator can be used
for when needing to setuid.

Let's discuss this also in the squad meeting tomorrow and try to synergize
approach for all tripleo nix accounts.

[1] https://github.com/openstack/oslo.privsep

Cheers,

Luke


> ¹
> https://github.com/openstack/python-tripleoclient/blob/
> master/tripleoclient/v1/tripleo_deploy.py#L827-L829
>
>
> --
> Cédric Jeanneret
> Software Engineer
> DFG:DF
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-de
> 
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] Limiting sudo coverage of heat-admin / stack and other users.

[Luke Hinds]

On Tue, May 22, 2018 at 8:24 AM, Cédric Jeanneret <cjean...@redhat.com>
wrote:

>
>
> On 05/22/2018 09:08 AM, Luke Hinds wrote:
> >
> >
> > On Tue, May 22, 2018 at 5:27 AM, Cédric Jeanneret <cjean...@redhat.com
> > <mailto:cjean...@redhat.com>> wrote:
> >
> >
> >
> > On 05/21/2018 03:49 PM, Luke Hinds wrote:
> > > A few operators have requested if its possible to limit sudo's
> coverage
> > > on both the under / overcloud. There is concern over `ALL=(ALL)
> > > NOPASSWD:ALL` , which allows someone to  `sudo su`.
> > >
> > > This task has come under the care of the tripleo security squad.
> > >
> > > The work is being tracked and discussed here [0].
> > >
> > > So far it looks like the approach will be to use regexp within
> > > /etc/sudoers.d/*., to narrow down as close as possible to the
> specific
> > > commands called. Some services already do this with rootwrap:
> > >
> > > ironic ALL = (root) NOPASSWD: /usr/bin/ironic-rootwrap
> > > /etc/ironic/rootwrap.conf *
> > >
> > > It's fairly easy to pick up a list of all sudo calls using a simple
> > > script [1]
> > >
> > > The other prolific user of sudo is ansible / stack, for example:
> > >
> > > /bin/sh -c echo BECOME-SUCCESS-kldpbeueyodisjajjqthpafzadrncdff;
> > > /usr/bin/python
> > > /home/stack/.ansible/tmp/ansible-tmp-1526579105.0-
> 109863952786117/systemd.py;
> > > rm -rf
> > > "/home/stack/.ansible/tmp/ansible-tmp-1526579105.0-109863952786117/"
> >
> > > /dev/null 2>&1
> > >
> > > My feelings here are to again use regexp around the immutable non
> random
> > > parts of the command.  cjeanner also made some suggestions in the
> > > etherpad [0].
> >
> > Might be a temporary way to limit the surface indeed, but an upstream
> > change in Ansible would still be really nice. Predictable names is
> the
> > only "right" way, although this will create a long sudo ruleset. A
> > really long one to be honnest. Maintainability is also to be
> discussed
> > in either way (maintain a couple of regexp vs 200+ rules.. hmmm).
> >
> >
> > As I understand it, the problem with predicable names is they also
> > become predictable to attackers (this would be the reason ansible adds
> > in the random string). It helps prevent someone creating a race
> > condition to replace the python script with something more nefarious.
> > Its the same reason commands such as mktemp exists.
>
> Fair enough indeed. Both solution have their pros and cons. In order to
> move on, I think the regexp in sudoers is acceptable for the following
> reasons:
> - limits accesses outside of ansible generated code
> - allows others to still push new content without having to change sudo
> listing (thanks to regexp)
> - still hard to inject bad things in the executed script/code
> - quick to implement (well, fastest than requiring an upstream change
> that will most probably break some internal things before working
> properly, and without adding more security as you explained it)
>
>
Thanks for chiming in Cédric , value your contributions here.

I was thinking about this earlier on my way to work..

Perhaps we could have a script in CI that fails on sudo calls being blocked
(as no regexp exists for them)? This way it will prevent people going on a
wild goose chase trying to work out why a patch they are working on has
failed. As an example, someone might change a single argument in an
iptables command (a few of those run under sudo) that desyncs the command
to the sudo regexp?


@Juan do you agree with that statement? As we had some quick chat about it.
>
> Note: I'm not part of the security squad ;). But I like secured things.
>
> >
> > >
> > > However aside to the approach, we need to consider the impact
> locking
> > > down might have should someone create a develop a new bit of code
> that
> > > leverages commands wrapped in sudo and assumes ALL with be in
> place.
> > > This of course will be blocked.
> >
> > This will indeed require some doc, as this is a "major" change.
> However,
> > the use of regexp should somewhat limit the impact, especially since
> > Ansible pushes its exec script in the same location.
> > Even new parts should be allowed (that might be a bit of concern if
> we
> > 

Re: [openstack-dev] [tripleo] Limiting sudo coverage of heat-admin / stack and other users.

[Luke Hinds]

On Tue, May 22, 2018 at 5:27 AM, Cédric Jeanneret <cjean...@redhat.com>
wrote:

>
>
> On 05/21/2018 03:49 PM, Luke Hinds wrote:
> > A few operators have requested if its possible to limit sudo's coverage
> > on both the under / overcloud. There is concern over `ALL=(ALL)
> > NOPASSWD:ALL` , which allows someone to  `sudo su`.
> >
> > This task has come under the care of the tripleo security squad.
> >
> > The work is being tracked and discussed here [0].
> >
> > So far it looks like the approach will be to use regexp within
> > /etc/sudoers.d/*., to narrow down as close as possible to the specific
> > commands called. Some services already do this with rootwrap:
> >
> > ironic ALL = (root) NOPASSWD: /usr/bin/ironic-rootwrap
> > /etc/ironic/rootwrap.conf *
> >
> > It's fairly easy to pick up a list of all sudo calls using a simple
> > script [1]
> >
> > The other prolific user of sudo is ansible / stack, for example:
> >
> > /bin/sh -c echo BECOME-SUCCESS-kldpbeueyodisjajjqthpafzadrncdff;
> > /usr/bin/python
> > /home/stack/.ansible/tmp/ansible-tmp-1526579105.0-
> 109863952786117/systemd.py;
> > rm -rf
> > "/home/stack/.ansible/tmp/ansible-tmp-1526579105.0-109863952786117/" >
> > /dev/null 2>&1
> >
> > My feelings here are to again use regexp around the immutable non random
> > parts of the command.  cjeanner also made some suggestions in the
> > etherpad [0].
>
> Might be a temporary way to limit the surface indeed, but an upstream
> change in Ansible would still be really nice. Predictable names is the
> only "right" way, although this will create a long sudo ruleset. A
> really long one to be honnest. Maintainability is also to be discussed
> in either way (maintain a couple of regexp vs 200+ rules.. hmmm).
>
>
As I understand it, the problem with predicable names is they also become
predictable to attackers (this would be the reason ansible adds in the
random string). It helps prevent someone creating a race condition to
replace the python script with something more nefarious. Its the same
reason commands such as mktemp exists.

>
> > However aside to the approach, we need to consider the impact locking
> > down might have should someone create a develop a new bit of code that
> > leverages commands wrapped in sudo and assumes ALL with be in place.
> > This of course will be blocked.
>
> This will indeed require some doc, as this is a "major" change. However,
> the use of regexp should somewhat limit the impact, especially since
> Ansible pushes its exec script in the same location.
> Even new parts should be allowed (that might be a bit of concern if we
> want to really dig in the consequences of a bad template being injected
> in some way [looking config-download ;)]).
> But at some point, we might also decide to let the OPs ensure their
> infra isn't compromised.
> Always the same thread-of with Security vs The World - convenience vs
> cumbersome management, and so on.
>
> >
> > Now my guess is that our CI would capture this as the deploy would
> > fail(?) and the developer should work out an entry is needed when
> > testing their patch, but wanted to open this up to others who know
> > testing at gate better much better than myself.  Also encourage any
> > thoughts on the topic to be introduced to the etherpad [0]
> >
> > [0] https://etherpad.openstack.org/p/tripleo-heat-admin-security
> > [1] https://gist.github.com/lukehinds/4cdb1bf4de526a049c51f05698b8b04f
> >
> > --
> > Luke Hinds
>
> --
> Cédric Jeanneret
> Software Engineer
> DFG:DF
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Luke Hinds | NFV Partner Engineering | CTO Office | Red Hat
e: lhi...@redhat.com | irc: lhinds @freenode | t: +44 12 52 36 2483
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tripleo] Limiting sudo coverage of heat-admin / stack and other users.

[Luke Hinds]

A few operators have requested if its possible to limit sudo's coverage on
both the under / overcloud. There is concern over `ALL=(ALL) NOPASSWD:ALL`
, which allows someone to  `sudo su`.

This task has come under the care of the tripleo security squad.

The work is being tracked and discussed here [0].

So far it looks like the approach will be to use regexp within
/etc/sudoers.d/*., to narrow down as close as possible to the specific
commands called. Some services already do this with rootwrap:

ironic ALL = (root) NOPASSWD: /usr/bin/ironic-rootwrap
/etc/ironic/rootwrap.conf *

It's fairly easy to pick up a list of all sudo calls using a simple script
[1]

The other prolific user of sudo is ansible / stack, for example:

/bin/sh -c echo BECOME-SUCCESS-kldpbeueyodisjajjqthpafzadrncdff;
/usr/bin/python
/home/stack/.ansible/tmp/ansible-tmp-1526579105.0-109863952786117/systemd.py;
rm -rf "/home/stack/.ansible/tmp/ansible-tmp-1526579105.0-109863952786117/"
> /dev/null 2>&1

My feelings here are to again use regexp around the immutable non random
parts of the command.  cjeanner also made some suggestions in the etherpad
[0].

However aside to the approach, we need to consider the impact locking down
might have should someone create a develop a new bit of code that leverages
commands wrapped in sudo and assumes ALL with be in place. This of course
will be blocked.

Now my guess is that our CI would capture this as the deploy would fail(?)
and the developer should work out an entry is needed when testing their
patch, but wanted to open this up to others who know testing at gate better
much better than myself.  Also encourage any thoughts on the topic to be
introduced to the etherpad [0]

[0] https://etherpad.openstack.org/p/tripleo-heat-admin-security
[1] https://gist.github.com/lukehinds/4cdb1bf4de526a049c51f05698b8b04f

-- 
Luke Hinds
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OSSN-0083] Keystone policy rule "identity:get_identity_providers" was ignored

[Luke Hinds]

Keystone policy rule "identity:get_identity_providers" was ignored
---

### Summary ###
A policy rule in Keystone did not behave as intended leading to a less
secure configuration than would be expected.

### Affected Services / Software ###
OpenStack Identity Service (Keystone) versions through Mitaka, as well
as Newton (<= 10.0.3), and Ocata (<= 11.0.3).

### Discussion ###
Deployments were unaffected by this problem if the default rule was
changed or the "get_identity_providers" rule was manually changed to
be "get_identity_provider" (singular) in keystone's `policy.json`.

A spelling mistake in the default policy configuration caused these
rules to be ignored. As a result operators that attempted to restrict
this API were unlikely to actually enforce it.

### Recommended Actions ###
Update Keystone to a minimum version of 12.0.0.0b3. Additionally, this
fix has been backported to Ocata (11.0.3) and Newton (10.0.3).

Fix any lingering rules: `identity:get_identity_providers` should
be changed to `identity:get_identity_provider`.

### Contacts / References ###
Author: Nick Tait
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0083
Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1703369
Mailing List : [Security] tag on openstack-dev@lists.openstack.org
OpenStack Security Project : https://launchpad.net/~openstack-ossg


0x3C202614.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Migration of Bandit

[Luke Hinds]

All,

Please note that Bandits code and issues / docs will be migrated from
OpenStack to PyCQA.

This is expected to happen next week.

No changes are required in any projects or CI, as Bandit will still be
available via pypi and projects / CI are set up to use Bandit in that way
via tox.

READMEs and Key Wiki pages will be updated to inform any visitors of the
new home and how to contribute / raise issues.

Cheers,

Luke
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [bandit] Migration to PyCQA

[Luke Hinds]

Hi All,

As most of you are aware, a decision was made to migrate the maintenance of
Bandit to PyCQA [0].

In order to kick things off, I have started a pad [1] to make sure we
capture all the steps needed for a seamless migration.

Please do look at this and provide input / feedback. @Jeremy, including you
for the zuul side of things.

We will start covering this as a topic each Thursday on the security-sig
meeting, until we are confident to 'hit the button' and move the project
over.

[0] https://github.com/PyCQA
[1] https://etherpad.openstack.org/p/bandit-migration

Please be mindful of including Ian on replies, who may not be subscribed
the the -dev list.

-- 
Luke Hinds
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [security] Tomorrow's meeting and LCOO

[Luke Hinds]

Sounds great, thanks Gage!

I will try to catch up with you on Friday!

On Wed, Mar 14, 2018 at 6:51 PM, Gage Hugo <gageh...@gmail.com> wrote:

> Hey Luke,
>
> I can chair the meeting tomorrow if that works.
>
> I will also ping eeiden about getting some LCOO discussion going as well.
>
> On Wed, Mar 14, 2018 at 1:35 PM, Luke Hinds <lhi...@redhat.com> wrote:
>
>> Hello,
>>
>> Something has come up that determines I won't be able to attend the
>> meeting tomorrow and more importantly chair it.
>>
>> However I would not want to be a bottleneck to good progress underway.
>>
>> If someone would like to step up and chair for just this meeting, the
>> agenda is below:
>>
>> https://etherpad.openstack.org/p/security-agenda
>>
>> Also keep in mind, we now meet in #openstack-meeting at 15:00, instead of
>> 17:00.
>>
>> If not, we will defer and meet the week after.
>>
>> Last point, someone called eeiden pinged me on IRC, but have since logged
>> out. They LCOO has an interest in working with the security SIG, which is
>> most welcome. If anyone knows eeiden, can you ask him / her to contact us
>> on this list and we can get initial discussions going and hopefully bring
>> them into the meeting too.
>>
>> Cheers,
>>
>> Luke
>>
>
>


-- 
Luke Hinds | NFV Partner Engineering | CTO Office | Red Hat
e: lhi...@redhat.com | irc: lhinds @freenode | t: +44 12 52 36 2483
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [security] Tomorrow's meeting and LCOO

[Luke Hinds]

Hello,

Something has come up that determines I won't be able to attend the meeting
tomorrow and more importantly chair it.

However I would not want to be a bottleneck to good progress underway.

If someone would like to step up and chair for just this meeting, the
agenda is below:

https://etherpad.openstack.org/p/security-agenda

Also keep in mind, we now meet in #openstack-meeting at 15:00, instead of
17:00.

If not, we will defer and meet the week after.

Last point, someone called eeiden pinged me on IRC, but have since logged
out. They LCOO has an interest in working with the security SIG, which is
most welcome. If anyone knows eeiden, can you ask him / her to contact us
on this list and we can get initial discussions going and hopefully bring
them into the meeting too.

Cheers,

Luke
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] [security] Proposing Security Squad

[Luke Hinds]

On Tue, Mar 6, 2018 at 1:37 PM, Jeremy Stanley  wrote:

> On 2018-03-06 14:40:53 +0200 (+0200), Juan Antonio Osorio wrote:
> > As mentioned in the PTG, I would like to start a Security Squad
> > for TripleO, with the goal of working with the security aspects
> > and challenges in a more public manner.
> [...]
>
> I would also strongly encourage you all to get involved with the
> OpenStack Security SIG. We're always looking for help/input with
> regard to information security concerns and ideas. The weekly
> meeting has recently been rescheduled to 15:00 UTC on Thursdays if
> you're available, and we have a #openstack-security IRC channel on
> Freenode where many of us can be found.
> --
> Jeremy Stanley
>
>
Hi Jeremy, Good call - and I made a note in the squad planning pad ("General
OpenStack security topics should go to the Security SIG."



> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [security] Security SIG Meeting Time Change

[Luke Hinds]

Hi All,

As agreed during the PTG, we will switch Thursdays meetings from 17:00 UTC,
to 15:00 UTC.

-- 
Luke
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [security] Security PTG Planning, x-project request for topics.

[Luke Hinds]

Hi Pino,

Thank you for your time demonstrating Tatu.

If you like we could incubate Tatu into the security SIG. This would mean
no change to project structure / governance etc, its more the project gains
a regular slot on our weekly meetings to help get patches reviewed and
encourage other contributors / feedback etc. We did this with projects such
as Bandit before, until it found its own legs and momentum.

Cheers,

Luke


On Mon, Feb 12, 2018 at 8:45 AM, Luke Hinds <lhi...@redhat.com> wrote:

>
>
> On Sun, Feb 11, 2018 at 4:01 PM, Pino de Candia <
> giuseppe.decan...@gmail.com> wrote:
>
>> I uploaded the demo video (https://youtu.be/y6ICCPO08d8) and linked it
>> from the slides.
>>
>
> Thanks Pino , i added these to the agenda:
>
> https://etherpad.openstack.org/p/security-ptg-rocky
>
> Please let me know before the PTG, if it will be your colleague or if we
> need to find a projector to conference you in.
>
>
>> On Fri, Feb 9, 2018 at 5:51 PM, Pino de Candia <
>> giuseppe.decan...@gmail.com> wrote:
>>
>>> Hi Folks,
>>>
>>> here are the slides for the Tatu presentation: https://docs.goo
>>> gle.com/presentation/d/1HI5RR3SNUu1If-A5Zi4EMvjl-3TKsBW20xEUyYHapfM
>>>
>>> I meant to record the demo video as well but I haven't gotten around to
>>> editing all the bits. Please stay tuned.
>>>
>>> thanks,
>>> Pino
>>>
>>>
>>> On Tue, Feb 6, 2018 at 10:52 AM, Giuseppe de Candia <
>>> giuseppe.decan...@gmail.com> wrote:
>>>
>>>> Hi Luke,
>>>>
>>>> Fantastic! An hour would be great if the schedule allows - there are
>>>> lots of different aspects we can dive into and potential future directions
>>>> the project can take.
>>>>
>>>> thanks!
>>>> Pino
>>>>
>>>>
>>>>
>>>> On Tue, Feb 6, 2018 at 10:36 AM, Luke Hinds <lhi...@redhat.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Tue, Feb 6, 2018 at 4:21 PM, Giuseppe de Candia <
>>>>> giuseppe.decan...@gmail.com> wrote:
>>>>>
>>>>>> Hi Folks,
>>>>>>
>>>>>> I know the request is very late, but I wasn't aware of this SIG until
>>>>>> recently. Would it be possible to present a new project to the Security 
>>>>>> SIG
>>>>>> at the PTG? I need about 30 minutes. I'm hoping to drum up interest in 
>>>>>> the
>>>>>> project, sign on users and contributors and get feedback.
>>>>>>
>>>>>> For the past few months I have been working on a new project - Tatu
>>>>>> [1]- to automate the management of SSH certificates (for both users and
>>>>>> hosts) in OpenStack. Tatu allows users to generate SSH certificates with
>>>>>> principals based on their Project role assignments, and VMs automatically
>>>>>> set up their SSH host certificate (and related config) via Nova vendor
>>>>>> data. The project also manages bastions and DNS entries so that users 
>>>>>> don't
>>>>>> have to assign Floating IPs for SSH nor remember IP addresses.
>>>>>>
>>>>>> I have a working demo (including Horizon panels [2] and OpenStack CLI
>>>>>> [3]), but am still working on the devstack script and patches [4] to get
>>>>>> Tatu's repositories into OpenStack's GitHub and Gerrit. I'll try to post 
>>>>>> a
>>>>>> demo video in the next few days.
>>>>>>
>>>>>> best regards,
>>>>>> Pino
>>>>>>
>>>>>>
>>>>>> References:
>>>>>>
>>>>>>1. https://github.com/pinodeca/tatu (Please note this is still
>>>>>>very much a work in progress, lots of TODOs in the code, very little
>>>>>>testing and documentation doesn't reflect the latest design).
>>>>>>2. https://github.com/pinodeca/tatu-dashboard
>>>>>>3. https://github.com/pinodeca/python-tatuclient
>>>>>>4. https://review.openstack.org/#/q/tatu
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> Hi Giuseppe, of course you can! I will add you to the agenda. We could
>>>>> get your an hour if it allows more time for presenting and post 
>>>>> discussion?
&g

Re: [openstack-dev] [PTL][SIG][PTG]Team Photos

[Luke Hinds]

Hi Kendall,

Now the day has arrived, could you let us know about logistics..is there
somewhere we should go to wait before being collected and heading to the
pitch?

Cheers,

Luke

On Wed, Feb 21, 2018 at 11:48 PM, Kendall Nelson <kennelso...@gmail.com>
wrote:

> Hello Everyone!
>
> I just wanted to remind you all that you have till *Monday Feburary 26th*
> to sign up if your team or group is interested in a team photo on the Croke
> Park pitch! We still have slots available Tuesday afternoon and Thursday
> morning.
>
> -Kendall (diablo_rojo)
>
> On Thu, Feb 8, 2018 at 10:21 AM Kendall Nelson <kennelso...@gmail.com>
> wrote:
>
>> This link might work better for everyone:
>> https://docs.google.com/spreadsheets/d/1J2MRdVQzSyakz9HgTHfwYPe49PaoT
>> ypX66eNURsopQY/edit?usp=sharing
>>
>> -Kendall (diablo_rojo)
>>
>>
>> On Wed, Feb 7, 2018 at 9:15 PM Kendall Nelson <kennelso...@gmail.com>
>> wrote:
>>
>>> Hello PTLs and SIG Chairs!
>>>
>>> So here's the deal, we have 50 spots that are first come, first
>>> served. We have slots available before and after lunch both Tuesday and
>>> Thursday.
>>>
>>> The google sheet here[1] should be set up so you have access to edit,
>>> but if you can't for some reason just reply directly to me and I can add
>>> your team to the list (I need team/sig name and contact email).
>>>
>>> I will be locking the google sheet on *Monday February 26th so I need
>>> to know if your team is interested by then. *
>>>
>>> See you soon!
>>>
>>> - Kendall Nelson (diablo_rojo)
>>>
>>> [1] https://docs.google.com/spreadsheets/d/
>>> 1J2MRdVQzSyakz9HgTHfwYPe49PaoTypX66eNURsopQY/edit?usp=sharing
>>>
>>>
>>>
>>>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Luke Hinds | NFV Partner Engineering | CTO Office | Red Hat
e: lhi...@redhat.com | irc: lhinds @freenode | t: +44 12 52 36 2483
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] Draft schedule for PTG

[Luke Hinds]

On Sat, Feb 24, 2018 at 12:15 AM, Emilien Macchi <emil...@redhat.com> wrote:

>
>
> On Fri, Feb 23, 2018 at 10:28 AM, Juan Antonio Osorio <jaosor...@gmail.com
> > wrote:
>
>> Could we change the Security talk to a day before Friday (both Thursday
>> and Wednesday are fine)? Luke Hinds, the leader of the OpenStack Security
>> group would like to join that discussion, but is not able to join that day.
>>
>
> Done, moved to Thursday afternoon. Hope it works for you!
>

Thanks Emilien!


>
>>
>> On Mon, Feb 19, 2018 at 6:37 PM, Emilien Macchi <emil...@redhat.com>
>> wrote:
>>
>>> Alex and I have been working on the agenda for next week, based on what
>>> people proposed in topics.
>>>
>>> The draft calendar is visible here:
>>> https://calendar.google.com/calendar/embed?src=tgpb5tv12mlu7
>>> kge5oqertje78%40group.calendar.google.com=Europe%2FDublin
>>>
>>> Also you can import the ICS from:
>>> https://calendar.google.com/calendar/ical/tgpb5tv12mlu7kge5o
>>> qertje78%40group.calendar.google.com/public/basic.ics
>>>
>>> Note this is a draft - we would love your feedback about the proposal.
>>>
>>> Some sessions might be too short or too long? You to tell us. (Please
>>> look at event details for descriptions).
>>> Also, for each session we need a "driver", please tell us if you
>>> volunteer to do it.
>>>
>>> Please let us know here and we'll make adjustment, we have plenty of
>>> room for it.
>>>
>>> Thanks!
>>> --
>>> Emilien Macchi
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>> --
>> Juan Antonio Osorio R.
>> e-mail: jaosor...@gmail.com
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Emilien Macchi
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [security] Security PTG Planning, x-project request for topics.

[Luke Hinds]

On Sun, Feb 11, 2018 at 4:01 PM, Pino de Candia <giuseppe.decan...@gmail.com
> wrote:

> I uploaded the demo video (https://youtu.be/y6ICCPO08d8) and linked it
> from the slides.
>

Thanks Pino , i added these to the agenda:

https://etherpad.openstack.org/p/security-ptg-rocky

Please let me know before the PTG, if it will be your colleague or if we
need to find a projector to conference you in.


> On Fri, Feb 9, 2018 at 5:51 PM, Pino de Candia <
> giuseppe.decan...@gmail.com> wrote:
>
>> Hi Folks,
>>
>> here are the slides for the Tatu presentation: https://docs.goo
>> gle.com/presentation/d/1HI5RR3SNUu1If-A5Zi4EMvjl-3TKsBW20xEUyYHapfM
>>
>> I meant to record the demo video as well but I haven't gotten around to
>> editing all the bits. Please stay tuned.
>>
>> thanks,
>> Pino
>>
>>
>> On Tue, Feb 6, 2018 at 10:52 AM, Giuseppe de Candia <
>> giuseppe.decan...@gmail.com> wrote:
>>
>>> Hi Luke,
>>>
>>> Fantastic! An hour would be great if the schedule allows - there are
>>> lots of different aspects we can dive into and potential future directions
>>> the project can take.
>>>
>>> thanks!
>>> Pino
>>>
>>>
>>>
>>> On Tue, Feb 6, 2018 at 10:36 AM, Luke Hinds <lhi...@redhat.com> wrote:
>>>
>>>>
>>>>
>>>> On Tue, Feb 6, 2018 at 4:21 PM, Giuseppe de Candia <
>>>> giuseppe.decan...@gmail.com> wrote:
>>>>
>>>>> Hi Folks,
>>>>>
>>>>> I know the request is very late, but I wasn't aware of this SIG until
>>>>> recently. Would it be possible to present a new project to the Security 
>>>>> SIG
>>>>> at the PTG? I need about 30 minutes. I'm hoping to drum up interest in the
>>>>> project, sign on users and contributors and get feedback.
>>>>>
>>>>> For the past few months I have been working on a new project - Tatu
>>>>> [1]- to automate the management of SSH certificates (for both users and
>>>>> hosts) in OpenStack. Tatu allows users to generate SSH certificates with
>>>>> principals based on their Project role assignments, and VMs automatically
>>>>> set up their SSH host certificate (and related config) via Nova vendor
>>>>> data. The project also manages bastions and DNS entries so that users 
>>>>> don't
>>>>> have to assign Floating IPs for SSH nor remember IP addresses.
>>>>>
>>>>> I have a working demo (including Horizon panels [2] and OpenStack CLI
>>>>> [3]), but am still working on the devstack script and patches [4] to get
>>>>> Tatu's repositories into OpenStack's GitHub and Gerrit. I'll try to post a
>>>>> demo video in the next few days.
>>>>>
>>>>> best regards,
>>>>> Pino
>>>>>
>>>>>
>>>>> References:
>>>>>
>>>>>1. https://github.com/pinodeca/tatu (Please note this is still
>>>>>very much a work in progress, lots of TODOs in the code, very little
>>>>>testing and documentation doesn't reflect the latest design).
>>>>>2. https://github.com/pinodeca/tatu-dashboard
>>>>>3. https://github.com/pinodeca/python-tatuclient
>>>>>4. https://review.openstack.org/#/q/tatu
>>>>>
>>>>>
>>>>>
>>>>>
>>>> Hi Giuseppe, of course you can! I will add you to the agenda. We could
>>>> get your an hour if it allows more time for presenting and post discussion?
>>>>
>>>> We will be meeting in an allocated room on Monday (details to follow).
>>>>
>>>> https://etherpad.openstack.org/p/security-ptg-rocky
>>>>
>>>> Luke
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>> On Wed, Jan 31, 2018 at 12:03 PM, Luke Hinds <lhi...@redhat.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> On Mon, Jan 29, 2018 at 2:29 PM, Adam Young <ayo...@redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Bug 968696 and System Roles.   Needs to be addressed across the
>>>>>>> Service catalog.
>>>>>>>
>>>>>>
>>>>>> Thanks Adam, will add it to the list. I see it's been open since 2012!
>>>>>

Re: [openstack-dev] [OpenStackClient][Security][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][masakari][neutron][senlin][shade][solum][swift][tacker][tricircle][vitrage][watcher][winstackers]

[Luke Hinds]

On Wed, Feb 7, 2018 at 4:23 PM, Matthew Thode 
wrote:

> Hi all,
>
> it looks like some of your projects may need to cut a queens
> branch/release.  Is there anything we can do to move it along?
>
> The following is the list I'm working off of (will be updated as
> projects release)
> https://gist.github.com/prometheanfire/9449355352d97207aa85172cd9ef4b9f
>
> As of right now it's as follows.


>From what I know anchor (security) has no maintainers / cores now, so I
guess it would make sense to perhaps archive (I will follow this through
outside this thread), so for now there is no need to tag a queens branch /
release.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [security] Security PTG Planning, x-project request for topics.

[Luke Hinds]

On Tue, Feb 6, 2018 at 4:21 PM, Giuseppe de Candia <
giuseppe.decan...@gmail.com> wrote:

> Hi Folks,
>
> I know the request is very late, but I wasn't aware of this SIG until
> recently. Would it be possible to present a new project to the Security SIG
> at the PTG? I need about 30 minutes. I'm hoping to drum up interest in the
> project, sign on users and contributors and get feedback.
>
> For the past few months I have been working on a new project - Tatu [1]-
> to automate the management of SSH certificates (for both users and hosts)
> in OpenStack. Tatu allows users to generate SSH certificates with
> principals based on their Project role assignments, and VMs automatically
> set up their SSH host certificate (and related config) via Nova vendor
> data. The project also manages bastions and DNS entries so that users don't
> have to assign Floating IPs for SSH nor remember IP addresses.
>
> I have a working demo (including Horizon panels [2] and OpenStack CLI
> [3]), but am still working on the devstack script and patches [4] to get
> Tatu's repositories into OpenStack's GitHub and Gerrit. I'll try to post a
> demo video in the next few days.
>
> best regards,
> Pino
>
>
> References:
>
>1. https://github.com/pinodeca/tatu (Please note this is still very
>much a work in progress, lots of TODOs in the code, very little testing and
>documentation doesn't reflect the latest design).
>2. https://github.com/pinodeca/tatu-dashboard
>3. https://github.com/pinodeca/python-tatuclient
>4. https://review.openstack.org/#/q/tatu
>
>
>
>
Hi Giuseppe, of course you can! I will add you to the agenda. We could get
your an hour if it allows more time for presenting and post discussion?

We will be meeting in an allocated room on Monday (details to follow).

https://etherpad.openstack.org/p/security-ptg-rocky

Luke




>
>
> On Wed, Jan 31, 2018 at 12:03 PM, Luke Hinds <lhi...@redhat.com> wrote:
>
>>
>> On Mon, Jan 29, 2018 at 2:29 PM, Adam Young <ayo...@redhat.com> wrote:
>>
>>> Bug 968696 and System Roles.   Needs to be addressed across the Service
>>> catalog.
>>>
>>
>> Thanks Adam, will add it to the list. I see it's been open since 2012!
>>
>>
>>>
>>> On Mon, Jan 29, 2018 at 7:38 AM, Luke Hinds <lhi...@redhat.com> wrote:
>>>
>>>> Just a reminder as we have not had many uptakes yet..
>>>>
>>>> Are there any projects (new and old) that would like to make use of the
>>>> security SIG for either gaining another perspective on security challenges
>>>> / blueprints etc or for help gaining some cross project collaboration?
>>>>
>>>> On Thu, Jan 11, 2018 at 3:33 PM, Luke Hinds <lhi...@redhat.com> wrote:
>>>>
>>>>> Hello All,
>>>>>
>>>>> I am seeking topics for the PTG from all projects, as this will be
>>>>> where we try out are new form of being a SIG.
>>>>>
>>>>> For this PTG, we hope to facilitate more cross project collaboration
>>>>> topics now that we are a SIG, so if your project has a security need /
>>>>> problem / proposal than please do use the security SIG room where a larger
>>>>> audience may be present to help solve problems and gain x-project 
>>>>> consensus.
>>>>>
>>>>> Please see our PTG planning pad [0] where I encourage you to add to
>>>>> the topics.
>>>>>
>>>>> [0] https://etherpad.openstack.org/p/security-ptg-rocky
>>>>>
>>>>> --
>>>>> Luke Hinds
>>>>> Security Project PTL
>>>>>
>>>>
>>>>
>>>> 
>>>> __
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe: openstack-dev-requ...@lists.op
>>>> enstack.org?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>> --
>> Luke Hinds | NFV Partner Engineering | CTO Office | Red Hat
>> e: lhi...@redhat.com | irc: lh

Re: [openstack-dev] [ptg] Dublin PTG proposed track schedule

[Luke Hinds]

On Mon, Feb 5, 2018 at 3:07 PM, Thierry Carrez <thie...@openstack.org>
wrote:

> Luke Hinds wrote:
> > I had been monitoring for PTG room allocations, but I missed this email
> > which was the important one.
> >
> > The security SIG plans to meet at the PTG to discuss several topics. I
> > am to late to get our inclusion?
>
> Not too late, but obviously less choice... Would you be interested in a
> full day on Monday ? What room size do you need ?
>
> --
> Thierry Carrez (ttx)
>

A full day would be great, and room does not need to be large - I expect
between 5 to 10.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ptg] Dublin PTG proposed track schedule

[Luke Hinds]

On Tue, Jan 30, 2018 at 2:11 PM, Thierry Carrez 
wrote:

> Thierry Carrez wrote:
> > Here is the proposed pre-allocated track schedule for the Dublin PTG:
> >
> > https://docs.google.com/spreadsheets/d/e/2PACX-1vRmqAAQZA1rIzlNJpVp-X60-
> z6jMn_95BKWtf0csGT9LkDharY-mppI25KjiuRasmK413MxXcoSU7ki/
> pubhtml?gid=1374855307=true
>
> Following feedback I made small adjustments to Kuryr and
> OpenStack-Charms allocations. The track schedule is about to be
> published on the event website, so now is your last chance to signal
> critical issues with it!
>
> --
> Thierry Carrez (ttx)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


Hi Thierry,

I had been monitoring for PTG room allocations, but I missed this email
which was the important one.

The security SIG plans to meet at the PTG to discuss several topics. I am
to late to get our inclusion?

Luke
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [security] Security PTG Planning, x-project request for topics.

[Luke Hinds]

On Mon, Jan 29, 2018 at 2:29 PM, Adam Young <ayo...@redhat.com> wrote:

> Bug 968696 and System Roles.   Needs to be addressed across the Service
> catalog.
>

Thanks Adam, will add it to the list. I see it's been open since 2012!


>
> On Mon, Jan 29, 2018 at 7:38 AM, Luke Hinds <lhi...@redhat.com> wrote:
>
>> Just a reminder as we have not had many uptakes yet..
>>
>> Are there any projects (new and old) that would like to make use of the
>> security SIG for either gaining another perspective on security challenges
>> / blueprints etc or for help gaining some cross project collaboration?
>>
>> On Thu, Jan 11, 2018 at 3:33 PM, Luke Hinds <lhi...@redhat.com> wrote:
>>
>>> Hello All,
>>>
>>> I am seeking topics for the PTG from all projects, as this will be where
>>> we try out are new form of being a SIG.
>>>
>>> For this PTG, we hope to facilitate more cross project collaboration
>>> topics now that we are a SIG, so if your project has a security need /
>>> problem / proposal than please do use the security SIG room where a larger
>>> audience may be present to help solve problems and gain x-project consensus.
>>>
>>> Please see our PTG planning pad [0] where I encourage you to add to the
>>> topics.
>>>
>>> [0] https://etherpad.openstack.org/p/security-ptg-rocky
>>>
>>> --
>>> Luke Hinds
>>> Security Project PTL
>>>
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Luke Hinds | NFV Partner Engineering | CTO Office | Red Hat
e: lhi...@redhat.com | irc: lhinds @freenode | t: +44 12 52 36 2483
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [security] Security PTG Planning, x-project request for topics.

[Luke Hinds]

Just a reminder as we have not had many uptakes yet..

Are there any projects (new and old) that would like to make use of the
security SIG for either gaining another perspective on security challenges
/ blueprints etc or for help gaining some cross project collaboration?

On Thu, Jan 11, 2018 at 3:33 PM, Luke Hinds <lhi...@redhat.com> wrote:

> Hello All,
>
> I am seeking topics for the PTG from all projects, as this will be where
> we try out are new form of being a SIG.
>
> For this PTG, we hope to facilitate more cross project collaboration
> topics now that we are a SIG, so if your project has a security need /
> problem / proposal than please do use the security SIG room where a larger
> audience may be present to help solve problems and gain x-project consensus.
>
> Please see our PTG planning pad [0] where I encourage you to add to the
> topics.
>
> [0] https://etherpad.openstack.org/p/security-ptg-rocky
>
> --
> Luke Hinds
> Security Project PTL
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [security] Won't be able to make todays meeting

[Luke Hinds]

Hello,

I won't be able to attend the security project meeting today, and as there
are no hot topics I suggest we postpone until next week (if there are, then
feel free to #startmeeting and I will catch up tomorrow through meetbot
logs).

Cheers,

Luke
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] PTL Election Season

[Luke Hinds]

On Mon, Jan 15, 2018 at 5:04 PM, Kendall Nelson 
wrote:

> Election details: https://governance.openstack.org/election/
>
> Please read the stipulations and timelines for candidates and electorate
> contained in this governance documentation.
>
> Be aware, in the PTL elections if the program only has one candidate, that
> candidate is acclaimed and there will be no poll. There will only be a poll
> if there is more than one candidate stepping forward for a program's PTL
> position.
>
> There will be further announcements posted to the mailing list as action
> is required from the electorate or candidates. This email is for
> information purposes only.
>
> If you have any questions which you feel affect others please reply to
> this email thread.
>
> If you have any questions that you which to discuss in private please
> email any of the election judges[1] so that we may address your concerns.
>
>  Thank you,
>
> -Kendall Nelson (diablo_rojo)
>
> [1] https://governance.openstack.org/election/#election-officials
>

Keep in mind there will be no Security PTL election for rocky as we will be
changing to a SIG and will no longer be a project.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [security] Security PTG Planning, x-project request for topics.

[Luke Hinds]

Hello All,

I am seeking topics for the PTG from all projects, as this will be where we
try out are new form of being a SIG.

For this PTG, we hope to facilitate more cross project collaboration topics
now that we are a SIG, so if your project has a security need / problem /
proposal than please do use the security SIG room where a larger audience
may be present to help solve problems and gain x-project consensus.

Please see our PTG planning pad [0] where I encourage you to add to the
topics.

[0] https://etherpad.openstack.org/p/security-ptg-rocky

-- 
Luke Hinds
Security Project PTL
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [all] [security] Security SIG

[Luke Hinds]

Hi All,

Following on from the mailing list discussion [0], we now plan to change
the Security Project into a Special Interest Group (The Security SIG).

SIGs are a good match for an activity that centers around a topic or
practice that spans all the community (developers, operators, end
users...), by forming a guild of people with a shared interest. This rings
especially true for security, where changes are often needed cross-project
and not in a silo. A SIG will also (we hope) encourage more user / operator
involvement and lead to discussions of field centric security pains, which
can then be realised as specs and code.

One key point , there will be no change in our overall operations and
working structure. We will still continue to manage and care for the
Security Guide, OSSNs, Bandit, Threat Reviews, Syntribos as well as
encourage and incubate new security projects. We will of course also
continue to work with the VMT, and will keep a Sec-Core group for launchpad
that can work with embargoed issues.

The plan is to make the change at the coming release juncture (Queens ->
Rocky).

Shortly I will follow up with a PTG planning etherpad with a view to
encourage projects and operators / users to seed security related
discussions within the SIGs PTG room. We will also perform an s/Security
Group/Security SIG in the docs and Wiki around the time of the PTG / post
Queens release.

[0]
http://lists.openstack.org/pipermail/openstack-dev/2017-October/124053.html

Best Regards,

Luke
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [security] Security SIG

[Luke Hinds]

On Sat, Nov 18, 2017 at 8:34 PM, Jeremy Stanley <fu...@yuggoth.org> wrote:

> On 2017-11-03 07:49:05 + (+0000), Luke Hinds wrote:
> [...]
> > One thing came to mind on Jeremy's points around the VMT, is
> > OSSN's
> >
> > We often get a workflow where Sec-Core are brought into a private
> > LP bug to determine if its suitable for an OSSN, and it remains so
> > until we release the OSSN.
> >
> > So the option here is transfer OSSN into the VMT, or we keep
> > things as they are.
> [...]
>
> The VMT has operated fairly independently of the Security Team even
> while they were technically one project team from a governance
> perspective. In my opinion moving OSSN publications to the VMT makes
> little sense as those were always intended to be addenda/appendices
> of the Security Guide, which would presumably remain the purview of
> the new Security SIG. As you note the VMT already does a decent job
> of pulling the security notes editors into discussions if we
> determine an issue is out of scope for an advisory, and I don't see
> that process would need to change.
> --
> Jeremy Stanley
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
Let's keep it as it is then. We intend to keep the same access control /
structure when we move to a SIG, so I cannot see the work flow we have
changing (whereby you bring Sec-Core into the LP bug).
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [security] [api] Script injection issue

[Luke Hinds]

This will need the VMT's attention, so please raise as an issue on
launchpad and we can tag it as for the vmt members as a possible OSSA.

Apologies for top post, replying from phone.

On 17 Nov 2017 12:34 pm, "Adam Heczko"  wrote:

> Thanks TommyLike for this bug report. Sounds like Stored XSS [1].
> Could you please share more details, e.g. branch / release, APIs tested
> etc.?
>
> [1] https://www.owasp.org/index.php/Types_of_Cross-Site_Scripting
>
> On Fri, Nov 17, 2017 at 12:36 PM, Davanum Srinivas 
> wrote:
>
>> Adding [api] to make sure the API (SIG?) sees this too
>>
>> On Fri, Nov 17, 2017 at 3:22 AM, TommyLike Hu 
>> wrote:
>> > Hey all,
>> >  Recently when we integrating and testing OpenStack services. We
>> found
>> > there is a potential script injection issue that some of our services
>> accept
>> > the input with special character [1] [2], for instance we can create an
>> > instance or a volume with the name of 'script inside'.
>> One
>> > of the possible solutions is add HTML encode/decode support in Horizon,
>> but
>> > it's not guaranteed every OpenStack user is using Horizon. So should we
>> > apply more strict restriction on user's input?
>> >  Also, I found  Google Cloud have a strict and explicit restrction
>> in
>> > their instance insert API document [3].
>> >
>> > [1]: Nova:
>> > https://github.com/openstack/nova/blob/master/nova/api/valid
>> ation/parameter_types.py#L148
>> > [2]: Cinder:
>> > https://github.com/openstack/cinder/blob/master/cinder/api/o
>> penstack/wsgi.py#L1253
>> > [3]: Google Cloud:
>> > https://cloud.google.com/compute/docs/reference/latest/instances/insert
>> >
>> > Thanks
>> > TommyLike.Hu
>> >
>> >
>> >
>> > 
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe: openstack-dev-requ...@lists.op
>> enstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>>
>>
>> --
>> Davanum Srinivas :: https://twitter.com/dims
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Adam Heczko
> Security Engineer @ Mirantis Inc.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [security] Security SIG

[Luke Hinds]

On Mon, Oct 30, 2017 at 1:53 PM, Thierry Carrez <thie...@openstack.org>
wrote:

> Luke Hinds wrote:
> > On Fri, Oct 27, 2017 at 6:08 PM, Jeremy Stanley <fu...@yuggoth.org
> > <mailto:fu...@yuggoth.org>> wrote:
> >
> >> On 2017-10-27 15:30:34 +0200 (+0200), Thierry Carrez wrote:
> >>> [...]
> >>> I think the Security project team would benefit from becoming a
> >>> proper SIG.
> >>> [...]
> >> I tend to agree, though it's worth also considering what the
> >> implications are for vulnerability management under the new model.
> >> The VMT tended to act as an independent task force in the
> >> beforetime, until the big t^W^Wproject reform of 2014, and then
> >> allied itself with the newly-formed Security Team while continuing
> >> operation autonomously under a fairly independent mandate. Does this
> >> still make sense in a Security SIG context, or should we be
> >> considering alternative (perhaps more formal?) governance for the
> >> VMT in that scenario? I don't have especially cogent thoughts around
> >> this yet, so interested to hear what others in the community think.
>
> So the activity of the Security project team can be split into a number
> of things:
>
> - Security advisories for supported projects (ossa by the VMT subteam)
> - General security notices / information (ossn)
> - Promotion of secure coding practices (bandit, syntribos)
> - Promotion of secure operations (security-doc, anchor)
> - Audit activities (security-analysis)
>
> The only thing here that is not performed by an open group is the VMT
> stuff. It also happens to be the most "upstream" of all the team
> activity: it's closely related to stable branch maintenance.
>
> Personally I think the VMT would be better split off from a Security SIG
> -- it's suboptimal to have a part of a SIG to be a restricted group. It
> could be made it's own team, or attached to an existing group (stable
> branch maintenance) or converted to a TC-owned "workgroup" (a TC
> delegation of power, like it's always been).
>
> > We discussed the SIG proposal on the security meeting and I planned to
> > invite you in for a session to discuss Thierry (apologies for being late
> > for getting this together).
> >
> > Overall folks thought it an idea worth while enough to explore further.
> >
> > My own view is that if its leads to getting more eyes on security, then
> > its a good thing. With that in mind, I had the idea that we could run a
> > "Security SIG" in parallel to the security project and see if it gains
> > traction and security minded people from the wider community do actually
> > come forward to get involved and merit the change worth while (and it's
> > not just the Security Project rearranging the furniture). We could then
> > review how its gone at the end of the Queens cycle and if a success (not
> > sure how we would define that as yet), then implement the change at the
> > juncture of a new release.
>
> Sure, we can definitely try it out and keep the project team around
> while we try. The only issue I see with that approach is that it's a bit
> confusing, and not as strong of a statement compared to saying "all the
> security activity now happens there". But if you feel more comfortable
> that way, we can definitely follow that road.
>
> --
> Thierry Carrez (ttx)


One thing came to mind on Jeremy's points around the VMT, is OSSN's

We often get a workflow where Sec-Core are brought into a private LP bug to
determine if its suitable for an OSSN, and it remains so until we release
the OSSN.

So the option here is transfer OSSN into the VMT, or we keep things as they
are.

Something else which comes to mind; it seems to me we are more of a
'working group', are working groups no longer a thing in OpenStack? - SIG
seems like a better fit for topics focused mainly on cross project
collaborations efforts (API's being a good example), whereas we have a lot
of group like tasks that we handle in silo?
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [security] Security SIG

[Luke Hinds]

On Fri, Oct 27, 2017 at 6:08 PM, Jeremy Stanley  wrote:

> On 2017-10-27 15:30:34 +0200 (+0200), Thierry Carrez wrote:
> [...]
> > I think the Security project team would benefit from becoming a
> > proper SIG.
> [...]
>
> I tend to agree, though it's worth also considering what the
> implications are for vulnerability management under the new model.
> The VMT tended to act as an independent task force in the
> beforetime, until the big t^W^Wproject reform of 2014, and then
> allied itself with the newly-formed Security Team while continuing
> operation autonomously under a fairly independent mandate. Does this
> still make sense in a Security SIG context, or should we be
> considering alternative (perhaps more formal?) governance for the
> VMT in that scenario? I don't have especially cogent thoughts around
> this yet, so interested to hear what others in the community think.
> --
> Jeremy Stanley
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>

We discussed the SIG proposal on the security meeting and I planned to
invite you in for a session to discuss Thierry (apologies for being late
for getting this together).

Overall folks thought it an idea worth while enough to explore further.

My own view is that if its leads to getting more eyes on security, then its
a good thing. With that in mind, I had the idea that we could run a
"Security SIG" in parallel to the security project and see if it gains
traction and security minded people from the wider community do actually
come forward to get involved and merit the change worth while (and it's not
just the Security Project rearranging the furniture). We could then review
how its gone at the end of the Queens cycle and if a success (not sure how
we would define that as yet), then implement the change at the juncture of
a new release.
Luke
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Regarding Multi-Factor Authentication

[Luke Hinds]

On Thu, Oct 12, 2017 at 11:49 PM, Puneet Jain <punitj...@csu.fullerton.edu>
wrote:

> Hi All,
>
> The OpenStack login screen has just login name and password for
> validation. Now, if someone writes a script to perform DoS attacks by
> sending a lot of fake login requests, the server will easily become
> unavailable.
>

If you have found an exploit please raise it in launchpad and mark as
security bug for the VMT to look at.


> I know there is a section in the security page which talks about
> multi-factor authentication. However, each organization has to implement
> this at their own (Correct me if I am wrong here).
>
> Questions
>
> Is there any property based solution to provide multifactor
> authentication? Like, the multi-factor implementation would be a part of
> OpenStack installation but would be unavailable by default and if an
> organization enables that property, they will have the multifactor
> authentication enabled.
>
> I apologize if my question is very basic. I am quite new to OpenStack.
>
>
>
So keystone is an *identity service*, it's not positioned as being an
*identity provider* (although it can act as a basic provider by using an
instance of mariadb, but this is not the norm for production deployments).
Instead a typical deployment will have third party systems act as identity
provider, and this could be in any form such as LDAP, Active Directory
and SAML / OpenID via Federation. The operator would then implement MFA in
their chosen identity provider.

I recommend a read of this:

https://docs.openstack.org/keystone/latest/advanced-
topics/federation/federated_identity.html

For this reason, its unlikely that Keystone will provide MFA out of the box.



> --
> Best
> Regards,
> Puneet Jain
>
> <https://www.linkedin.com/pub/puneet-jain/20/917/a54>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Luke Hinds | NFV Partner Engineering | Office of Technology | Red Hat
e: lhi...@redhat.com | irc: lhinds @freenode | m: +44 77 45 63 98 84 | t: +44
12 52 36 2483
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Project Ideas for Graduate Student

[Luke Hinds]

On Thu, Oct 5, 2017 at 11:37 PM, Mike Perez  wrote:

> On 15:27 Oct 05, Mike Perez wrote:
> > On 02:59 Oct 05, Puneet Jain wrote:
> > > Hello all,
> > >
> > > I am a graduate student and have intermediate knowledge and huge in
> cloud
> > > computing. I am looking for a project idea, particularly any new
> feature I
> > > can implement in OpenStack.
> > >
> > > I thought of implementing multi-factor authentication but happened to
> know
> > > that it has already been implemented.
> > > https://docs.openstack.org/security-guide/identity/authentication.html
> > >
> > > I would prefer to do something in security. Any ideas?
> > >
> > > Looking forward to hearing from you guys. Thanks in advance!
> >
> > Welcome to the community Puneet! We have various Security group related
> > projects listed here:
> >
> > https://wiki.openstack.org/wiki/Security
> >
> > You can also find various Security/Identity/Compliance OpenStack project
> > services listed in our project navigator:
> >
> > https://www.openstack.org/software/project-navigator/
> >
> > Also on freenode irc we have #openstack-security. You can see more
> channels:
> >
> > https://wiki.openstack.org/wiki/IRC
> >
> > Here are some helpful documents in setting up IRC, git, and the various
> > accounts you'll be using in our community:
> >
> > https://docs.openstack.org/upstream-training/irc.html
> > https://docs.openstack.org/upstream-training/git.html
> > https://docs.openstack.org/upstream-training/accounts.html
> >
> > --
> > Mike Perez
>
> Actually this account setup documentation is more up-to-date and better:
>
> https://docs.openstack.org/infra/manual/developers.html#account-setup
>
> --
> Mike Perez
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



Further to what is already said, you're welcome to join us on the weekly
security meeting where we discuss security projects such as Bandit
(security lint scanner) and Syntribos (API fuzzer). We also help incubate
new projects if you have some ideas you would like to float.

We meet on freenode IRC channel #openstack-meeting-alt @ 17:00 UTC each
week.

As mentioned there is also Barbican who meet as well
on #openstack-meeting-alt Monday @ 20.00 UTC and are very welcoming group
of folks who welcome new contributions.

Welcome to come along and say hi!
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OSSN-0082] Heap and Stack based buffer overflows in dnsmasq prior to version 2.78

[Luke Hinds]

Heap and Stack based buffer overflows in dnsmasq prior to version 2.78
--

### Summary ###
A series of heap and stack based buffer overflows have been discovered
in versions of dnsmasq prior to release 2.78.

### Affected Services / Software ###
Any neutron based OpenStack deployment on a version of dnsmasq prior to
2.78.

### Discussion ###
The following attack vectors have been assigned the following CVE numbers.

* CVE-2017-14491
* CVE-2017-14492
* CVE-2017-14493
* CVE-2017-14494
* CVE-2017-14495
* CVE-2017-14496
* CVE-2017-13704

Each of these CVE's exposes a neutron based OpenStack deployment to
various attacks such as leakage of sensitive memory information or
causing a denial of service. Nodes are exposed to this risk by the
crafting of various nefarious DNS or DHCP requests.

### Recommended Actions ###
Operators should update the dnsmasq service using the affected nodes
operating systems packaging tools to version 2.78 and later, or a
distribution packaged version that contains relevant backports for these
vulnerabilities.

### Contacts / References ###
Author: Luke Hinds <lhi...@redhat.com>
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0082
Mailing List : [Security] tag on openstack-dev@lists.openstack.org
Launchpad Bug: https://bugs.launchpad.net/neutron/+bug/1721063
CVE: CVE-2017-14491
OpenStack Security Project : https://launchpad.net/~openstack-ossg



signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Security of Meta-Data

[Luke Hinds]

On Tue, Oct 3, 2017 at 11:00 PM, Giuseppe de Candia <
giuseppe.decan...@gmail.com> wrote:

> Hi Folks,
>
>
> Are there any documented conventions regarding the security model for
> MetaData?
>
>
> Note that CloudInit allows passing user and ssh service public/private
> keys via MetaData service (or ConfigDrive). One assumes it must be secure,
> but I have not found a security model or documentation.
>
>
> My understanding of the Neutron reference implementation is that MetaData
> requests are HTTP (not HTTPS) and go from the VM to the MetaData proxy on
> the Network Node (after which they are proxied to Nova meta-data API
> server). The path from VM to Network Node using HTTP cannot guarantee
> confidentiality and is also susceptible to Man-in-the-Middle attacks.
>
>
> Some Neutron drivers proxy Metadata requests locally from the node hosting
> the VM that makes the query. I have mostly seen this presented/motivated as
> a way of removing dependency on the Network node, but it should also
> increase security. Yet, I have not seen explicit discussions of the
> security model, nor any attempt to set a standard for security of the
> meta-data.
>
> Finally, there do not seem to be granular controls over what meta-data is
> presented over ConfigDrive (when enabled) vs. meta-data REST API. As an
> example, Nova vendor data is presented over both, if both are enabled;
> config drive is presumably more secure.
>
> thanks,
> Pino
>
>
>
The recommendation is not to use metadata for security sensitive data (its
possible to spoof by setting a X-Forwarded header), please see the
following OpenStack Security Note on the topic:

https://wiki.openstack.org/wiki/OSSN/OSSN-0074
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Glance][Security] Secure Hash Algorithm Spec

[Luke Hinds]

On Fri, Sep 29, 2017 at 5:31 PM, Jay Pipes <jaypi...@gmail.com> wrote:

> On 09/29/2017 06:19 AM, Luke Hinds wrote:
>
>> On Thu, Sep 28, 2017 at 8:38 PM, McClymont Jr, Scott <
>> scott.mcclym...@verizonwireless.com <mailto:scott.mcclymont@verizo
>> nwireless.com>> wrote:
>>
>> Hey All,
>>
>> I've got a spec up for a change I want to implement in Glance for
>> Queens to enhance the current checksum (md5) functionality with a
>> stronger hash algorithm. I'm going to do this in such a way that it
>> is easily altered in the future for new algorithms as they are
>> released.  I'd appreciate it if someone on the security team could
>> look it over and comment. Thanks.
>>
>> Review: https://review.openstack.org/#/c/507568/
>> <https://review.openstack.org/#/c/507568/>
>>
>>
>> +1 , thanks for undertaking this work. Strong support from the security
>> projects side.
>>
>> Would be good to see all projects move on from MD5 use now, its been
>> known to be insecure for sometime and clashes with FIPS-142 compliance.
>>
>
> In the case of Glance's use of MD5 for checksums, it is used to identify
> whether a particular array of bytes that represents an image has changed.
> The client uploads a bytestream to Glance, which does a rolling checksum of
> that byte data for each chunk received and writes the checksum to the
> database upon completion of the upload.
>
> That checksum number never changes since Glance images are immutable once
> uploaded.
>
> Can someone please inform me how changing the checksum algorithm for this
> operation to SHA-1 or something else would improve the security of this
> operation?
>


As I understand it, MD5 has been proven to be susceptible to collision
attacks, so its possible to generate the same hash from two blobs. The same
is also true for SHA-1, and can't be out ruled this may also be the case
for strong cryptos (SHA 256, 512 etc) in the future.


> As someone who recently had to go through thousands of (mostly bogus)
> entries in a spreadsheet generated from the Bandit "security scanning
> tool", I'd like to ask that we approach these kinds of things with some
> common sense and not just as a checking-the-box-off activity.
>

understood, you may already know this, but you can make a # nosec on the
line using hashlib.md5 and Bandit will not false positive. It might seem a
pain it reporting on md5, but it has highlighted a few occurrences of
people using weak hashes for salting , integrity checks etc.

>
> md5 is used in a number of places in many OpenStack services, and often
> those uses have nothing to do with cryptography. Rather, in those cases md5
> is used as a simple mechanism to generate a hash from a name. [1]
>
> All I ask is that we don't have an army of people going out and replacing
> blindly all uses of the MD5 algorithm everywhere, since (as I learned
> recently) that will just lead to a lot of busywork for little gain.
>

I do see you're point, some network protocols also use md5 purely for error
checking, not computing. In OpenStack swift uses MD5 for a non security
case, and its no simple swap out for them.

If anything it would be ideal to insure anyone implementing new
functionality, not use md5 and if anyone can easily swap out uses of md5 /
sha1 then its worth doing, as there may be an edge case not yet seen that
it opens up a hole.


>
> Best,
> -jay
>
> [1] https://github.com/openstack/nova/blob/master/nova/utils.py#L1067
>
>
>
> ______
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Luke Hinds | NFV Partner Engineering | Office of Technology | Red Hat
e: lhi...@redhat.com | irc: lhinds @freenode | m: +44 77 45 63 98 84 | t: +44
12 52 36 2483
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][infra] Zuul v3 migration update

[Luke Hinds]

On Fri, Sep 29, 2017 at 2:40 AM, Clark Boylan  wrote:

> On Wed, Sep 27, 2017, at 03:24 PM, Monty Taylor wrote:
> > Hey everybody,
> >
> > We're there. It's ready.
> >
> > We've worked through all of the migration script issues and are happy
> > with the results. The cutover trigger is primed and ready to go.
> >
> > But as it's 21:51 UTC / 16:52 US Central it's a short day to be
> > available to respond to the questions folks may have... so we're going
> > to postpone one more day.
> >
> > Since it's all ready to go we'll be looking at flipping the switch first
> > thing in the morning. (basically as soon as the West Coast wakes up and
> > is ready to go)
> >
> > The project-config repo should still be considered frozen except for
> > migration-related changes. Hopefully we'll be able to flip the final
> > switch early tomorrow.
> >
> > If you haven't yet, please see [1] for information about the transition.
> >
> > [1] https://docs.openstack.org/infra/manual/zuulv3.html
> >
>
> Its done! Except for all the work to make jobs run properly. Early today
> (PDT) we converted everything over to our auto generated Zuulv3 config.
> Since then we've been working to address problems in job configs.
>
> These problems include:
> Missing inclusion of the requirements repo for constraints in some
> jobs
> Configuration of python35 unittest jobs in some cases
> Use of sudo checking not working properly
> Multinode jobs not having multinode nodesets
>
> Known issues we will continue to work on:
> Multinode devstack and grenade jobs are not working quite right
> Releasenote jobs not working due to use of origin/ refs in git
> It looks like we may not have job branch exclusions in place for all
> cases
> The zuul-cloner shim may not work in all cases. We are tracking down
> and fixing the broken corner cases.
>
> Keep in mind that with things in flux, there is a good chance that
> changes enqueued to the gate will fail. It is a good idea to check
> recent check queue results before approving changes.
>
> I don't think we've found any deal breaker problems at this point. I am
> sure there are many more than I have listed above. Please feel free to
> ask us about any errors. For the adventurous, fixing problems is likely
> a great way to get familiar with the new system. You'll want to start by
> fixing errors in openstack-infra/openstack-zuul-jobs/playbooks/legacy.
> Once that stabilizes the next step is writing native job configs within
> your project tree. Documentation can be found at
> https://docs.openstack.org/infra/manual/zuulv3.html. I expect we'll
> spend the next few days ironing out the transition.
>
> Thank you for your patience,
> Clark
>
>
Hi,

We have a couple of failures in Bandit's gvate I wanted to flag up (fungi
believes it might be from missing openstack/requirements as a required repo
in the job definition):

Glance Store:

http://logs.openstack.org/44/504544/6/check/legacy-bandit-integration-glance_store/900f88a/job-output.txt.gz


Magnum client:

http://logs.openstack.org/44/504544/6/check/legacy-bandit-integration-python-magnumclient/ba50a54/job-output.txt.gz

Thanks, and do let me know if I need to do anything on Bandits side.

Luke
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Glance][Security] Secure Hash Algorithm Spec

[Luke Hinds]

On Thu, Sep 28, 2017 at 8:38 PM, McClymont Jr, Scott <
scott.mcclym...@verizonwireless.com> wrote:

> Hey All,
>
> I've got a spec up for a change I want to implement in Glance for Queens
> to enhance the current checksum (md5) functionality with a stronger hash
> algorithm. I'm going to do this in such a way that it is easily altered in
> the future for new algorithms as they are released.  I'd appreciate it if
> someone on the security team could look it over and comment. Thanks.
>
> Review: https://review.openstack.org/#/c/507568/
>
>
+1 , thanks for undertaking this work. Strong support from the security
projects side.

Would be good to see all projects move on from MD5 use now, its been known
to be insecure for sometime and clashes with FIPS-142 compliance.



> --
> Scott McClymont
> Sr. Software Engineer
> Verizon Cloud Platform
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [api-wg][glance] call for comments on Glance spec for Queens

[Luke Hinds]

On Fri, Sep 29, 2017 at 3:08 AM, Brian Rosmaita 
wrote:

> Hello API WG,
>
> I've got a patch up for a proposal to fix OSSN-0075 by introducing a
> new policy.  There are concerns that this will introduce an
> interoperability problem in that an API call that works in one
> OpenStack cloud may not work in other OpenStack clouds.  As author of
> the spec, I think this is an OK trade-off to fix the security issue,
> but not all members of the Glance community agree, so we're trying to
> get some wider perspective.  We'd appreciate it if some API-WG members
> could take a look and leave a comment:
>
> https://review.openstack.org/#/c/468179/
>
> If you could respond by Tuesday 3 October, that would give us time to
> get this worked out before the spec freeze (6 October).
>
> thanks,
> brian
>
>
+1 for efforts to take this forward and find a resolution, from a security
standpoint it would be good to see this solved.

Luke

__
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
> 
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OSSN-0081] sha512_crypt is insufficient for password hashing

[Luke Hinds]

sha512_crypt is insufficient for password hashing
-

### Summary ###

Use of sha512_crypt for password hashing in versions of Keystone prior
to Pike, is insufficient and provides limited protection against
brute-forcing of password hashes.

### Affected Services / Software ###
OpenStack Identity Service (Keystone). OpenStack Releases Ocata, Newton.

### Discussion ###

Keystone uses sha512_crypt for password hashing. This provides
insufficient and limited protection, since sha512_crypt algorithm has a
low computational cost factor, therefore making it easier to crack
passwords offline in a short period of time.

The correct mechanism is to use the more secure hashing algorithms with
a higher computational cost factor such as bcrypt, scrypt, or
pbkdf2_sha512 instead of sha512_crypt.

### Recommended Actions ###

It is recommended that operators upgrade to the Pike release where all
future passwords would be bcrypt hashed.

Operators should also force password changes on all users [1], which
will result in the users newly generated passwords being bcrypt hashed.

### Contacts / References ###
Author: Luke Hinds <lhi...@redhat.com>
[1]:
https://docs.openstack.org/keystone/latest/admin/identity-security-compliance.html#force-users-to-change-password-upon-first-use
[2] http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63b.pdf
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0081
Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1668503
Mailing List : [Security] tag on openstack-dev@lists.openstack.org
OpenStack Security Project : https://launchpad.net/~openstack-ossg



signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [barbican] [security] custodia @ PTG

[Luke Hinds]

Hi Raildo,

That's great news. Are you around next Thursday to jump on
#openstack-meeting-alt at 17:00 UTC? we can then go over some topics.

@Dave, unless you prefer to use the Barbican meeting that is (possible
synergies to barbican)?

Regards,

Luke

On Thu, Aug 17, 2017 at 1:10 PM, Raildo Mascena de Sousa Filho <
rmasc...@redhat.com> wrote:

> Hi Luke,
>
> I'll definitely be there, sounds like a great idea, so we can clarify a
> lot of topics and make progress in the community together.
>
> Cheers,
>
>
> On Thu, Aug 17, 2017 at 5:52 AM Luke Hinds <lhi...@redhat.com> wrote:
>
>> Hi Raildo,
>>
>> Both Barbican and Security have an interest in custodia and we have it
>> marked down as a topic / discussion point for the PTG [1]
>>
>> Would you be interested / willing to join the Barbican room on Thurs /
>> Fri and propose a walk through / overview etc?
>>
>> [1] https://etherpad.openstack.org/p/barbican-ptg-queens
>>
>>
>> Regards,
>>
>> Luke
>>
> --
>
> Raildo mascena
>
> Software Engineer, Identity Managment
>
> Red Hat
>
> <https://www.redhat.com>
> <https://red.ht/sig>
> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
>



-- 
Luke Hinds | NFV Partner Engineering | Office of Technology | Red Hat
e: lhi...@redhat.com | irc: lhinds @freenode | m: +44 77 45 63 98 84 | t: +44
12 52 36 2483
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OSSN 0080] Aodh can be used to launder Keystone trusts

[Luke Hinds]

Aodh can be used to launder Keystone trusts
---

### Summary ###

When adding an alarm action with the scheme `trust+http:` Aodh does not
verify that the user creating the alarm is the trustor or has the same
rights as the trustor, not that the trust is for the same project as the
alarm.

### Affected Services / Software ###

Aodh the alarm engine of the Telemetry project.

Pike, Ocata and Newton

### Discussion ###

When adding an alarm action with the scheme `trust+http:`, Aodh allows
the user to provide a trust ID to acquire a token with which to make a
webhook request. (If no trust ID is provided then Aodh creates a trust
internally, in which case the issue is not present.) However, Aodh makes
no attempt to verify that the user creating the alarm is the trustor or
has the same rights as the trustor - it also does not attempt to check
that the trust is for the same project as the alarm.

The nature of the `trust+http:` alarm notifier is that it allows the
user to obtain a token given the ID of a trust for which Aodh is the
trustee, since the URL is arbitrary and not limited to services in the
Keystone catalog.

### Recommended Actions ###

A patchfile is attached to the launchpad bug referenced below. It will
block use of trust URLs which contain trust ID's and log an error
message of "trust URL cannot contain a trust ID.". Any trust action
without a trust ID will result in Aodh internally creating a trust ID as
before.

You will also need to restart the web server used for Aodh API. This is
typically apache. In cases of eventlet (in older versions) it will
require restart openstack-aodh-api for centos/RHEL/Suse and aodh-api
for ubuntu.

The fix has also been merged to master (Pike), Ocata and Newton.

### Contacts / References ###
Discoverer: Zane Bitter, Red Hat
Author: Luke Hinds, Red Hat
CVE: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-12440
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0080
Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1649333
OpenStack Security Project : https://launchpad.net/~openstack-ossg



signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [barbican] [security] custodia @ PTG

[Luke Hinds]

Hi Raildo,

Both Barbican and Security have an interest in custodia and we have it
marked down as a topic / discussion point for the PTG [1]

Would you be interested / willing to join the Barbican room on Thurs / Fri
and propose a walk through / overview etc?

[1] https://etherpad.openstack.org/p/barbican-ptg-queens


Regards,

Luke
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [security] Security Meeting next week

[Luke Hinds]

Hi,

It was decided that the Security Project meeting would not be held next
week, and will instead reconvene on the 17th of August.

Regards,

Luke
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [security][barbican] PTG room sharing

[Luke Hinds]

On Tue, Aug 1, 2017 at 5:28 PM, Dave McCowan (dmccowan) <dmcco...@cisco.com>
wrote:

>
>
> On 8/1/17, 12:21 PM, "Thierry Carrez" <thie...@openstack.org> wrote:
>
> >Luke Hinds wrote:
> >> Thanks Dave, I will let Kendall know that we can free up the room from
> >> Mon / Tuesday, and instead have the sec proj join barbican on Wed /
> >>Thur.
> >
> >Note that we have extra room on Monday/Tuesday, so it would be OK to
> >keep the room to have cross-project "security discussions", even if
> >you'll have your team internal-facing meetings on Wed-Fri...
> >
> >For example we could use the time to advance the discussion around
> >making Castellan/barbican a base service that every other project can
> >depend on being present. Or any other cross-project discussion with a
> >security focus.
> >
> >--
> >Thierry Carrez (ttx)
>
> Thanks!  I'd like to keep the room available for potential cross-project
> meetings.  In Atlanta, we did have project teams drop in to discuss how to
> integrate with Castellan/Barbican.
>
>
Sounds good to me, unfortunately I won't be arriving until Tues, but if it
helps foster Castellan/Barbican discussions you should go for it.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [elections][security] Candidacy for Security Project PTL (Queens)

[Luke Hinds]

Hello All,

I would like to announce my candidacy for Security Project PTL for
Queens.

I have been a member of the Security Project for 2-3 years, and a
core member for one year.

During my tenure as core I have managed public and embargoed security
notes and contributed with my feedback to the VMT team on OpenStack
vulnerabilities.

I have also been an active contributor to the security guide as well as a
regular reviewer. I am the current driver for the security guide
launchpad page.

As PTL, I'd like to focus on the following things:

* Documentation

I am currently planning a revamp of the Security guide to bring it up to
date with Pike. To do this I will reach out to other projects to help
validate the information in the guide is technically correct and up to
date.

I also would like to migrate the checklists into a format that can be
easily filtered to a specific release, thereby allowing other security
tools and processes to easily consume the content and gain a snapshot
of what security actions are required to harden any given release.

I also plan to encourage others to get involved, with topics arranged for
the coming PTG on key management.

* Support and championing of OpenStack security projects.

I would like to put forward continued support by means of reviews and
feedback for the projects currently having their home under the
security project, and I have plans to propose further projects. Our
close synergy with the Barbican project should continue to be fostered,
and encouraged.

* Perform Threat Analysis with further projects

The Threat Analysis project has proved very useful in helping the VMT
and operators understand the threat landscape pertinent to each OpenStack
project. I will work with and encourage other projects to undergo threat
analysis.

* Encourage more contributions and grow some new cores

The security project has lost a good number of core members due to
companies shifting priorities, so I would like increase the projects
exposure with blog posts to planet.openstack.org and by outreach at
various other tech events. I see it as vital to keep the security
project afloat, as operators rely so much on the project for
guidance on securing OpenStack clouds.

Regards,

Luke Hinds (lhinds)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [security][barbican] PTG room sharing

[Luke Hinds]

On Tue, Aug 1, 2017 at 2:50 PM, Dave McCowan (dmccowan) 
wrote:

>
> Hello Barbican Team,
>
> I believe there were some discussions on room sharing between the security
> project and barbican team.
>
> We are still keen on this in the security project. How would you like to
> work out logistics?
>
> Should we share PTG planning etherpads?
>
> We have 4 days between us, not sure if we will need all four, did you have
> anything in mind here? So far I don't expect the security project will need
> more then a day at max (if that).
>
> p.s. I am plan to come onto the Barbican irc weekly meeting, if you prefer
> to sketch out the details there.
>
> Regards,
>
> Luke
>
>
> Hi Luke--
> We'd be happy to continue of tradition of sharing mid-cycle/PTG
> meeting time and place.
> Per the schedule, Security has a room reserved Monday and Tuesday;
> Barbican has a room reserved Wednesday and Thursday.
> Our etherpad is here: https://etherpad.openstack.org/p/barbican-ptg-
> queens.
>
> Anyone with an interest in key management, encryption, or other
> security topics please feel welcome to join us and add your name and topics
> to the etherpad.
>
> Thanks!
> --Dave
>

Thanks Dave, I will let Kendall know that we can free up the room from Mon
/ Tuesday, and instead have the sec proj join barbican on Wed / Thur.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [security][barbican] PTG room sharing

[Luke Hinds]

Hello Barbican Team,

I believe there were some discussions on room sharing between the security
project and barbican team.

We are still keen on this in the security project. How would you like to
work out logistics?

Should we share PTG planning etherpads?

We have 4 days between us, not sure if we will need all four, did you have
anything in mind here? So far I don't expect the security project will need
more then a day at max (if that).

p.s. I am plan to come onto the Barbican irc weekly meeting, if you prefer
to sketch out the details there.

Regards,

Luke
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OSSN-0078] Ceph credentials included in logs using older versions of libvirt/qemu

[Luke Hinds]

Ceph credentials included in logs using older versions of libvirt/qemu
--

### Summary ###
Older versions of libvirt included network storage authentication
information on the qemu command line. If libvirt raises an exception
which logs the qemu command line it used, for example an error starting
a domain, this authentication information will available in the logs.

### Affected Services / Software ###
Versions 2.5 and earlier of QEMU and libvirt versions of 2.1 or earlier.

The issue has been resolved in all QEMU versions 2.6 and above and
libvirt 2.2 and above.

No patches or specific releases of Nova or Ceph are required, the
issue is completely resolved in QEMU and libvirt.

### Discussion ###
If a deployment is using ceph, a libvirt error starting a domain would
log the cephx secret key and the monitor addresses on the qemu command
line.

A local attacker could then use this flaw to gain access of the cephx
secret key and perform certain privileged operations within the cluster.

An existing CVE is already present for this issue.

### Recommended Actions ###
The issue has been resolved upstream. Users running qemu version 2.6 or
later, and libvirt version 2.2 or later, are not vulnerable.

No change is required in Nova or Ceph to resolve this issue.

### Contacts / References ###
Author: Luke Hinds, Red Hat
https://access.redhat.com/security/cve/CVE-2015-5160
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0079
Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1686743
OpenStack Security Project : https://launchpad.net/~openstack-ossg



signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] Forming our plans around Ansible

[Luke Hinds]

On Fri, Jul 7, 2017 at 10:17 PM, James Slagle <james.sla...@gmail.com>
wrote:

> On Fri, Jul 7, 2017 at 5:00 PM, Luke Hinds <lhi...@redhat.com> wrote:
> > I can't offer much in-depth feedback on the pros and cons of each
> scenario.
> > My main point would be to try and simplify as much as we can, rather then
> > adding yet more tooling to the stack. At the moment ooo is spread across
> > multi repos and events are handed around multiple tool sets and queues.
> This
> > adds to a very steep learning curve for the folk who have to operate
> these
> > systems, as there are multiple moving parts to contend with. At the
> moment
> > things seem 'duck taped' together, so we should avoid adding more
> > complexity, and refactor down to a simpler architecture instead.
> >
> > With that in mind [1] sounds viable to myself, but with the caveat that
> > others might have a better view of how much of a fit that is for what we
> > need.
>
> Agreed, I think the goal ought to be a move towards simplification
> with Ansible at the core.
>
> An ideal scenario for me personally would be a situation where
> operators could just run Ansible in the typical way that they do today
> for any other project. Additionally, we'd have a way to execute the
> same Ansible playbook/roles/vars/whatever via Mistral so that we had a
> common API for our CLI and UI.
>
> Perhaps the default would be to go through the API, and more advanced
> usage could interface with Ansible directly.
>

I like the sound of this approach, as we then have a API for driving
complex deployment and upgrades, but if an operator needs to troubleshoot
or customise, they can do so with pure play ansible. Yet mistral is there
to drive the main complexity of a full openstack deployment.


> Additionally, we must have a way to maintain backwards compatibility
> with our existing template interfaces, or at least offer some form of
> migration tooling.
>
> Thanks for your feedback.
>
> --
> -- James Slagle
> --
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Luke Hinds | NFV Partner Engineering | Office of Technology | Red Hat
e: lhi...@redhat.com | irc: lhinds @freenode | m: +44 77 45 63 98 84 | t: +44
12 52 36 2483
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] Forming our plans around Ansible

[Luke Hinds]

On Fri, Jul 7, 2017 at 6:50 PM, James Slagle  wrote:

> I proposed a session for the PTG
> (https://etherpad.openstack.org/p/tripleo-ptg-queens) about forming a
> common plan and vision around Ansible in TripleO.
>
> I think it's important however that we kick this discussion off more
> broadly before the PTG, so that we can hopefully have some agreement
> for deeper discussions and prototyping when we actually meet in
> person.
>
> Right now, we have multiple uses of Ansible in TripleO:
>
> (0) tripleo-quickstart which follows the common and well accepted
> approach to bundling a set of Ansible playbooks/roles.
>
> (1) Mistral calling Ansible. This is the approach used by
> tripleo-validations where Mistral directly executes ansible playbooks
> using a dynamic inventory. The inventory is constructed from the
> server related stack outputs of the overcloud stack.
>
> (2) Ansible running playbooks against localhost triggered by the
> heat-config Ansible hook. This approach is used by
> tripleo-heat-templates for upgrade tasks and various tasks for
> deploying containers.
>
> (3) Mistral calling Heat calling Mistral calling Ansible. In this
> approach, we have Mistral resources in tripleo-heat-templates that are
> created as part of the overcloud stack and in turn, the created
> Mistral action executions run ansible. This has been prototyped with
> using ceph-ansible to install Ceph as part of the overcloud
> deployment, and some of the work has already landed. There are also
> proposed WIP patches using this approach to install Kubernetes.
>
> There are also some ideas forming around pulling the Ansible playbooks
> and vars out of Heat so that they can be rerun (or run initially)
> independently from the Heat SoftwareDeployment delivery mechanism:
>
> (4) https://review.openstack.org/#/c/454816/
>
> (5) Another idea I'd like to prototype is a local tool that runs on
> the undercloud and pulls all of the SoftwareDeployment data out of
> Heat as the stack is being created and generates corresponding Ansible
> playbooks to apply those deployments. Once a given playbook is
> generated by the tool, the tool would signal back to Heat that the
> deployment is complete. Heat then creates the whole stack without
> actually applying a single deployment to an overcloud node. At that
> point, Ansible (or Mistral->Ansible for an API) would be used to do
> the actual deployment of the Overcloud with the Undercloud as the
> ansible runner.
>
> All of this work has merit as we investigate longer term plans, and
> it's all at different stages with some being for dev/CI (0), some
> being used already in production (1 and 2), some just at the
> experimental stage (3 and 4), and some does not exist other than an
> idea (5).
>
> My intent with this mail is to start a discussion around what we've
> learned from these approaches and start discussing a consolidated plan
> around Ansible. And I'm not saying that whatever we come up with
> should only use Ansible a certain way. Just that we ought to look at
> how users/operators interact with Ansible and TripleO today and try
> and come up with the best solution(s) going forward.
>
> I think that (1) has been pretty successful, and my idea with (5)
> would use a similar approach once the playbooks were generated.
> Further, my idea with (5) would give us a fully backwards compatible
> solution with our existing template interfaces from
> tripleo-heat-templates. Longer term (or even in parallel for some
> time), the generated playbooks could stop being generated (and just
> exist in git), and we could consider moving away from Heat more
> permanently
>
> I recognize that saying "moving away from Heat" may be quite
> controversial. While it's not 100% the same discussion as what we are
> doing with Ansible, I think it is a big part of the discussion and if
> we want to continue with Heat as the primary orchestration tool in
> TripleO.
>
> I've been hearing a lot of feedback from various operators about how
> difficult the baremetal deployment is with Heat. While feedback about
> Ironic is generally positive, a lot of the negative feedback is around
> the Heat->Nova->Ironic interaction. And, if we also move more towards
> Ansible for the service deployment, I wonder if there is still a long
> term place for Heat at all.
>
> Personally, I'm pretty apprehensive about the approach taken in (3). I
> feel that it is a lot of complexity that could be done simpler if we
> took a step back and thought more about a longer term approach. I
> recognize that it's mostly an experiment/POC at this stage, and I'm
> not trying to directly knock down the approach. It's just that when I
> start to see more patches (Kubernetes installation) using the same
> approach, I figure it's worth discussing more broadly vs trying to
> have a discussion by -1'ing patch reviews, etc.
>
> I'm interested in all feedback of course. And I plan to take a shot at
> working on the prototype I 

Re: [openstack-dev] [Security] Today's IRC meeting.

[Luke Hinds]

On Thu, May 4, 2017 at 12:37 PM, Rob C  wrote:

> Hi All,
>
> I won't be able to make today's meeting as I'm travelling.
>
> I've not found a chair to cover the meeting, please decide if you have a
> quorum and either proceed or go back to "real life" as you see fit.
>
> Cheers
> -Rob
>

I am out this week too, so might find it a challenge to get on IRC, but
will do my best.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] spec-lite process for tripleo

[Luke Hinds]

On Wed, Mar 29, 2017 at 10:42 PM, Steven Hardy  wrote:

> On Tue, Mar 28, 2017 at 12:09:43PM -0400, Emilien Macchi wrote:
> > Bringing an old topic on the table.
> >
> > We might have noticed:
> >
> > 1. Some tripleo-specs take huge amount of time before getting merged
> > (or even reviewed). We have been asking folks to review them every
> > week but unfortunately they don't get much attraction (# of core
> > reviewers versus # of folks actually reviewing specs).
> > 2. Some folks spend a lot of time writing TripleO specs and wait for
> > feedback before starting some implementation (like proof of concept).
> >
> > Because TripleO like innovation and also moving fast, I think it's
> > time to bring the tripleo-specs topic on the table:
> >
> > 1. If you have an idea, don't feel obliged to write a specs. Create a
> > blueprint on launchpad, announce it on the ML and start writing code
> > (can be real implementation or just a simple PoC). Feedback will be
> > given in the classic code review.
>
> +1 I for one have been burnt more than once spending significant time
> on a spec only to find our collective understanding changes after actual
> code exists.
>
> For things related to interfaces a spec can be helpful, but I think it's
> often faster to raise a blueprint with relatively few details and work on a
> prototype that clarifies the direction, particularly if such code patches
> can be generated fairly quickly.
>
> > 2. If you still want to write a spec, please make it readable and
> > communicate about it. If your spec is 900 lines long and not announced
> > anywhere, there is an high change that it will never been reviewed.
>
> I agree - I think a common mistake is to get bogged down in implementation
> detail when writing (and reviewing) a spec, so I definitely favor a
> clearly expressed summary of the problem, an overview of the proposed
> direction (including any major interface changes), and clarification of any
> user/dev visible impact.  None of this requires much focus at all on the
> details of the implementation IMO.
>
> Thanks for raising this Emilien, hopefully this will help us move a little
> faster in future!
>
> Steve


Having wrote a few specs this cycle, its good to read both your views, as I
was becoming concerned about spending a fair amount of time on answering
comments, correcting grammar nits, clarifying misunderstands etc, instead
of getting code I already had staged up for review.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Arrivederci

[Luke Hinds]

On Wed, Mar 22, 2017 at 12:06 PM, Ian Cordasco 
wrote:

> Hi everyone,
>
> Friday 24 March 2017 will be my last day working on OpenStack. I'll remove
> myself from teams (glance, craton, security, hacking) on Friday and
> unsubscribe
> from the OpenStack mailing lists.
>
> I want to thank all of you for the last ~3 years. I've learned quite a bit
> from all of you. It's been a unique privilege to call the people in this
> community my colleagues. Treat each other well. Don't let minor technical
> arguments cause rifts in the community. Lift each other up.
>
> As for me, I'm moving onto something completely different. You all are
> welcome
> to keep in touch via email, IRC, or some other method. At the very
> least, I'll see y'all
> around PyCon, the larger F/OSS world, etc.
>
> --
> Ian Cordasco
> IRC/Git{Hub,Lab}/Twitter: sigmavirus24
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

Hi Ian,

A loss for OpenStack, but also a big gain for the next community you
participate in! Wish you best of luck, thanks for all the effort put in.
Its been great working and learning alongside you in the security project.

Cheers,

Luke
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OSSN-0078] copy_from in Image Service API v1 allows network port scan

[Luke Hinds]

copy_from in Image Service API v1 allows network port scan
---

### Summary ###
The `copy_from` feature in Image Service API v1 supplied by Glance can
allow an attacker to perform masked network port scans.

### Affected Services / Software ###
Version 1 of the Glance Image Service (deprecated in Newton).

### Discussion ###
In Version 1 of the Glance Image Service API it is possible to create
images with a URL such as `http://localhost:22`. This could then allow
an attacker to enumerate internal network details while appearing
masked, since the scan would appear to originate from the Glance image
service.

### Recommended Actions ###
Version 1 of the Glance Image Service API was deprecated in the Newton
cycle, so operators should upgrade to a later version that will allow
use of Version 2.

Existing deployments can limit policy on `copy_from` by restricting use
to `admin` within `policy.json` as follows:

"copy_from": "role:admin"

### Contacts / References ###
Author: Luke Hinds, Red Hat
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0078
Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1606495
OpenStack Security Project : https://launchpad.net/~openstack-ossg




signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo][diskimage-builder] Status of diskimage-builder

[Luke Hinds]

On Sat, Mar 4, 2017 at 6:13 PM, Andre Florath  wrote:

> Hello!
>
> Thanks Greg for sharing your thoughts.  The idea of splitting off DIB
> from OpenStack is new for me, therefore I collect some pros and
> cons:
>
> Stay in OpenStack:
>
> + Use available OpenStack infrastructure and methods
> + OpenStack should include a possibility to create images for ironic,
>   VMs and docker. (Yes - there are others, but DIB is the best! :-) )
> + Customers use DIB because it's part of OpenStack and for OpenStack
>   (see e.g. [1])
> + Popularity of OpenStack attracts more developers than a separate
>   project (IMHO running DIB as a separate project even lowers the low
>   number of contributors).
> + 'Short Distances' if there are special needs for OpenStack.
> + Some OpenStack projects use DIB - and also use internal 'knowledge'
>   (like build-, run- or test-dependencies) - it would be not that easy
>   to completely separate this in short term.
>
> As a separate project:
>
> - Possibly less organizational overhead.
> - Independent releases possible.
> - Develop / include / concentrate also for / on other non-OpenStack
>   based virtualization platforms (EC2, Google Cloud, ...)
> - Extend the use cases to something like 'DIB can install a wide range
>   of Linux distributions on everything you want'.
>   Example: DIB Element to install Raspberry Pi [2] (which is currently
>   not the core use-case but shows how flexible DIB is).
>
> In my opinion the '+' arguments are more important, therefore DIB
> should stay within OpenStack as a sub-project.  I don't really care
> about the master: TripleO, Infra, glance, ...
>
>
> I want to touch an important point: Greg you are right that there are
> only a very few developers contributing for DIB.  One reason
> is IMHO, that it is not very attractive to work on DIB; some examples:
>
> o The documentation how to set up a DIB development environment [3]
>   is out of date.
> o Testing DIB is nightmare: a developer has no chance to test
>   as it is done in the CI (which is currently setup by other OpenStack
>   projects?). Round-trip times of ~2h - and then it often fails,
>   because of some mirror problem...
> o It takes sometimes very long until a patch is reviewed and merged
>   (e.g. still open since 1y1d [6]; basic refactoring [7] was filed
>   about 9 month ago and still not in the master).
> o There are currently about 100 elements in DIB. Some of them are
>   highly hardware dependent; some are known not to work; a lot of them
>   need refactoring.
>
> It is important to work on these topics to make DIB more attractive and
> possible have more contributors.  Discussions about automated
> development environment setup [4] or better developer tests [5] started
> but need more attention and discussions (and maybe a different setting
> than a patch / review).
> In addition we should concentrate on the core functionalities: block
> device setup, minimal system installation, bootloader, kernel and
> ramdisk creation and a stable extensible element interface; drop
> non-core elements or move them to the projects where they are used.
>
> Kind regards
>
> Andre
>
>
> [1] https://imagefactory.otc.t-systems.com/
> [2] https://github.com/florath/dib-element-raspberrypi3
> [3] https://docs.openstack.org/developer/diskimage-builder/
> developer/index.html
> [4] https://review.openstack.org/#/c/419655/
> [5] https://review.openstack.org/#/c/414347/
> [6] https://review.openstack.org/#/c/287784/
> [7] https://review.openstack.org/#/c/319591/
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


Merging into infra sounds pragmatic, especially if a lack of testing / CI
presence is an area that needs improvement. Yolanda from infra has been
very active in DIB as of recent (in terms of CI).

Unless there are strong objections, infra seems a good choice of home to
me.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OSSN 0065] Users of Glance may be able to replace active image data

[Luke Hinds]

Users of Glance may be able to replace active image data
---

### Summary ###
When Glance has been configured with the "show_multiple_locations"
option enabled with default policy for set and delete locations, it is
possible for a non-admin user having write access to the image metadata
to replace active image data.

### Affected Services / Software ###
Glance, Havana, Icehouse, Juno, Kilo, Liberty, Mitaka, Newton, Ocata

### Discussion ###

As a convenience to operators, Glance has a multiple location feature,
disabled by default, that allows a single image to be stored in multiple
places. This is intended to offer an extra degree of resilience by
improving the availability of Glance images. This feature involves a
user setting a new entry in an image's 'locations' list, not visible to
users by default, via the Glance API. However, this process does not
involve taking a checksum of the data in a newly created image location,
and hence does not involve comparing the 'checksum' field of the image
(which is always visible to users) with the checksum of any added
locations. This design opens the possibility that a malicious user
could create an image in Glance, set an additional location on that
image pointing to an altered image, then delete the original location,
so that consumers of the original image would unwittingly be using the
malicious image. Note, however, that this attack vector cannot change
the original image's checksum, and it is limited to images that are
owned by the attacker.

### Recommended Actions ###

The reach of this attack depends upon how broadly usage of the original
image is spread among consumers who do not checksum images before they
are used. Glance enables three ways for an image to be made
available to other users:

1 Making an image "public". This makes an image available to all users
  of a cloud. The ability to do this is governed by the
  'publicize_image' policy, which is restricted to the admin role by
  default since the Juno release.

2 Making an image "community". *This feature is only available since
  Ocata.* This makes an image available to all users of a cloud, but
  unlike a "public" image, it does not appear in the default image-list
  response of any user (other than the owner). It is governed by the
  'communitize_image' policy, which is unrestricted by default.

3 Making an image "shared". Glance allows project-to-project image
  sharing, in which a user in project A shares an image with project B
  by making project B a *member* of the image. The ability to do this
  is governed by the 'add_member' policy, which is unrestricted by
  default.

  * Project-to-project sharing is the default, based on the
'owner_is_tenant' configuration setting in Glance. In a cloud
configured so that 'owner_is_tenant' is false, image sharing is
user-to-user. This is a cloud-wide configuration, users may not
determine whether sharing is project-to-project or owner-to-owner.

Note that what has been discussed so far is independent of the specific
vulnerability discussed in this notice. We encourage cloud operators to
review their current settings for the policies mentioned above. In
particular, we recommend that the 'publicize_image' policy be restricted
to admins (as it has been by default since the Juno release) so that
users can rely on the trustworthiness of a "public" image.

With respect to the image location vulnerability described above, we
recommend that operators review the settings of the following
configuration options and policies:

* The configuration option 'show_multiple_locations'. If this is set to
  False, this attack vector is not available.

* The policy 'set_image_location'. When 'show_multiple_locations' is
  set to True, we recommend that this policy be restricted to
  administrators, and if necessary, to trusted users. It is currently
  unrestricted by default.

* The policies 'get_image_location' and 'delete_image_location'. These
  policies are unrestricted by default (but note that if
  'show_multiple_locations' is False, they do not come into play).

Additionally, image consumers should be encouraged to checksum images
they consume and compare the result to the 'checksum' field in the
response from the Images API.

Finally, in addition to reviewing the specific location policy targets
mentioned above, we encourage operators to review the 'default' target
in their Glance policy.json file. This target is used when the software
references a policy target that is not specifically defined in the
policy.json file, as may happen when new targets are introduced in the
software but the policy file being used is from a prior release. Since
Newton, Glance has shipped with "default":"role:admin", but prior to
that, Glance shipped with "default":"", which would make any target not
specifically mentioned in the file unrestricted.

### Contacts / References ###
Author: Robert Clark, IBM
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0065

Re: [openstack-dev] [security] FIPS compliance

[Luke Hinds]

On Tue, Jan 17, 2017 at 10:11 AM, Yolanda Robla Mota 
wrote:

> Hi, in previous threads, there have been discussions about enabling FIPS,
> and the problems we are hitting with md5 inside OpenStack:
> http://lists.openstack.org/pipermail/openstack-dev/2016-
> November/107035.html
>
> It is important from a security perspective to enable FIPS, however
> OpenStack cannot boot with that, because of the existence of md5 calls in
> several projects. These calls are not used for security, just for hash
> generation, but even with that, FIPS is blocking them.
>
> There is a patch proposed for newest versions of python, to avoid that
> problem. The idea is that when a hash method is called, users could specify
> if these are used for security or not. If the useforsecurity flag is set to
> False, FIPS won't block the call. See: http://bugs.python.org/issue9216
>
> This won't land until next versions of Python, however the patch is
> already on place for current RHEL and CentOS versions that are used in
> OpenStack deploys. Using that patch as a base, I have a proposal to allow
> FIPS enabling, at least in the distros that support it.
>
> The idea is to create a wrapper around md5, something like:
> md5_wrapper('string_to_hash', useforsecurity=False)
>
> This method will check the signature of hashlib.md5, and see if that's
> offering the useforsecurity parameter. If that's offered, it will pass the
> given parameter from the wrapper. If not, we will just call
> md5('string_to_hash') .
>
> This gives us the possibility to whitelist all the md5 calls, and enabling
> FIPS kernel booting without problems. It will start to work for distros
> supporting it, and it will be ready to use generally when the patch lands
> in python upstream and another distros adopt it. At some point, when all
> projects are using newest python versions, this wrapper could disappear and
> use md5 useforsecurity parameter natively.
>
> The steps needed to achieve it are:
> - create a wrapper, place it on some existing project or create a new fips
> one
> - search and replace all md5 calls used in OpenStack core projects , to
> use that new wrapper. Note that all the md5 calls will be whitelisted by
> default. We have not noted any md5 call that is used for security, but if
> that exists, it shall be better to use another algorithms, in terms of
> security.
>
> What do people think about it?
>
>
Sounds pragmatic to me. The other option explored was for projects to
migrate to sha2, but that transpired to be a huge challenge for some
projects that had complex functionality built up around md5.

I see this as a non breaking way to allow FIPS compliant kernels, without
throwing the `baby out with the bath water`, as we use md5.




> Best
>
> --
> Yolanda Robla Mota
> NFV Partner Engineer
> yrobl...@redhat.com
> +34 605641639 <+34%20605%2064%2016%2039>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OSSN-0074] Nova metadata service should not be used for sensitive information

[Luke Hinds]

OpenStack Security Note: 0074

Nova metadata service should not be used for sensitive information

---

### Summary ###
A recent security report has highlighted how users may be using the
metadata service to store security sensitive information.

The Nova metadata service should not be considered a secure repository
of confidential information required by compute instances.

### Affected Services / Software ###
Nova, All Versions

### Discussion ###
A recent vulnerability report for Nova stated that the metadata service
will obey the `X-Forwarded-For` HTTP header. This header is often
supplied by proxies so that the end service can identify which IP the
request originated from.

The Nova metadata service typically uses the source IP address of the
incoming request to respond with the appropriate data for the compute
instance making the request. This is a sort of weak authentication,
designed to ensure that metadata for one tenant isn't accidentally
provided to another.

If the request contains a `X-Forwarded-For` HTTP header then the
metadata service will use that for the source authentication rather than
the actual TCP/IP source.

An attacker with access to a compute instance in the cloud could send a
request to the metadata service and include the `X-Forwarded-For` header
in order to effectively spoof their source and cause the metadata
service to provide information that should not have been provided to
that instance.

Consider the following:
Alice creates a compute instance. She places the root password for that
instance in the metadata service. The instance is assigned a 10.1.2.2
IP address. Alice believes that the root password for her instance is
safe within the metadata service.

Alice retrieves metadata by running a command similar to:
`curl http://169.254.169.254/latest/meta-data
`
this will retrieve any metadata stored for Alice's compute instance,
which has an IP address of 10.1.2.2

Bob has a compute instance with IP address 10.1.9.9 however Bob wants
access to the metadata for Alice's compute instance. If Bob runs a
similar command to Alice, but includes a customer header as below, he
will get access to all of Alice's metadata, including the root password
she chose to store there:
`curl -H "X-Forwarded-For:
10.1.2.2" http://169.254.169.254/latest/meta-data
`

The Nova metadata service is a useful utility within OpenStack but
clearly not intended as a strongly authenticated system for storing
sensitive data such as private keys or passwords.

### Recommended Actions ###
The metadata service should not be used to store sensitive information.

The IP forwarding issue is not a defect of itself, it exists to allow
the metadata service to provide IP addresses for instances that are
behind a proxy as may be the case in more complex deployments.

Cloud users who have a requirement to store sensitive information that
compute instances require for operation should instead look to the
Config drive to provide this service. It's operation is much more
tightly bound to individual compute instances.

Where use of config drive is not an option, operators should consider
other mitigations such as placing a proxy in front of the metadata service
which can filter out these sorts of malicious activities.

### Contacts / References ###
Author: Robert Clark, IBM
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0074
Original LaunchPad Bug : https://bugs.launchpad.net/nova/+bug/1563954

Mailing List : [Security] tag on openstack-dev@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg

Config Drive
: http://docs.openstack.org/user-guide/cli-config-drive.html




0x3C202614.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Fwd: Re: [requirements][kolla][security] pycrypto vs cryptography

[Luke Hinds]

On Fri, Nov 18, 2016 at 3:04 PM, Jeremy Stanley <fu...@yuggoth.org> wrote:

> On 2016-11-18 14:38:22 + (+0000), Luke Hinds wrote:
> [...]
> > I proposed raising bugs on launchpad for each instance discovered, so
> that
> > if anything, we at least have an idea of the extent of work needed to
> reach
> > the needed level of compliance for FIPS 140-2.
> [...]
>
> It's come up plenty over the years and I think a lot of the easier
> cases have already been fixed. Places where you'll have more trouble
> are the ones like https://launchpad.net/bugs/1348339 (inherited from
> Swift's use of MD5 for etags).
> --
>

Thx

So its been known about for two years now, and the consensus then was it
needed changing too.

Sounds to me like this topic won't just go away and we need to address it
sooner or later.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [security] FIPS Compliance (Was: [requirements][kolla][security] pycrypto vs cryptography)

[Luke Hinds]

On Fri, Nov 18, 2016 at 4:14 PM, Dean Troyer <dtro...@gmail.com> wrote:

> > -Original Message-
> > From: Luke Hinds <lhi...@redhat.com>
> [...]
> >> for non security related functions, but when it comes to government
> >> compliance and running OpenStack on public clouds (and even private for
> the
> >> Telcos / NFV), not meeting FIPS will in some cases block production
> getting
> >> a green light, or at least make it a big challenge to push through.
>
> Are there any know cases of this happening?  If so, can those be
> publicly documented to quantify how much this issue is hurting
> deployments?
>
>
>
I don't have any that I could share publicly at the moment, but I will dig
around.

I expect the FIPS 140-2 requirement will be more frequently requested for
the telecommunications based NFV deployments, which as we all see, are
undergoing a groundswell in OpenStack, with many networks expected to go
into production over the next five years. Security compliance tends to be
more strictly enforced in Telco as the networks are seen as a critical
infrastructure.


> On Fri, Nov 18, 2016 at 9:57 AM, Ian Cordasco <sigmaviru...@gmail.com>
> wrote:
> > Also, instead of creating bugs, I would suggest instead that we try to
> make this into a community goal. We would work with the TC and for P or Q,
> make it a goal to start migrating off of MD5 and have a goal for a cycle or
> two later to completely remove reliance on MD5.
> >
> > Doing this piecemeal via bugs will not be efficient and we'll need
> community buy-in.
>
>
If that is the more pragmatic approach and there is TC buy in, then let's
go ahead. Whatever means is most effective in getting it done.

At some point, I think we will need a tag to return a set of bugs to gauge
progress, but I agree the consensus needs to be in place, more then a bug
list.


We would also need to get a reasonable scoping of the issue (which
> projects, how many instances, etc) to help decide if this is an
> achievable goal (in the sense of the 'community goals').
>
> As you noted, this will not be easy for Swift or Glance (others?), but
> if the impact to deployers can be quantified it makes it easier to
> spend energy here.
>
>
I can collate figures on how many instances there are, on which projects
etc.

The part where I am green is how this would be taken forward to gain
community consensus or TC approval.

dt
>
> --
>
> Dean Troyer
> dtro...@gmail.com
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Fwd: Re: [requirements][kolla][security] pycrypto vs cryptography

[Luke Hinds]

w older versions of OpenSSL, and to work with
> > that you'd have to stick to an older version of Cryptography.
> >
> > Can I ask why FIPS compliance is a requirement for Kolla? This seems
> > like an odd request for a deployment project.
> >
> > > On Sun, Nov 6, 2016 at 4:44 PM, Jeremy Stanley wrote:
> > >
> > > > On 2016-11-06 14:59:03 + (+), Jeremy Stanley wrote:
> > > > > On 2016-11-06 08:05:51 + (+), Steven Dake (stdake) wrote:
> > > > [...]
> > > > > > An orthogonal question I have received from one of our community
> > > > > > members (Pavo on irc) is whether pycrypto (or if we move to
> > > > > > cryptography) provide FIPS-140-2 compliance.
> > > > >
> > > > > My understanding is that if you need, for example, a FIPS-compliant
> > > > > AES implementation under the hood, then this is dependent more on
> > > > > what backend libraries you're using... e.g.,
> > > > > https://www.openssl.org/docs/fips.html
> > > > > https://www.openssl.org/docs/fipsvalidation.html
> >
> > --
> > Ian Cordasco
> >
> >
> >
>
> --
> Ian Cordasco
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Luke Hinds | NFV Partner Engineering | Office of Technology | Red Hat
e: lhi...@redhat.com | irc: lhinds @freenode | m: +44 77 45 63 98 84 | t: +44
12 52 36 2483
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OSSN-0066] (Errata) MongoDB guest instance allows any user to connect

[Luke Hinds]

MongoDB guest instance allows any user to connect
---

### Summary ###
When creating a new MongoDB single instance or cluster the default
setting in MongoDB `security.authorization` was set as disabled. This
resulted in no need to provide user credentials to connect to the mongo
instance and perform read / write operations from any network that is
attached on instance create.

### Affected Services / Software ###
Trove, Liberty

### Discussion ###
MongoDB contains a security config set within `mongo.conf` as follows:

security:
authorization: "enabled"

When creating a new MongoDB instance, or cluster within Trove the
`security` value was not populated resulting in MongoDB adopting the
default value of `disabled`. With security authorization disabled there
would be no enforcement of user authentification, allowing users to
connect and perform read/write data operations from any network that is
attached on instance create.

A fix was implemented within Mitaka and back ported to Liberty that
addresses the problem by enabling authorization by default on single
instances. This can be toggled via configuration groups.

Cluster security is determined by the Trove config variable
`mongodb.cluster_secure`. This cannot be toggled once the cluster is
created.

### Recommended Actions ###
Single instances now use role based access control (RBAC) by default. To
disable RBAC, the Trove user can attach a security group with
`security.authorization` set to `disabled`. It can be re-enabled by
detaching the security group or changing the value to `enabled`.

The Trove config variable `mongodb.cluster_secure`
(boolean type, in `trove.conf`) determines the RBAC state of MongoDB
clusters that are created. Setting this to true enables RBAC while false
disables it. This applies to all MongoDB clusters, and requires a
restart of the trove-api service to change, and cannot be toggled on
running clusters.

Existing mongoDB instances can be secured by using the following changes
to `mongo.conf`

   security:
   authorization: "enabled

### Errata ###
This OSSN previously incorrectly stated that the fix was back ported to
Liberty release. This is not the case and the fix was applied only to
Mitaka.

### Contacts / References ###
Author: Luke Hinds, Red Hat
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0066
Original LaunchPad Bug : https://bugs.launchpad.net/trove/+bug/1507841
Mailing List : [Security] tag on openstack-dev@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg



0x3C202614.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon] USE_SSL

[Luke Hinds]

On Wed, Nov 9, 2016 at 1:56 PM, Rob Cresswell <robert.cressw...@outlook.com>
wrote:

> Was that ever in local_settings? I couldnt find any mention of it.
>

Yes, seems to have stopped being used around Kilo:

http://docs.openstack.org/kilo/config-reference/content/configure-dashboard.html


> The Django docs are probably your best bet for information: https://docs.
> djangoproject.com/en/1.10/topics/security/#ssl-https
>
> Rob
>
> On 9 November 2016 at 13:23, Luke Hinds <lhi...@redhat.com> wrote:
>
>> Hi,
>>
>> I have noted that USE_SSL is no longer in local_settings.py
>>
>> I have not had any luck in having google find the background of why this
>> was removed for first django (if it has?)  and horizon.
>>
>> From what I can see, it seems related to django views.
>>
>> Does anyone understand the context of this being removed. I don't require
>> the use of the parameter myself, I more want to update the security guide
>> which recommends toggling it to true when using SSL.
>>
>> Thanks,
>>
>> Luke
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Luke Hinds | NFV Partner Engineering | Office of Technology | Red Hat
e: lhi...@redhat.com | irc: lhinds @freenode | m: +44 77 45 63 98 84 | t: +44
12 52 36 2483
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [horizon] USE_SSL

[Luke Hinds]

Hi,

I have noted that USE_SSL is no longer in local_settings.py

I have not had any luck in having google find the background of why this
was removed for first django (if it has?)  and horizon.

>From what I can see, it seems related to django views.

Does anyone understand the context of this being removed. I don't require
the use of the parameter myself, I more want to update the security guide
which recommends toggling it to true when using SSL.

Thanks,

Luke
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OSSN-0076] Glance Image service v1 and v2 api image-create vulnerability

[Luke Hinds]

Glance Image service v1 and v2 api image-create vulnerability
---

### Summary ###
No limits are enforced within the Glance image service for both v1 and
v2 `/images` API POST method for authenticated users, resulting in
possible denial of service attacks through database table saturation.

### Affected Services / Software ###
All versions of Glance image service.

### Discussion ###
Within the Glance image service, calls to the POST method within v1 or
v2/images creates an image (record) in `queued` status. There is no
limit enforced within the Glance API on the number of images a single
tenant may create, just on the total amount of storage a single user may
consume.

Therefore a user could either maliciously or unintentionally fill
multiple database tables (images, image_properties, image_tags,
image_members) with useless image records, thereby causing a denial of
service by lengthening transaction response times in the Glance database.

### Recommended Actions ###
For all versions of Glance that expose either the v1 and v2/images API,
operators are recommended to deploy external rate-limiting proxies or
web application firewalls, to provide a front layer of protection to
glance. The Glance database should be monitored for abnormal growth.
Although rate-limiting does not eliminate this attack vector, it will
slow it to the point where you can react prior to a denial of service
occurring.

The following solutions may be considered, however it is key that the
operator carefully plans and considers the individual performance needs
of users and services within their OpenStack cloud, when configuring any
rate limiting functionality.

 Repose 
Repose provides a rate limiting filter, that can utilise limits by IP,
Role (OpenStack Identity v3 filter) or header.

https://repose.atlassian.net/wiki/display/REPOSE/Rate+Limiting+Filter

 NGINX 
NGINX provides the limit_req_module, which can be used to provide a
global rate
limit. By means of a `map`, it can be limited to just the POST method.

Further details can be found on the nginx site:
http://nginx.org/en/docs/http/ngx_http_limit_req_module.html

 HAProxy 
HAProxy can provide inherent rate-limiting using stick-tables with a General
Purpose Counter (gpc)

Further details can be found on the haproxy website:

http://blog.haproxy.com/2012/02/27/use-a-load-balancer-as-a-first-row-of-defense-against-ddos

 Apache 
A number of solutions can be explored here as follows.

# mod_ratelimit #
http://httpd.apache.org/docs/2.4/mod/mod_ratelimit.html

# mod_qos #
http://opensource.adnovum.ch/mod_qos/dos.html

# mod_evasive #
https://www.digitalocean.com/community/tutorials/how-to-protect-against-dos-and-ddos-with-mod_evasive-for-apache-on-centos-7

# mod_security #
https://www.modsecurity.org/

 Limit `add_image` to admin role 

Another possible mitigation is to restrict image creation to the admin
role, however this should only be done for those cases in which there
are Glance nodes dedicated to end-user access only. Restriction to admin
only on Glance nodes that serve OpenStack services will for example,
remove the ability to create snapshots from the Compute API or to create
bootable volumes from Cinder.

To restrict image creation to the role admin only, amend
`/etc/glance/policy.json` accordingly.

"add_image": "role:admin",

### Contacts / References ###
Author: Luke Hinds, Red Hat
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0076
Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1545092
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg




0x3C202614.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Fwd: [security] [salt] Removal of Security and OpenStackSalt project teams from the Big Tent

[Luke Hinds]

Hi,

So I am recent elected core to the security group, so while obviously
pro OSSG-Sec, I also have a fairly fresh perspective of the group.

I would first off all not agree on disengagement with the community.
Well at least not from my perspective.

Since I joined I have found the group welcoming to new members, with
well run with meetings never starting late or failing to achieve
actions from before. While I may be a new core, I am not new to open
source, so there is no way I would have joined if I felt the group was
waning in enthusiasm, disconnected or not moving forward.

The team are actively working on several projects which have found
vulnerabilities in openstack, namely Bandit and syntribos, threat
analysis and I was inspired to start on my own new proposal project
from seeing the enthusiasm in the group. There is also lots of
engagement between other cores and the security group in OSSN's
(security notes). I recently took over covering these, and have
enjoyed working immensely with cores in keystone, trove, nova,
neutron, and horizon etc. I did not see any disconnect there myself.

On the matter of elections, I understand people are upset that the PTL
nomination period was missed, but I understand there was a genuine
reason for this which I will leave for the PTL to cover. For me Robert
did a really great job of welcoming and mentoring me into the security
group, so I personally have nothing but respect there.

So if the decision is made to demote(?) the group, I guess so be it,
but it will be a big downer and disappointment for me as someone that
is proud and enthusiastic to be a new OSSG-core sec member.

Regards,

Luke



From: Thierry Carrez <thie...@openstack.org>
Date: Wed, Sep 21, 2016 at 12:23 PM
Subject: [openstack-dev] [security] [salt] Removal of Security and
OpenStackSalt project teams from the Big Tent
To: OpenStack Development Mailing List <openstack-dev@lists.openstack.org>


Hi everyone,

As announced previously[1][2], there were no PTL candidates within the
election deadline for a number of official OpenStack project teams:
Astara, UX, OpenStackSalt and Security.

In the Astara case, the current team working on it would like to abandon
the project (and let it be available for any new team who wishes to take
it away). A change should be proposed really soon now to go in that
direction.

In the UX case, the current PTL (Piet Kruithof) very quickly reacted,
explained his error and asked to be considered for the position for
Ocata. The TC will officialize his nomination at the next meeting,
together with the newly elected PTLs.

That leaves us with OpenStackSalt and Security, where nobody reacted to
the announcement that we are missing PTL candidates. That points to a
real disconnect between those teams and the rest of the community. Even
if you didn't have the election schedule in mind, it was pretty hard to
miss all the PTL nominations in the email last week.

The majority of TC members present at the meeting yesterday suggested
that those project teams should be removed from the Big Tent, with their
design summit space allocation slightly reduced to match that (and make
room for other not-yet-official teams).

In the case of OpenStackSalt, it's a relatively new addition, and if
they get their act together they could probably be re-proposed in the
future. In the case of Security, it points to a more significant
disconnect (since it's not the first time the PTL misses the nomination
call). We definitely still need to care about Security (and we also need
a home for the Vulnerability Management team), but I think the "Security
team" acts more like a workgroup than as an official project team, as
evidenced by the fact that nobody in that team reacted to the lack of
PTL nomination, or the announcement that the team missed the bus.

The suggested way forward there would be to remove the "Security project
team", have the Vulnerability Management Team file to be its own
official project team (in the same vein as the stable maintenance team),
and have Security be just a workgroup rather than a project team.

Thoughts, comments ?

[1]
http://lists.openstack.org/pipermail/openstack-dev/2016-September/103904.html
[2]
http://lists.openstack.org/pipermail/openstack-dev/2016-September/103939.html

--
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Luke Hinds | NFV Partner Engineering | Office of Technology | Red Hat
e: lhi...@redhat.com | irc: lhinds @freenode | m: +44 77 45 63 98 84 |
t: +44 12 52 36 2483

__
OpenStack Development Mailing List (not for usage questions)

[openstack-dev] [OSSN-0066] MongoDB guest instance allows any user to connect

[Luke Hinds]

MongoDB guest instance allows any user to connect
---

### Summary ###
When creating a new MongoDB single instance or cluster the default
setting in MongoDB `security.authorization` was set as disabled. This
resulted in no need to provide user credentials to connect to the mongo
instance and perform read / write operations from any network that is
attached on instance create.

### Affected Services / Software ###
Trove, Liberty

### Discussion ###
MongoDB contains a security config set within `mongo.conf` as follows:

security:
authorization: "enabled"

When creating a new MongoDB instance, or cluster within Trove the
`security` value was not populated resulting in MongoDB adopting the
default value of `disabled`. With security authorization disabled there
would be no enforcement of user authentification, allowing users to
connect and perform read/write data operations from any network that is
attached on instance create.

A fix was implemented within Mitaka and back ported to Liberty that
addresses the problem by enabling authorization by default on single
instances. This can be toggled via configuration groups.

Cluster security is determined by the Trove config variable
`mongodb.cluster_secure`. This cannot be toggled once the cluster is
created.

### Recommended Actions ###
Single instances now use role based access control (RBAC) by default. To
disable RBAC, the Trove user can attach a security group with
`security.authorization` set to `disabled`. It can be re-enabled by
detaching the security group or changing the value to `enabled`.

The Trove config variable `mongodb.cluster_secure`
(boolean type, in `trove.conf`) determines the RBAC state of MongoDB
clusters that are created. Setting this to true enables RBAC while false
disables it. This applies to all MongoDB clusters, and requires a
restart of the trove-api service to change, and cannot be toggled on
running clusters.

### Contacts / References ###
Author: Luke Hinds, Red Hat
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0066
Original LaunchPad Bug : https://bugs.launchpad.net/trove/+bug/1507841
Mailing List : [Security] tag on openstack-dev@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg


0x3C202614.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OSSN-0075] Deleted Glance image IDs may be reassigned

[Luke Hinds]

Deleted Glance image IDs may be reassigned
---

### Summary ###
It is possible for image IDs from deleted images to be reassigned to
other images.  This creates the possibility that:

 - Alice creates a VM that boots from image ID X which has been shared
 with her by a trusted party, Bob.
 - Bob (image X's owner) deletes the image.  As per design, Alice
 receives no notification this happened.
 - Mallory creates a new image and specifies that the ID should be X.
 - Mallory shares image X with Alice.  Again, per design, Alice is not
 notified of this change.
 - Alice boots her VM without realizing that the image has changed.

It's worth noting that in this scenario Mallory needs to know Alice's
project ID to share the new image with Alice.  This isn't enough to
mitigate the issue as project IDs weren't designed to be confidential.

Also, if the environment allows non-administrators to publish images,
Mallory doesn't have to explicitly share with Alice or know her project
ID to perform this attack.

### Affected Services / Software ###
Glance, Liberty, Mitaka, Newton

### Discussion ###
Glance's image table doesn't maintain a list of previously used image
IDs.  Previously assigned image IDs will be listed in the image table
as deleted, but these records may be removed (for performance reasons)
with the `glance-manage db purge` utility or manually by an
administrator.

If these records are removed a malicious user may intentionally upload
a new image using the same ID (Glance allows an image creator to
optionally specify the image ID).  This would cause any victim
instances referencing the ID to use an attacker supplied image.

### Recommended Actions ###
The combination of purged Glance database entries and non-admin image
upload is dangerous.  In environments where normal users are permitted
to upload images, the `images` table should not be purged.  It is
however safe to delete rows from `image_properties`, `image_tags`,
`image_members`, and `image_locations` tables.

### Contacts / References ###
Author: Travis McPeak, IBM
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0075
Original LaunchPad Bug : https://bugs.launchpad.net/glance/+bug/1593799/
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg




0x3C202614.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OSSN-0073] Horizon dashboard leaks internal information through cookies

[Luke Hinds]

Horizon dashboard leaks internal information through cookies
---

### Summary ###
When horizon is configured, its URL contains the IP address of
the internal URL of keystone, as the default value for the identity
service is "internalURL".[1]

The cookie "login_region" will be set to the value configured as
OPENSTACK_KEYSTONE_URL, given in the local_settings.py file.

Usually, the OPENSTACK_KEYSTONE_URL is the publicURL, and hence the
cookie URL will also be the public one. If set to internal URL (by
default), then the login cookie URL will be the internal URL or IP. So,
by putting the OPENSTACK_KEYSTONE_URL in the cookie that is sent to
the public network, horizon leaks the values of the internal network IP
address.

### Affected Services and Software ###
Horizon

### Discussion ###
This is not a bug in horizon, but a possible misconfiguration issue.

Exposing the internal URL is not a bug, since one can view the internal
URL as it's a freely accessible endpoint to authorized users, or it's
hidden behind a firewall. Also, the data for internal URLs are freely
available in the catalog and the catalog is not considered private
information.

### Contacts / References ###
Author: Khanak Nangia, Intel
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0073
Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1585831
Related bug : https://bugs.launchpad.net/horizon/+bug/1597864
OpenStack Security ML : openstack-dev@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
[1]: http://docs.openstack.org/developer/horizon/topics/settings.html


0x3C202614.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OSSN-0069] Host machine exposed to tenant networks via IPv6

[Luke Hinds]

Host machine exposed to tenant networks via IPv6
---

### Summary ###

New interfaces created by Neutron in the default namespace, were done so
without disabling IPv6 link-local addresses. This resulted in instances
gaining the ability to directly access the host OS, therefore breaking
guest isolation.

In Linux, link-local IPv6 addresses are assigned to all active
interfaces, unlike IPv4 addresses where an administrator must configure
each interface explicitly. This leads to a time window between when the
interface is enabled and when it is attached to bridge device. Within
this time window the host could be accessed from a tenant network.

IPv6 is now disabled automatically by both Neutron and Nova, prior to
bringing any links up, however operators should still be aware of the
security risks associated with re-enabling IPv6 link-local addresses.

### Affected Services / Software ###

Nova, Neutron, networking-midonet, Kilo, Liberty

### Discussion ###

Linux assigns link-local IPv6 addresses to all the active interfaces,
which is different to that of IPv4 addresses, where an administrator
must configure each interface explicitly. Once an interface is enslaved
in a bridge, all addresses assigned to it are ignored and only the
addresses on the bridge are active. They are exposed via
LinuxBridgeManager calls to `ensure_vlan` and `ensure_vxlan` where a new
VLAN or VXLAN interface is created prior to enslaving the interfaces in
the bridge.

Both Neutron and Nova now disable IPv6 on all interfaces before bringing
the interface up. This avoids exposing a time window between when the
interface is enabled and when it is attached to a bridge device, during
which time the host could be accessible from a tenant network.

### Recommended Actions ###

IPv6 should remain disabled for each interface, before the interface is
brought to link up. If an operator, for any given reason, needs to
re-enable link-local IPv6 adreses, they should be aware of the security
implications of allowing tenant networks access of the host.

IPv6 is now disabled by default using root_dev.disable_ipv6() in
interface.py, which calls the method common.ip_utils.is_enabled()

We can verify the value of the IPv6 parameters within sysctl.conf by
using the following command:

  $ sysctl -a | grep disable | grep ipv6

A value of `0` represents IPv6 enabled, with `1` as disabled.

  net.ipv6.conf.default.disable_ipv6 = 1
  net.ipv6.conf.$IFACE.disable_ipv6 = 1

Here $IFACE refers to the interface for which IPv6 is disabled by
default in Neutron.

Note: The value set at /proc/sys/net/ipv6/conf/$IFACE/disable_ipv6 is
equivalent to net.ipv6.conf.$IFACE.disable_ipv6 in sysctl.conf

### Contacts / References ###

Author: Vinay Potluri, Intel & Luke Hinds, Red Hat
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0069
Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1534652
This issue was referenced in https://bugs.launchpad.net/Neutron/+bug/1459856
Related issue addressed in Nova: https://review.openstack.org/#/c/313070/
OpenStack Security ML : openstack-dev@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg


0x3C202614.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OSSN 0070] Bandit versions lower than 1.1.0 do not escape HTML in issue reports

[Luke Hinds]

Bandit versions lower than 1.1.0 do not escape HTML in issue reports
---

### Summary ###

Bandit versions lower than 1.1.0 have a bug in the HTML report formatter
that does not escape HTML in issue context snippets. This could lead to
an XSS if HTML reports are hosted as part of a CI pipeline.

### Affected Services / Software ###

Bandit: < 1.1.0

### Discussion ###

Bandit versions lower than 1.1.0 have a bug in the HTML report formatter
that does not escape HTML in issue context snippets. This could lead to
an XSS attack if HTML reports are hosted as part of a CI pipeline
because HTML in the source code would be copied verbatim into the report.

For example:

  import subprocess
  subprocess.Popen("alert(1)", shell=True)

Will cause "alert(1)" to be inserted into the HTML
report. This issue could allow for arbitrary code injection into CI/CD
pipelines that feature accessible HTML reports generated from Bandit runs.

### Recommended Actions ###

Update bandit to version 1.1.0 or greater.

### Contacts / References ###
Author: Tim Kelsey , HPE
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0070
Original LaunchPad Bug : https://bugs.launchpad.net/bandit/+bug/1612988
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
CVE: N/A


0x3C202614.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OSSN 0068] Repeated token revocation requests, can lead to service degradation or disruption

[Luke Hinds]

how-to-protect-against-dos-and-ddos-with-mod_evasive-for-apache-on-centos-7)

# mod_security #
https://www.modsecurity.org/

### Contacts / References ###
Author: Luke Hinds, Red Hat
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0068
Original LaunchPad Bug : https://bugs.launchpad.net/nova/+bug/1553324
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg


0x3C202614.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev