New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 772073 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Email to this user bounced
Closed: Nov 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 1
Type: Feature

Blocking:
issue 509672



Sign in to add a comment

Implement secure validation API

Project Member Reported by no...@chromium.org, Oct 5 2017

Issue description

Add "validate" API endpoint to api.py that
- accepts config_set and a list of (path, contents)
- checks that requester can READ that config set
- checks requester's membership in "config-validation" group
- for each file, returns a list of validation messages

Given that 
- validation can be used for probing for confidential data
- in the vast majority of use cases, on-demand validation is needed by googlers
lock down config-validation group to googlers, and mention security implications in the group description

 

Comment 1 by no...@chromium.org, Oct 5 2017

Blocking: 509672

Comment 2 by no...@chromium.org, Oct 8 2017

Vadim,

I think normally validation result should depend only on file contents and not service state, it is just buildbucket is special. if not buildbucket, would we want authorization for validation API? If yes, why? If no, I think I have a better idea.

Restricting validation API to googlers is a cost. With the proposed design, all services pay the price b/c of buildbucket. Ideally only buildbucket should pay the price. 

WDYT about luci-config impersonating the user of the validation API when talking to individual services? Then we will implement authorization only in buildbucket.

We will have to trust luci-config to impersonate anyone to any service, but luci-config is the one who tells who to trust to, so we don’t pay with lower security here.

Then we don’t need global validation group. Only buildbucket will restrict validation to googlers. Then anyone can run PRESUBMIT on non-buildbucket configs. 

Comment 3 by no...@chromium.org, Oct 8 2017

Cc: ryanmartens@google.com

Comment 4 by no...@chromium.org, Oct 8 2017

Ideally all validation functions depend only on their inputs. Then we don’t have the security problem and don’t have to add authentication to presumit_support.py (nontrivial, want to avoid). I think reaching this state is what we should be working on.

Independently, the fact that buildbucket buckets are unique across projects causes other problems: 1) given a bucket identifier, it is not possible to derive the project id without an RPC 2) project of a bucket may change. This caused the “luci.<project>.<suffix>” bucket format that is long and weird to some people. Eventually, I think, we should lift the requirement for the buckets to be unique across projects, at least for the LUCI buckets.

WDYT about removing cross-project bucket name uniqueness check from buildbucket validation code? 

Note that Buildbucket will still guarantee that buckets are unique because it will reject the config at ingestion time, spitting an error in the log. It is worse UX (we, humans, will notify a user that their bucket is not unique) in a rare case (someone actually registered a dup bucket) with the same security (if someone has permissions to commit config, they can sniff buckets today).

We will also verify that validation in other services doesn’t depend on the service state.

Cc: kamrik@google.com

Comment 6 by no...@chromium.org, Oct 10 2017

Status: Started (was: Assigned)
talked to vadimsh@ offline

is still would be insecure to allow anyone to validate unstrusted configs. Apparently there configs in Python, and it is not hard to imagine someone python execing them.

=> we have to restrict the new validation API to googlers => we don't have implement impersonation.
Project Member

Comment 8 by bugdroid1@chromium.org, Nov 6 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/infra/luci/luci-py.git/+/9b83ba1823b051433b8bc379fcab9b2c3c5c672f

commit 9b83ba1823b051433b8bc379fcab9b2c3c5c672f
Author: Mun Yong Jang <myjang@google.com>
Date: Mon Nov 06 23:31:33 2017

[config_service] Add logging explaining why validation access is denied



Bug:  772073 
Change-Id: I0b44e1da343df1f422a79b4168643e0d00bb592f
Reviewed-on: https://chromium-review.googlesource.com/755154
Commit-Queue: Mun Yong Jang <myjang@google.com>
Reviewed-by: Nodir Turakulov <nodir@chromium.org>

[modify] https://crrev.com/9b83ba1823b051433b8bc379fcab9b2c3c5c672f/appengine/config_service/api.py

Project Member

Comment 9 by bugdroid1@chromium.org, Nov 8 2017

The following revision refers to this bug:
  https://chrome-internal.googlesource.com/infradata/config/+/d65e548229e531a1485c3c42ea680f59e074e6d7

commit d65e548229e531a1485c3c42ea680f59e074e6d7
Author: Mun Yong Jang <myjang@google.com>
Date: Wed Nov 08 18:04:33 2017

Comment 10 by myjang@google.com, Nov 20 2017

Status: Fixed (was: Started)

Sign in to add a comment