3.40 Access Control Pitfalls

Access control deals with assets, actors and actions, or in other words which actors have access to which assets and how much of those assets and what actions can the actors use to access those assets.

Access Control Specification

The access control specification should detail who can access what and why should they have that access, when can that access happen and how much of those assets can the actors access. All these aspects should be very accurately specified in great detail, so that they can be correctly implemented and enforced across the different contracts and functions, and across all the system transitions and flows that happen within those contracts and functions.

This should help determine the trust, the threat models and any assumptions that are being made from this model. Without such an access control specification it will be very hard or even impossible to evaluate if the implementation actually enforces all these aspects.

Access Control Implementation

The implementation of access control should make sure that every aspect of the access control that was specified in the specification is implemented uniformly and accurately across all the actors on all the assets via all the actions possible. The implementation should make sure that none of the actors, assets and flow conditions within actions are missing or may be sidestepped. Such an implementation should help us evaluate if the access control enforcement has been done correctly according to the specification.

Access Control Modifiers

Access control is typically enforced in Solidity smart contacts by means of modifiers. Instead of implementing access control checks that are required for different functions multiple times in each of those functions, modifiers allow us to encapsulate those checks in one place and then these modifiers can be applied on any of those functions that require the access control checks implemented within them. While this encapsulation brings in the desired aspect of modularity, modifiers also impact auditability.

There's a school of thought that believes that modifiers are good for auditability: they make it easier because they implement all the checks in one place, so instead of reviewing the same checks multiple times in multiple functions these checks can be reviewed once within the modifier, then check if these modifiers are applied correctly to all the functions that require those checks, so that makes auditability easier.

On the flip side, there's another school of thought that believes that modifiers are not as good for auditability as thought. The reason is that if there is a contract that has multiple modifiers and many functions that use those modifiers, then remember that the programming style guidelines recommend modifiers to be declared and defined at the beginning of the contract, and all the functions come thereafter so, if an auditor is reviewing functions deep down within the contract and it uses multiple modifiers, then they have to scroll up to the modifiers at the beginning of the contracts to check if the desired checks were implemented and if they were implemented correctly. This switching of context in the process of scrolling is believed to not lead to good auditability.

Nevertheless, modifiers are used extensively and reviewing these modifiers should make sure that they are indeed present on the functions that require the checks implemented by them, that modifiers implement valid checks in a correct manner and their order is also correctly specified for functions that use multiple modifiers.

Modifiers Implementation

Given the critical role of modifiers in access control, modifiers need to be implemented correctly. But what does that mean? Access control in smart contracts is enforced on different addresses that may be classified into different roles with differing privileges.

Like we discussed in earlier modules, contracts may have a simple ownership based access control or a more flexible one based on RBAC. In such RBAC scenarios we need to check that modifiers are enforcing the correct checks on the correct roles, that such checks are composed correctly. Such a correct implementation is critical to access control which is the fundamental aspect of smart contract security and therefore needs to be reviewed very carefully.

Modifiers Usage

It is not sufficient to have the modifiers implemented correctly, but they should be used or applied correctly as well: the questions of which modifiers are used, why are they used, the how/what aspects, what are the parameters passed to them and what should they do with them, the order of modifiers when more than one is present, the when aspect (under what state transitions should they be applied), finally the where aspect (the functions where they're applied to). All such aspects of modifiers their functions and any parameters should have been considered correctly.

Access Control Changes

The access control implemented may need to be changed in some scenarios. In such cases, it is critical that the change is done correctly with respect to the assets actors or actions that are impacted. Using the wrong addresses for assets or actors, or allowing the changes to happen at the wrong times in the context of the application logic may lead to loss or locking of funds. Therefore, access control changes should be validated for correctness, use a two-step process to allow recovery from mistakes and also log changes for transparency and off-chain monitoring.