Security Policies



STORM’s policies let developers secure application data in various ways, ranging from access control: who can insert or edit data, to information flow control: who can explicitly or implicitly access the values of sensitive data. Crucially, STORM’s expressive policy language allows specifications that depend on data values from the same row to entirely different tables.




Integrity


A policy is a predicate (assertion) over a database row and a user, whose truth determines when some action is allowed.

Here, the insert policy for Item says that only the owner of the item can add the row to the DB. We can specify update policies for each field, that determine which users can modify the values of that field. This policy says only the owner can alter the description or level, and the owner never changes.




Confidentiality


An confidentiality policy specifies which users can are allowed to read – either explicitly or implicitly, via derived computations – sensitive values in the database.

Here, the description of an Item is sensitive: the policy specifies that it should only be accessible to the owner unless the owner explicitly marked the level field to deem the item accessible to the "public".




Data Dependency


STORM policies can refer to the application’s data, stored in the same row (e.g. IsPublic) or even a different table.

Here, a Follower relationship is stored in a separate table: the assert clause specifies that each row witnesses that the subscriber follows the publisher.

We can use the follows predicate to ensure that visibility of items’ descriptions is restricted to the items’ owners and their followers.



For more examples of policies, see the paper or the demo application