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 …