Skip to content
This repository was archived by the owner on Aug 2, 2022. It is now read-only.

Contract and actor whitelist/blacklist #3376

Closed
arhag opened this issue May 24, 2018 · 1 comment
Closed

Contract and actor whitelist/blacklist #3376

arhag opened this issue May 24, 2018 · 1 comment
Assignees
Milestone

Comments

@arhag
Copy link
Contributor

arhag commented May 24, 2018

Summary

A subjective means for each node to be configured to reject speculatively executing transactions based on a whitelist or blacklist. This feature would not impact whether a node accepts a block signed by a producer.

Motivation

Nodes may want the ability to blacklist or whitelist certain contracts from executing on their node under the context of producing a block (either speculatively or as the real block producer that will then sign the block).

Such an ability, particularly whitelisting, will be quite handy early on in the first bootstrapping process of an EOSIO blockchain to provide confidence that the core functionality of the chain (system contract, token contract, multisig contract, and native actions) are all working together properly prior to opening up the chain arbitrary user-submitted contract which greatly increase the attack surface.

Even well after launch, the ability for producers to coordinate in blacklisting a buggy contract causing issues or malicious actors exploiting newly found bugs in the system (and to be able to quickly adapt the blacklists without a recompilation or replay required) can prove very useful as a temporary "soft forking" fix until a proper fix is implemented later (perhaps as a hard forking fix or maybe just by upgrading a WASM contract to a version that fixes the bug).

Description

A whitelist or blacklist can be provided just like other nodeos options (in config.ini or via command line arguments) for contracts and actors (i.e. the authorizing accounts of a transaction). In the future, an API can be provided to dynamically query and modify the whitelists and blacklists without requiring a restart of nodeos; but this will not be supported by 1.0.

A whitelist takes precedence over a blacklist. This means that if a single entry exists in a whitelist, the corresponding blacklist (if even specified) is ignored. If there are no entries in a whitelist, then the corresponding blacklist is enforced (it is allowed to also be empty of course).

Contract whitelist/blacklist

A contract whitelist/blacklist determines whether an action (whether user-specified or contract generated) will be delivered to code of an account. The contract whitelist/blacklist does not take effect if the receiver does not have any code set.

If there exists a single entry in the contract whitelist, nodeos will check to see if the receiver of the action is in the whitelist. If not, the transaction causing that action dispatch will be rejected by the local node.

If the contract whitelist is empty, nodeos will check to see if the receiver of the action is in the blacklist. If so, the transaction causing that action dispatch will be rejected by the local node.

The whitelist/blacklist enforcement does not need to apply for generating a transaction or including a delayed transaction in the blockchain (though it could). However, it should be enforced when a deferred transaction is considered for retirement.

Actor whitelist/blacklist

An actor whitelist/blacklist determines whether an input transaction (whether delayed or not) should be included into the blockchain. It does need to apply to retiring deferred transactions.

If there exists a single entry in the actor whitelist, nodeos will check to see if all of the actors authorizing an input transaction are in the whitelist. If not, that input transaction is rejected by the local node.

If the actor whitelist is empty, nodeos will check to see if any of the actors authorizing an input transaction in the blacklist. If so, that input transaction will be rejected by the local node.

@arhag arhag added this to the Version 1.0 milestone May 24, 2018
@arhag arhag self-assigned this May 24, 2018
arhag added a commit that referenced this issue May 29, 2018
Auth checks should also be skipped when replaying reversible blocks.

Do not skip block signature checks if --force-all-checks passed.
arhag added a commit that referenced this issue May 29, 2018
@arhag arhag removed the in progress label May 29, 2018
@craigspys
Copy link

Pls I have a issue I can’t make any transaction in my EOS account it says authorizing actor of transaction is on the blacklist

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

No branches or pull requests

3 participants