What are sensible values for glide.script_processor.authorized_script_module_role as part of ISC security score?

[Michael Everson]

Hi all,

As part of improving our security score in the Instance Security Center, I want to set the property glide.script_processor.authorized_script_module_role.

I have read the documentation, but it does not suggest what sensible values might be.

Does anyone have any experience/guidance with changing this value?

[Paul Curwen]

The Test steps are listed in the Support article: 

Description

Referencing 'Authorization for script execution' documentation, script does not run if role is inherited or
if multiple roles are displayed in system property.

https://docs.servicenow.com/bundle/sandiego-platform-administration/page/administer/security/referen...

Steps to Reproduce

0. Log into instance with system administrator account with itil role explicitly added (not inherited)
1. Navigate to System Properties [sys_properties].list
2. Create new record:
Name: glide.script_processor.authorized_script_module_role
Value: admin
3. Click Save.
4. In a new tab, navigate to Modules [sys_app_module] table
5. Create new record (the info below is test information):
Title: Testing Script Execution
Application: Self-Service
Order: 100
Link type: Script (from Arguments:)
Arguments: console.log('Test')
6. Click Save.

EXPECTED BEHAVIOR WITH SINGULAR NON-INHERITED ROLE (admin and itil):
7. Reload page and select module created in step 5.
8. Observe script ran (if using test information, the script above will fail, but thats okay)
9. Navigate to first tab (system property record)
10. Change value to 'itil'
11. Click Save.
12. Navigate to 2nd tab, reload page and select module created in step 5.
13. Observe script ran (if using test information, the script above will fail, but thats okay)

UNEXPECTED BEHAVIOR WITH MULTIPLE ROLES:
14. Navigate to first tab (system property record)
15. Change value to 'admin,itil'
16. Click Save.
17. Navigate to 2nd tab, reload page and select module created in step 5.
18. Observe script does not run. Following message appears:
Unable to execute script in app module Testing Script Execution, user does not have authorized role.

INHERITED ROLES SETUP:
19. Navigate to Users [sys_user] table.
20. Search for System Administrator [admin] record:
/nav_to.do?uri=sys_user.do?sys_id=6816f79cc0a8016401c5a33be04be441
21. Remove itil role.
a. Scroll to Roles related list.
b. Click Edit.
c. Remove 'itil' from slushbucket on the right.
d. Click Save.
22. Add a group containing itil role.
a. Scroll to Groups related list.
b. Click New.
c. Create new record (this is test information):
Name: Test Group
d. Click Submit.
e. Open newly created group in Groups related list.
f. In Roles tab, click Edit.
g. Add itil role from left slushbucket to right slushbucket.
h. Click Save.
23. In the System Administrator [admin] record, ensure that the user has itil role and Inherited=true:
/nav_to.do?uri=sys_user.do?sys_id=6816f79cc0a8016401c5a33be04be441

**Login and logout to ensure role is updated**

UNEXPECTED BEHAVIOR WITH INHERITED ROLES:
24. Navigate to first tab (system property record).
25. Change value to 'itil'
36. Click Save.
37. Navigate to 2nd tab, reload page and select module created in step 5.
38. Observe script does not run. Following message appears:
Unable to execute script in app module Testing Script Execution, user does not have authorized role.

Workaround

This problem is currently under review. You can contact ServiceNow Technical Support or subscribe to this Known Error article by clicking the Subscribe button at the top right of this article to be notified when more information becomes available.

Related Problem: PRB1583002

---

Seen In

	Tokyo Patch 6
	Tokyo Patch 7
	Utah Patch 1

Fixed In

	San Diego Patch 10
	Tokyo Patch 5
	Utah

[MattSN]

OOB you'll see that the module type "Script (from Arguments:)" is only ever used for admin functions like enabling/disabling debug modes.

You can see the list of modules in this link.
https://<instanceName>.service-now.com/sys_app_module_list.do?sysparm_query=link_typeINSCRIPT%5Elink_type%3DSCRIPT

It is already controlled in most cases by the role value on each module. This property takes it step further to ensure accidentally left open modules cannot be executed by lower roles. Setting it to 'admin,catalog_admin' is probably enough for most customers.