TDSEC:TDOMS Security

From Remain Software
Jump to navigation Jump to search
Secbadge.png

TD/OMS Security Document

This document discusses the security aspects of TD/OMS. It explains who has access to what functions inside TD/OMS, how this can affect security, and how you can mitigate the vulnerabilities.


TL;DR;

To mitigate the problems described below, you can create two special user-profiles and place them in the user profile supplemental groups of the users you trust to perform these actions.

OMSSECADM
Only members of this group profile can do security-related actions.
OMSEXITADM
Only members of this group profile can do user-exit-related actions.

Vulnerability: Arbitrary Code Execution

TD/OMS contains many exit points that can help you tune your DevOps flow. It also means that TD/OMS can be exploited to execute arbitrary code on any development, test, and production machine. Exit programs can be created in the following ways:

Actions
Actions will execute code during the deployment of tasks. Actions can, but are not limited to, performing checks, stop and start subsystems, checking for locks, and controlling the flow of objects in the DevOps cycle. Actions can also be executed manually outside of the deployment. During deployment, Actions will be automatically executed by TD/OMS, no matter who initiates it. Actions can be used as a trojan horse to execute malicious code.
Exceptions
Exceptions are a simple form of Actions and propose the same security risk.
Compilation Types
The compilation of an object is usually tied to any of IBM's internal compilation commands, but any developer can change them. Developers can add code that will be executed during the compilation of an object. This code might not be related to compilation. Compilation types can be used as a trojan horse to execute malicious code.
Events
TD/OMS contains an extended eventing system. When an action is performed inside TD/OMS, you can attach an Event Subscriber to listen for a specific event and execute arbitrary code when the event occurs. Event Subscribers can be used as a trojan horse to execute malicious code.
Call API
Part of the TD/OMS REST API can execute a program. The programs that can be called by the API have to be registered in table OMPCP. Programs are executed under the right of TD/OMS and the rights of the user using the API.
Data Conversion
TD/OMS contains rules to convert data from one file version to another. This conversion may execute a conversion program on the remote machine.

Mitigation: Arbitrary Code Execution (since V151KEM01)

People who can instruct TD/OMS to execute code during the deployment may be restricted to a small group of individuals. By creating a group profile with the name OMSEXITADM you restrict the following programs to the members of this group. This is an additional security measure on top of normal TD/OMS rights. E.g., a TD/OMS Application Manager may not enter code execution functions if this user's profile does not contain OMSEXITADM as a supplemental group.

Actions
All Action related functions.
Exceptions
All Exception related functions.
File Conversion
File data conversions alter how data is converted for a file, including conversion programs.
Event Subscriber
Events Subscribers may execute arbitrary code.
Compile Types
Compile instructions may contain arbitrary code.


Compile Overrides - Are not included

For the moment, developers can still create compile overrides. Compile overrides are replacement compilation commands that are sometimes needed to compile a specific object in a special way. Programmers can theoretically insert malicious code into a compile override. To mitigate this, compile overrides can be authorized by members of the OMSEXITADM group, if it exists. If it does not exist, then the compile overrides can be authorized by the normal administrators. The green screen function to see the unauthorized compile commands is STROCM.

If the OMSEXITADM user exists and the compile override is not authorized, processing will continue, but a message will be logged in the transfer log.

Vulnerability: Malicious code insertion

One of the security threats is the insertion of wrong or malicious code into programs. During the flow of code from development to production, procedural steps ensure the quality of the code. During these phases, the following steps must be executed:

Peer Review
Programmers will take a look at the new source code by running a side-by-side comparison. If this review succeeds, the colleague will enter a ratification (approval) for all the objects in the task.
Unit Testing
Unit tests will be executed to ensure the code is still working as expected and regression has not occurred. The unit test can ratify (approve) the task based on the test result.
Functional Testing
Does the code do what it is advertised to do? If so, the functional tester may ratify the task.
Quality Control
Does the code meet the company's quality control criteria? If so, the QA tester may ratify the task.


After all these steps have been performed, the task is ready to go to production.

TD/OMS assures the following:

  • The task is not promoted when not all required ratifications (approvals) are in.
  • Only authorized people may go to the production environment


How can we ensure that the day-to-day administrators of TD/OMS will not bypass the defined procedures?
Functions related to TD/OMS Security can only be accessed by members of the OMSSECADM group. If this profile does not exist, then no explicit additional security checks are done.


Security prerequisites

TD/OMS Security can only be implemented successfully in concert with the normal IBM i security. Users with *ALLOBJ or *SECADM rights can bypass or alter TD/OMS security. Setting insufficient authority restrictions on objects will enable people to bypass TD/OMS.


Who can Access TD/OMS

Out of the box, TD/OMS enforces security on the system and application level, but various concerns are not divided over multiple role types. The TD/OMS Application Manager (any user with code '3' in an application) can assign other users, create exit programs, attach database conversion programs, and create Event Subscribers. Also, the application manager determines who can ratify (approve) workflow tasks and who can deploy them to production. While this will help to implement the system quickly, you might want to restrict access to these functions when the system goes live.

To be able to work with TD/OMS, the following is :

  • be assigned a named license,
  • When floating licenses are used, functions can be started by anyone with proper TD/OMS authorization,
  • *SECOFR, *SECADM and the TD/OMS Administrator can start system-wide functions like System Definition and Application Authority Maintenance.
  • Application Managers (code 3 in any application) can access functions that overarch applications. These functions are Action Maintenance, Exception Maintenance, Connection Rules, and Ratification Group Maintenance.

OMS Administrator

People with *SECOFR and *SECADM authority and the TD/OMS Administrator can start system-wide functions. The TD/OMS administrator can be set in the System Definition function. Only people with *SECOFR and *SECADM or the TD/OMS Administrator (once set) can start this function. The TD/OMS Administrator is a group profile or a user profile.


Mitigation: Protecting the Ratification and Security settings (since V151KEM01)

Functions related to TD/OMS Security can only be accessed by members of the OMSSECADM group (if it exists). When the OMSSECADM group profile exists, the following checks are done:

  • Application Security is restricted
    • Application Managers (code '3' users) are appointed by the OMSSECADM group.
  • Some Ratification Group functions are restricted to the OMSSECADM group
    • Adding or removing members from Ratification Groups
    • Assigning or removing a ratification group
    • Deactivating environment ratification
  • Some Environment Security functions are restricted to the OMSSECADM group
    • Adding or removing environment owners
    • Changing ratification attributes

Vulnerability: Exploit the TD/OMS Authority Grant Program

The TD/OMS Authority Grant command (GRTAUTOMS) is executed on initial installation and after each update of the TD/OMS Kernel. This program operates of tables that assign each object the proper owner and execution grants. The authority classes are stored in OM009C and the class assignments for objects are stored in OM009D.

Command GRTAUTOMS does not adopt authority so it will only be effective when called by an elevated user profile or job.


Security prerequisites

TD/OMS Security can only be implemented successfully in concert with the normal IBM i security. Users with *ALLOBJ or *SECADM rights can bypass or alter TD/OMS security. Setting insufficient authority restrictions on objects will enable people to bypass TD/OMS.


===Mitigation: Audit the security classes and data.

  • Command DSPOADOMS can be used to list the current settings in the authority tables. Review this report as part of your audits.