Re: [openstack-dev] [Neutron] Call for review focus

[Carl Baldwin]

On Fri, Nov 20, 2015 at 3:57 PM, Armando M.  wrote:
> On 20 November 2015 at 14:07, Kyle Mestery  wrote:
>> On Wed, Nov 18, 2015 at 8:14 PM, Armando M.  wrote:
>>>
>>> Hi Neutrites,
>>
>> Neutrinos?
>
> I am still experimenting to see what sticks...So far I got Neutrinos,
> Neutronians, and Neutrites...Neutrinos is the one I like most, but
> Neutronians is cool too. Ludicrous, uh?

I think of myself as a Neutronian and my kids as Neutrinos.  :)

Carl

__
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] [keystone] Case for renewability of tokens, increasing expiration time

[Jamie Lennox]

I realize this has been mostly closed up, but just a few additions.

On 19 November 2015 at 08:06, Dolph Mathews  wrote:


> On Tue, Nov 17, 2015 at 2:56 PM, Lindsay Pallickal 
> wrote:
>
>>
>>
>> On Tue, Nov 17, 2015 at 5:31 AM, Dolph Mathews 
>> wrote:
>>
>>>
>>>
>>> On Tuesday, November 17, 2015, Lindsay Pallickal 
>>> wrote:
>>>

 It looks like expiration is done this way to limit the damage from
 stolen tokens, but if a token were stolen, it could be stolen from the same
 location a username and password will now have to sit, to get around having
 to re-supply them manually once an hour. Yes, forcing re-auth hourly with a
 username and password, at the Keystone level, can limit damage if any of
 the core Openstack services are compromised for the mass theft of tokens.
 But limited damage will depend just as much on how quickly the compromise
 is detected. The more time an attacker has in the system, the less his
 actions will be hampered by a lack of token renewals. VMs can be
 compromised, and data exported or destroyed given just a small window.

>>>
>>> This first part of this is only a "maybe", not a completely true
>>> assertion. There are *many* more opportunities for individual tokens to be
>>> exposed than for the credentials used to create them. In the case if a mass
>>> token compromise, which I consider to be a completely different scenario,
>>> token expiration probably isn't going it be any help because there's
>>> probably always a fresher token available to the attacker, anyway, until
>>> the exploit is closed. Instead, keystone has several means of quickly
>>> revoking tokens in bulk (revocation events, truncating the UUID token
>>> table, restarting the memcache token backend, or rotating all your Fernet
>>> keys away... all depending on your deployment).
>>>
>>
>> The token does get sent a lot more often than the username/password
>> credentials, but as long as both are sent via SSL/TLS, shouldn't the
>> opportunity for exposure be similar? Although, I could see it being easier
>> to accidentally send a token in the clear, or in a way vulnerable to a mitm
>> (ignoring ssl cert issues), as there are frequently more bits of code in
>> the client that deal using a token, versus a just few bits to secure when
>> deal with logging in. Tokens get passed around to far more services with
>> potential vulnerabilities as well, but I see that as a separate issue. I
>> agree with your comment that token expiration will not really help in a
>> mass compromise scenario.
>>
>
> Similar, yes, but with a couple significant differences. Off the top of my
> head:
>
> In keystone's v2 API, bearer tokens are a part of the URL in token
> validation calls and token revocation calls. Of course, access logs are
> everywhere and many deployments do these operations over HTTP! The v3 API
> relegates them to headers, at least. I wonder if it would be possible to
> have keystoneauth / keystoneclient log a client-side warning when it's
> asked to send a bearer token over HTTP?
>
> And certainly, the number of possible attack vectors on a bearer token
> being passed around to a bunch of services is increased by an order of
> magnitude.
>

OpenStack is also fairly free with its tokens. You send it to every service
and every service that needs to do work elsewhere forwards it to someone
else. At least keeping the token system the only service that your
username/password is ever exposed to is keystone. An attacker able to
compromise another service still has a lot of power due to the bearer-ness
of tokens but they didn't get your user/pass.


>>
>>>

 On the other hand, if a user facing application, or a long running
 service supporting one, needs the API and is to remain convenient, they
 have to store usernames and passwords. Sometimes that long running service
 is connected to the outside world and faces security threats, such as when
 relaying Openstack API requests to their respective internal network
 endpoints - similar to what Horizon does. I wonder if I use Horizon
 continuously, whether it will force me to manually re-authenticate hourly,
 and if not, how it is getting around this problem, with or without storing
 the username and password.

>>>
The solution that was developed for this situation in heat was trusts. With
this you delegate certain roles to the service user from the original user
to act on your behalf. This lets those service users perform actions on
behalf of users after the initial request has expired. Now there are
similarly all sorts of security implications to trusts, the ability to
steal trust ids, who sets them up, whats delegated, however if done right
they are a much more secure alternative than simply soring user/pass as at
least they are already project and role restricted.



>
>>> Bearer tokens are 

[openstack-dev] [midonet] FYI: Ryu Ishimoto new MidoNet PTL

[Sandro Mathys]

Since we're moving to use this mailing list and other OpenStack
infrastructure soon, I thought I should forward the results of our
recent MidoNet PTL elections to the openstack-dev list.

-- Sandro

-- Forwarded message --
From: Sandro Mathys 
Date: Sat, Nov 21, 2015 at 10:53 AM
Subject: Re: [MidoNet-dev] Electing a MidoNet PTL
To: Ryu Ishimoto 
Cc: midonet-dev 


Alright, the nomination period has ended and there has only been a
single proposal for candidacy. Ryu clearly fulfills all the
requirements, therefore his candidacy is approved.

However, as stated before, there's no point in having an election with
only just one candidate. So please join me in congratulating Ryu to
becoming the first-ever MidoNet PTL, effective immediately!

Thanks for stepping up Ryu! Looking forward on collaborating with you
to reach your high-level goals for our team!

-- Sandro

On Fri, Nov 20, 2015 at 12:46 PM, Ryu Ishimoto  wrote:
>
> I would like to propose my candidacy for the MidoNet PTL.
>
> I have been a MidoNet and Neutron contributor for 5 years, basically from
> the start of both projects.  Because of my lengthy and close involvement in
> both projects, including the integration work, I believe I have the
> appropriate knowledge to steer the MidoNet project in the right direction.
>
> If I were to be chosen for PTL, my high level goals for the next 6 months
> will be:
>
> * Improve stability:  While we have made strides in improving quality of the
> software with the release of v5.0, it is clear that we still have a lot of
> room for improvement.  We must continuously keep fixing bugs until it gets
> to a manageable number.
> * Improve feature development:  This includes better specs, better test
> coverage, better documentation, and other factors that must be considered to
> really 'complete' the feature (ready to be used in production).
> * Improve developer collaboration: MidoNet is made up of different
> components that handle separate concerns; API, Cluster, and Agent, with
> developers with specific expertise scattered among these components.  For
> MidoNet to succeed, developers with different expertise must work together
> effectively.
> * Increase the community size: MidoNet is new to open source and still not
> getting enough contributors.  I will put a lot of effort to change this.
>
> Thanks!
> Ryu Ishimoto (GitHub ID: ryu25ish)
>
>
> On Sat, Nov 14, 2015 at 1:37 AM, Sandro Mathys  wrote:
>>
>> Dear Midos,
>>
>> It's about time we get a proper PTL, and it's also in line with our
>> planned / ongoing adoption of the OpenStack ways [1].
>>
>> "PTL means Project Team Lead. Each OpenStack official project team
>> elects a leader who has final say over all things in that specific
>> project team (and all the code repositories within it)." For more
>> information, see [2].
>>
>> PTLs usually get to serve for ~6 months, but we're a tad late to the
>> PTL election party so the first PTL term will be shorter. We'll try to
>> do the next PTL election at the same time as OpenStack next spring, so
>> the first PTL term will rather be 4-5 months long.
>>
>> Everyone who contributed to any of the repos in the MidoNet
>> organization [3] on GitHub will:
>> 1) be eligible for candidacy
>> 2) get a single vote in the election
>>
>> To propose your candidacy, simply send your self-nomination to this
>> thread. Your proposal must include your full name, your GitHub ID and
>> optionally your candidacy statement. I will then verify your
>> eligibility and add you to the list of candidates.
>>
>> If there's only a single candidate at the end of the nomination
>> period, that person will automatically become PTL. Otherwise, we'll
>> organize an election, using the CIVS [4] and a Condorcet algorithm
>> (Schulze/Beatpath/CSSD variant). In case of a tie, we'll use
>> OpenStack's way of breaking the tie [5].
>>
>> The nomination period starts right now, and ends on Friday, 2015-11-20
>> at 23:59 UTC. The election period will start shortly after (no later
>> than Sunday, 2015-11-22 at 23:59 UTC) and end on Sunday, 2015-11-29 at
>> 23:59 UTC (or a bit later, since ending the election is a manual
>> process).
>>
>> Let me know if there's any questions or concerns. Otherwise, looking
>> forward to your candidacy proposals!
>>
>> Cheers,
>> Sandro
>>
>> [1] https://lists.midonet.org/pipermail/midonet/2015-November/000315.html
>> [2] https://wiki.openstack.org/wiki/PTL_Guide
>> [3] https://github.com/midonet
>> [4] http://civs.cs.cornell.edu/
>> [5] https://wiki.openstack.org/wiki/Governance/TieBreaking
>> ___
>> MidoNet-dev mailing list
>> midonet-...@lists.midonet.org
>> http://lists.midonet.org/listinfo/midonet-dev
>
>

__
OpenStack Development Mailing List (not for usage questions)