gRFC L61-core: gRPC security level negotiation between call credentials and channel.

[Yihua Zhang]

I have created a gRFC  - https://github.com/grpc/proposal/pull/167

Please let me know your comments on this thread.

[Christopher Warrington - MSFT]

On Thursday, December 5, 2019 at 12:31:56 PM UTC-8, Yihua Zhang wrote:

> I have created a gRFC - https://github.com/grpc/proposal/pull/167
>
> Please let me know your comments on this thread.

I think it would be useful to add to the proposal:

* an explanation of the pros/cons that lead to the determination of the
  required level is only settable by the credential implementation and not
  the application;
* a brief explanation about why UDS and TCP local connections were assigned
  the level they were assigned; and
* an explanation of the behavior when a credential is not transferred because
  the connection didn't meet the required level (e.g., call failure vs no
  propagation vs something else).

Consider assigning the grpc_security_level enum members explicit numerical
values with gaps in them for future extension.

Also, I'm not following the "Rational" section as currently written...

Do the permissions on the UDS that is associated with a file system path
need to affect its level? Is a UDS in a 777 directory still considered
privacy+integrity or should that be insecure?

Does there need to be a privacy+integrity local connection on all platforms?
Right now, it looks like Windows won't have one, because local TCP is
considered insecure and there's currently no UDS transport on Windows.

--
Christopher Warrington
Microsoft Corp.

[Yihua Zhang]

Thanks much for the great comments. Please see inline. 

On Thursday, December 5, 2019 at 3:46:19 PM UTC-8, Christopher Warrington - MSFT wrote:

On Thursday, December 5, 2019 at 12:31:56 PM UTC-8, Yihua Zhang wrote:

> I have created a gRFC - https://github.com/grpc/proposal/pull/167
>
> Please let me know your comments on this thread.

I think it would be useful to add to the proposal:

* an explanation of the pros/cons that lead to the determination of the
  required level is only settable by the credential implementation and not
  the application;

I added more explanation to the gRFC. Basically by making it only settable by credential implementation 1) we can avoid the situation when the security level is incorrectly set by an application either intentionally or by mistake and 2) the behavior will be consistent with gRPC java and Go.  

 

* a brief explanation about why UDS and TCP local connections were assigned
  the level they were assigned; and

I added more explanation to the gRFC. Basically UDS can be treated as relatively secure (assuming a correct file permission is set) since it is possible to authenticate a remote peer and data confidentiality is also guaranteed against passive adversaries. But for local TCP, we cannot authenticate the remote peer and thus there is no point to further discuss confidentiality and integrity. 

* an explanation of the behavior when a credential is not transferred because
  the connection didn't meet the required level (e.g., call failure vs no
  propagation vs something else).

It will fail. I updated the gRFC to make it more clear.  

Consider assigning the grpc_security_level enum members explicit numerical
values with gaps in them for future extension.

Good point. the gaps are added. 

Also, I'm not following the "Rational" section as currently written...

Sorry for the confusion. Basically, plugin credentials are designed to be inherited by other call credentials with each of them having their own security level. And without this configuring capability all of them will be stuck with the same security level. 

Do the permissions on the UDS that is associated with a file system path
need to affect its level? Is a UDS in a 777 directory still considered
privacy+integrity or should that be insecure?

UDS will be treated secure only if a correct directory permission is set. 

 

Does there need to be a privacy+integrity local connection on all platforms?
Right now, it looks like Windows won't have one, because local TCP is
considered insecure and there's currently no UDS transport on Windows.

I do not see necessity for that. Also transport security for local connections is always an option.