Lua Security

Lua Scripting is one of the powerful features of system:inmation, making it highly flexible. But with great power comes great responsibility! This document addresses the system’s means to control said power.

While Security References to Profiles in the Access Model configure which objects users can access and which permissions they are granted for these objects, these permissions have no influence on Lua scripts running on Lua Executing Objects. They are applied to Lua scripts the user runs in the Console, though.

For Lua Scripts running on Lua Executing Objects (LEOs) the general behavior of how they can access system objects is defined in Core > Lua Security Options > Lua Security Mode. Options are:

  • Permissive - Lua scripts can access all objects

  • Restrictive - Lua scripts can not access objects unless permissions are explicitly granted

  • Inherit - Lua Security behavior is inherited from the parent Core (only applies to Local Cores)

The Permissive and Restrictive options will be addressed in detail in the following sections.

Running Lua instances are not affected by changing the Lua Security Mode! To apply the new Security Mode to such a Lua instance, disable and re-enable the object hosting the script. When accessing the system via an API, the changes only come into effect for new API requests.

Permissive Mode

In Lua Security Mode: Permissive, Lua Scripts running on Lua Executing Objects have unrestricted access to system by default.

Simple Permissive Mode Lua Security

Here, the user is assigned to Profile A and Profile B in the Access Model, restricting which objects he can access.

Profile A grants the user write (W) permission for Lua Executing Object. Therefore he can write a Lua script running there.

Although the user himself has no access to Data Item (or any other object), in Permissive Mode his Lua script can access Data Item (and all other objects in the system).


Restricting Lua Permissions in Permissive Mode

To restrict permissions for scripts running on Lua executing objects Security Perimeter objects can be used. In this case, Lua scripts hosted on Lua Executing Objects underneath a Security Perimeter object (like Lua Executing Object 1) by default can only access objects which are also located underneath this Security Perimeter object.

Additionally, Lua scripts running underneath a Security Perimeter can also be granted access to objects outside the Security Perimeter branch. This is done by creating a Security Reference for the respective object, referring to the Security Perimeter object. To do this, drag-and-drop the Security Perimeter object onto the respective target object.

Permissive Mode With Security Perimeter

In this example, the script on Lua Executing Object 1 can only access Data Item C but neither Data Item A nor Data Item B which are outside the perimeter.

For Data Item B a Security Reference was created. Therefore Lua Executing Object 1 can access this object although the object is not located inside the Security Parameter branch of the I/O Model tree.

Lua Executing Object 2 is located outside the Security Perimeter. Therefore the scripts running on this object are not restricted by the perimeter but can access all objects in the system, even those which are located underneath Security Perimeter objects, like Data Item C.


Restrictive Mode

If Core > Lua Security Options > Lua Security Mode is set to Restrictive, Lua scripts can not access any objects, unless they are running in the same Security Context.

With the Restrictive Mode two new concepts are introduced: the Security Subject and the Security Context.

  • The Security Subject is an object which acts as a man-in-the-middle between Lua Executing Objects and the objects a Lua script interacts with.

  • The Security Context is the sum of all Security References (pointing at different Security Subjects) for an individual object. If only one Security Reference exists, Security Context and Security Subject are effectively the same.

For Lua Executing Objects, Script Profile objects are recommended as Security Subject for Restrictive Mode. It’s also possible - but not recommended - to use the next ancestor Core as Security Subject. For Lua scripts which are executed in the DataStudio Console Display, the Profile with which the current user is logged-in, is used as the Security Subject.

If a Security Perimeter object exists on a superior level in the I/O branch, this acts as the Security Subject for all its descendants, overriding all other Security Subject configuration for Lua Executing Objects in this branch.

Restrictive Mode Without Permissions

Restrictive Mode Without Permissions

In this example, no permissions have been granted for Data Item, therefore - in Restrictive Mode - it is not accessible to Lua Executing Object.

When the Lua Security Mode is set to Restrictive, the Restrictive Security Options section becomes available, where permissions for included Lua libraries can be configured. This topic will be addressed in detail in Lua Library Permissions

Granting Permissions in Restrictive Mode

In Restrictive mode, for Lua scripts to be able to access system objects, both, the Lua Executing Object and the system object(s), have to be connected via the Security Subject.

To create such a connection …​

First, the LEO needs to be added to the Assigned Objects table property of the Script Profile which will act as Security Subject. Alternatively an ancestor object can be added to the table, connecting all its descendant LEOs to this Security Subject. To do this, open the table property and drag-and-drop the LEO (or ancestor) into the Assigned Objects column of the first empty row. Then click OK to close the table property and Apply these changes to the Script Profile object.

Second, system objects which should be made accessible to the LEO need to have a Security Reference pointing at Script Profile acting as Security Subject. To create a Security Reference, drag-and-drop the Script Profile object onto the system object(s) which should be made accessible and specify the individual permissions in the opening dialog.

Multiple LEOs can be added to a single Script Profile’s Assigned Objects table property and multiple objects can have Security References pointing at this Script Profile while single Objects can also reference multiple Script Profiles.

Access Model for Lua Security: Restrictive

This figure illustrates the Access Model configuration for the example below.

For Script Profile A, the Assigned Objects property lists LEO 2.

For Script Profile B and Script Profile C, the Assigned Objects properties both list LEO 3.

Restrictive Mode With Script Profiles

Here, the Core has a Security Reference to Script Profile A as well as Script Profile B with List (L), Read (R) and Inherit (I) permissions. Due to the Inherit permission, all descendant objects of the Core inherit these permissions. Therefore all Lua Executing Objects (LEOs) listed in the Assigned Objects property of either Script Profile A or Script Profile B can List (L) and Read (R) from all descendants of the Core. To all ancestors of the Core object, the List (L) permission is granted implicitly.

Data Item has a Security Reference to Script Profile A, explicitly granting it Write (W) permission.

LEO 2 being listed in the Assigned Objects property (see the Access Model above) of Script Profile A, Lua scripts running on this object have write access to Data Item.

Since Explicit Permissions overrule Implicit Permissions, the implicit permissions which Data Item inherited through its ancestors from Core, no longer apply. To bring those back, they would have to be recreated as additional Explicit Permissions for Data Item.