Thu, Feb 14
I wonder if the only legitimate use case for modifying that page is accompanied by the ability to change that SSH key, and so potentially is sanest as a right limited to toolforge admins/roots.
Tue, Feb 12
- manager approval
- linked wmf account
- discussed in sec team meeting
I'll take care of this today or tomorrow
Mon, Feb 11
Discussed this a bit on IRC and there was a good point made about the queries themselves potentially (inadvertently even) containing sensitive data:
Fri, Feb 8
Wed, Feb 6
In theory there are tests that submit things to the grid via tools-checker
than ensure the gridmaster itself is functioning but previously we had
issues where DNS was faulty and that cascaded down IIRC so we put in some
service level checking there
Jan 16 2019
Date: Wed Jan 16 13:10:52 2019 +0000(rush) Add dsharpe to security@ for T213742
Jan 15 2019
So to me it seems like there is LDAP client config here that is confusing the admin module, the two cannot really co-exist sanely. I have some idea of how that might happen but no time to look into it atm. The LDAP setup on the NFS servers is strictly for perms lookup and is not used by the overall host. Look at how the nfsd-ldap package works that is installed on labstore1004/5
Jan 14 2019
Jan 10 2019
Could a change to coming from a 172 address have effected ratelimit whitelisting?
Pardon the pile on appearance here @TBolliger. I very much appreciate it's difficult to balance transparency and efficacy in the short term but @Bawolff for me has hit the nail on the head. Any outcome from exploring and planning will be easy to reverse engineer, but also will need to be utilized and accepted in-the-least by the members of Security and acl*stewards. If anything can be done here it's going to be beneficial to be as transparent as possible as early as possible, though I totally understand if there are issues/constraints that are not public to begin with. I assume you'll be looking at techniques such as http://valve.github.io/fingerprintjs2/ and marrying to onwiki blocking and identity correlation. To that effect...
Jan 9 2019
I will bring this up in the weekly meeting for the security team but I wanted to respond briefly now, I don't know that Security-Team is a primary stakeholder here other than being generally supportive of the value add of ORES+TWN.
Name can be bike shedded if needed :) Initial agreement in an in-person meeting was to roll with https://phabricator.wikimedia.org/project/manage/3825/ and see if it's effective/useful.
Jan 8 2019
@Daimona thanks for jumping through all the hoops here, we are trying to make this process clearer for sure. I verified your 2fa access and this was confirmed again today by @JBennett in our weekly meeting. Let me know if you have any questions or issues.
Jan 7 2019
Jan 3 2019
Dec 21 2018
We could have email@example.com go to the Toolforge admins
Dec 20 2018
Why is his a Security task?
Dec 19 2018
+1 the debian packaging path is way too tied to OS release for a sane openstack plan long term, @Andrew and I looked at a few options over time but it seems fairly popular to use some container solution
I believe what we did for L->M was to reimage the standby of an HA pair to new Release/Openstack version and then fail over to it with a day for sanity and then reimage the now-standby-originally-active. I believe control components can seemlessly be N+1 from nova-compute at least. This /should/ hold true for Neutron as well (neutron-api as +1 from l3-agent for example) but I've never actually tested it. In theory this allows a straight stagger of control plane to Stretch/Newton.
I'm not sure, generally you can go +1 for compat tho it can come with caveats as in nova-api can be one release ahead of nova-compute but not vice versa. I wouldn't think you need mitaka at all on stretch.
I think this may help:
I think T169099 is probably relevant for matching Release/OpenStack
Dec 17 2018
Dec 14 2018
Thank you @Tgr
I've included this in the Security-Team weekly meeting for the 18th
Dec 13 2018
Seems like consensus is that https://gerrit.wikimedia.org/r/c/mediawiki/core/+/478395 is the sanest outcome here. @Tgr anything blocking?
@Bawolff can this task be closed now?
Typically, we ask that staff in the Security group associate their Phab account with their Foo (WMF) account onwiki.
Part of my concern is T140369 but another part is the lack of real managed lifecycle/standards for labtest[n] instances.
Dec 12 2018
There is a public range but to this point we made it through with using
private IPs as floating IPs which has been a fine test so far. Labtest
instances are not setup in a way that would be OK to expose them on public
IPs to my knowledge.
Dec 11 2018
Dec 10 2018
small progress https://phabricator.wikimedia.org/T108360#4812282
Dec 6 2018
Good points @Aklapper. I am not sure if this wording is ours or default. I am making a note to discuss with Security-Team. One question, I have done some testing of triggering our CSP policy and I don't see this language surface in the UI. Where are people seeing this?
Dec 3 2018
I want to acknowledge a few things:
Nov 30 2018
Thanks @faidon for weighing in, I think you got right to the heart of it. Not responding to you necessarily but I'm going to steal the 3 point breakdown as it makes sense to me. I don't feel empowered to relate much of the detail for history here, but I do value this conversation and want to respond.
Nov 29 2018
Small bit of background from my perspective, I had discussed this on hangout with a few folks who I will let acknowledge their own level of approval. I used !log and pinged @elukey with the intention of uninstalling post work-at-hand. Nothing here was me intending to take unilateral action or circumvent process. I really am under the impression that Debian main has nothing which would be incompatible with WMF prod infrastructure. I have no particular affection for exfat, and would much prefer to be able to use ext but have been assured that is not a possibility. If there are legal issues here I'm glad @Legoktm flagged it.