Whitelist for SCM Packages
In the context of the ThingWorx C SDK SCM edge extension, a whitelist is a simple text file that provides a C SDK application with a list of executables on the device that should be allowed to process a script that has been downloaded in a package from a ThingWorx platform. It is up to developers to create the whitelist. If you are downloading a script to devices, the whitelist must provide the extension for the script file and the path to the executable. The following table lists some scripting languages that you may want to use, their file extensions, and the default paths to the scripting executables on devices.
Scripting Language
File Extension
Default Path to Executable
Node.js
js
/usr/local/bin/node
Python
py
/usr/bin/python
Bash script
sh
/bin/bash
BASIC (Windows)
bas
c:\Program Files\cscript.exe
Batch (Windows)
bat
cmd /c
For example, js is the extension for a node.js script and the path to the executable on a Linux device is /usr/local/bin/node. For the Windows Script Host, the file extension is bas, and the path to the executable is c:\Program Files\cscript.exe. For a bash script on Linux you would use sh for the file extension and /bin/bash for the executable path .Here is an example of a whitelist:
# This is a sample whitelist
# please review it before using it in production
js,/usr/local/bin/node
bas,c:\program files\cscript.exe
bat,cmd /c
py,/usr/bin/python
In this example, the first entry shows the extension for node.js (js) and the path to the executable on a Linux device. The second entry shows the extension for BASIC (bas) and the path to the executable on a Windows computer. The third entry is for Windows batch (bat) file and the path for launching it. The fourth line provides the extension for Python (py) and the path to the Python executable on a Linux device.
SCM Security: Execute Packages as a Specific User in the Whitelist
To prevent malicious code from being downloaded and executed on your Edge devices, you can set up the whitelist to include a specific user identifier. With a user defined in the whitelist, the script in the package will execute as the user specified in the whitelist when run on Linux devices.
* 
This feature works only if the user you want to run as has lesser privileges than the user that your application is running as. Often systems that wish to perform setup operations must be running as user 0 (root). Some systems may require that the user have permissions needed to perform a setuid operation, such as enabling CAP_SETUID or its equivalent. Refer to the documentation for your operating system for more information on permitting setuid() permissions.
On Windows, the user field contains a "well-known security ID" string (SID), as described at https://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/security-identifiers. The SID string corresponds to the lowest possible security level at which the installed script can successfully be executed. The installation occurs at the security level indicated by the generic security string in the user field of the whitelist.
Specifically, the SID should be one of the following:
"S-1-16-0" for Untrusted Mandatory Level
"S-1-16-4096" for Low Mandatory Level
"S-1-16-8192" for Medium Mandatory Level
"S-1-16-8448" for Medium Plus Mandatory Level
"S-1-16-12288" for High Mandatory Level
* 
The user field can also be left empty, indicating that the install process should be run at the security level of the current user.
Was this helpful?