Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove proxy #27

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Remove proxy #27

wants to merge 1 commit into from

Conversation

d-xo
Copy link
Collaborator

@d-xo d-xo commented Jul 28, 2019

As far as I can tell, the proxy only protects against one edge case attack (a malicous plan could write directly to the plans mapping, allowing it to create plans that can executed with no delay). All other storage locations are exposed on interfaces that require only that they are being called from a plan.

The only case that I can see where this would give an attacker a real advantage is if there was an attack that could only be composed of multiple simulatneous transactions executed with the identity of the pause.

Given that plot is authed and a malcious plan could anyway take ownership of the entire pause, I think that the risk introduced by the additional implementation complexity that this countermeasure requires is greater than the risk of allowing this particular attack.

This does mean losing one nice invariant: 'There is no way to bypass the delay'.

Am I missing something?

cc @kmbarry1 @iamchrissmith @gbalabasquer

This only protected against one edge case attack (a malicous plan that
plotted new plans that could be immediately executed).

Given that plot is authed and a malcious plan could anyway take
ownership of the entire pause, this counter-measure is not worth the
addtional complexity.
@gbalabasquer
Copy link
Contributor

I think yeah, it was exactly how you described. The only thing that the proxy avoids is the possibility of accessing directly to the plans storage.
The reality is in practice you could just get a proposal passed that sets the delay to zero and that is enough to afterwards add a lot of malicious other proposals. And I'd say probably is not even necessary, you can do all the bad things you want in just one proposal.
As I always said, the constant evaluation of proposals close to be the hat is the important key thing here. One malicious proposal gets to be the hat then almost sure the damage is done. Maybe excepting a very amateur attacker (which is almost impossible for someone that makes to get that amount of funds).

@iamchrissmith
Copy link

It seems to me the proxy provide only limited protection and increases the complexity so I would support removing it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants