You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ratis.apache.org by "Elek, Marton" <el...@apache.org> on 2021/01/12 09:14:42 UTC
Hardening Ratis Grpc services (+incompatible change?)
Ratis GRPC has multiple GRPC services:
* RaftClientProtocolService
* RaftServerProtocolService
* AdminProtocolService
If all of them use the same port / netty server a malicious client/user
may send admin/setConfiguration requests to the servers adding more
groups or re-configuring existing ones.
For example if somebody implements any authentication/authorization on
the StateMachine level, it can be ignored by adding more nodes and
replicating the raw Ratis data.
I suggest to improve the GrpcService.java and add only the configured
services. With this approach mTLS can be turned on for admin and
server2server communication but not for the client.
The only problem is the RaftClientProtocolService.setConfiguration. It's
an un-safe operation and more-like an admin command.
Do you see any problem to move setConfiguration to AdminProtocolService?
(Which is an incompatible change).
Marton
Re: Hardening Ratis Grpc services (+incompatible change?)
Posted by "Elek, Marton" <el...@apache.org>.
Thanks the feedback. I opened RATIS-1286 and created the first PR
https://github.com/apache/incubator-ratis/pull/394
I am planning to create an other one to make it configurable which GRPC
services are added to the GRPC server. (To make it possible to separated
calls).
Marton
On 1/12/21 11:34 AM, Tsz Wo Sze wrote:
> +1
> We should move the methods as described. Indeed, it is the best time doing
> the moving before the 2.0 release.
>
> Tsz-Wo
>
>
> On Tue, Jan 12, 2021 at 6:01 PM Elek, Marton <el...@apache.org> wrote:
>
>>
>>
>> Same is true for the new transferLeadership method. I would move it to
>> the AdminProtocolService.
>>
>> Marton
>>
>> On 1/12/21 10:14 AM, Elek, Marton wrote:
>>>
>>> Ratis GRPC has multiple GRPC services:
>>>
>>> * RaftClientProtocolService
>>> * RaftServerProtocolService
>>> * AdminProtocolService
>>>
>>>
>>> If all of them use the same port / netty server a malicious client/user
>>> may send admin/setConfiguration requests to the servers adding more
>>> groups or re-configuring existing ones.
>>>
>>> For example if somebody implements any authentication/authorization on
>>> the StateMachine level, it can be ignored by adding more nodes and
>>> replicating the raw Ratis data.
>>>
>>> I suggest to improve the GrpcService.java and add only the configured
>>> services. With this approach mTLS can be turned on for admin and
>>> server2server communication but not for the client.
>>>
>>> The only problem is the RaftClientProtocolService.setConfiguration. It's
>>> an un-safe operation and more-like an admin command.
>>>
>>> Do you see any problem to move setConfiguration to AdminProtocolService?
>>>
>>> (Which is an incompatible change).
>>>
>>> Marton
>>
>
Re: Hardening Ratis Grpc services (+incompatible change?)
Posted by Tsz Wo Sze <sz...@gmail.com>.
+1
We should move the methods as described. Indeed, it is the best time doing
the moving before the 2.0 release.
Tsz-Wo
On Tue, Jan 12, 2021 at 6:01 PM Elek, Marton <el...@apache.org> wrote:
>
>
> Same is true for the new transferLeadership method. I would move it to
> the AdminProtocolService.
>
> Marton
>
> On 1/12/21 10:14 AM, Elek, Marton wrote:
> >
> > Ratis GRPC has multiple GRPC services:
> >
> > * RaftClientProtocolService
> > * RaftServerProtocolService
> > * AdminProtocolService
> >
> >
> > If all of them use the same port / netty server a malicious client/user
> > may send admin/setConfiguration requests to the servers adding more
> > groups or re-configuring existing ones.
> >
> > For example if somebody implements any authentication/authorization on
> > the StateMachine level, it can be ignored by adding more nodes and
> > replicating the raw Ratis data.
> >
> > I suggest to improve the GrpcService.java and add only the configured
> > services. With this approach mTLS can be turned on for admin and
> > server2server communication but not for the client.
> >
> > The only problem is the RaftClientProtocolService.setConfiguration. It's
> > an un-safe operation and more-like an admin command.
> >
> > Do you see any problem to move setConfiguration to AdminProtocolService?
> >
> > (Which is an incompatible change).
> >
> > Marton
>
Re: Hardening Ratis Grpc services (+incompatible change?)
Posted by "Elek, Marton" <el...@apache.org>.
Same is true for the new transferLeadership method. I would move it to
the AdminProtocolService.
Marton
On 1/12/21 10:14 AM, Elek, Marton wrote:
>
> Ratis GRPC has multiple GRPC services:
>
> * RaftClientProtocolService
> * RaftServerProtocolService
> * AdminProtocolService
>
>
> If all of them use the same port / netty server a malicious client/user
> may send admin/setConfiguration requests to the servers adding more
> groups or re-configuring existing ones.
>
> For example if somebody implements any authentication/authorization on
> the StateMachine level, it can be ignored by adding more nodes and
> replicating the raw Ratis data.
>
> I suggest to improve the GrpcService.java and add only the configured
> services. With this approach mTLS can be turned on for admin and
> server2server communication but not for the client.
>
> The only problem is the RaftClientProtocolService.setConfiguration. It's
> an un-safe operation and more-like an admin command.
>
> Do you see any problem to move setConfiguration to AdminProtocolService?
>
> (Which is an incompatible change).
>
> Marton