SECLABEL Parameter

Purpose

The SECLABEL parameter specifies the security label for a job in z/OS systems running with security labels enabled. Security labels are used in environments with mandatory access control (MAC) and are part of the RACF (Resource Access Control Facility) or other security management systems to enforce multilevel security (MLS) policies.

Syntax

JOB Statement Format

1
//jobname JOB parameters,SECLABEL=seclabel-name

Parameter Value

seclabel-name

• 1-8 character name of a security label defined to the security system (RACF)
• Must be a valid security label name in the installation's security profile
• Represents a specific security level and set of security categories
• Must be accessible to the user who submits the job

Security Concepts

Multilevel Security (MLS)

Multilevel security is a security policy that allows information with different sensitivities to be processed simultaneously while preventing unauthorized access. In an MLS environment:

• Security levels represent hierarchical levels of sensitivity (e.g., UNCLASSIFIED, CONFIDENTIAL, SECRET, TOP SECRET)
• Security categories represent non-hierarchical areas of concern (e.g., PROJECT-A, FINANCIAL, PERSONNEL)
• Security labels combine a security level with zero or more security categories

How Security Labels Work

When a job runs with a specific security label:

1. The job inherits the security level and categories associated with the label
2. Data access is restricted based on the job's security label
3. The job can only access resources with compatible security labels
4. Output created by the job inherits the job's security label

Usage Examples

Basic SECLABEL Specification

1
2
//TESTJOB JOB (ACCT),'JOHN DOE',CLASS=A,
//         MSGCLASS=X,SECLABEL=SECRET

This job will run with the security label SECRET, which might allow access to data classified as SECRET or lower.

SECLABEL with User Identification

1
2
3
//TESTJOB JOB (ACCT),'JOHN DOE',CLASS=A,
//         USER=JSMITH,PASSWORD=PASS1234,
//         SECLABEL=PROJECTA

This job runs under user ID JSMITH with the security label PROJECTA, which might restrict access to data related to PROJECT-A.

Access Control Rules

Read Access

For a job to read data, the following must be true:

• The job's security level must be greater than or equal to the data's security level
• The job's security categories must include all the data's security categories

Write Access

For a job to write data, the following must be true:

• The job's security level must be less than or equal to the data's security level
• The data's security categories must include all the job's security categories

Typical Security Label Hierarchy

Implementation Details

RACF Configuration

Before SECLABEL can be used in JCL, the security system (typically RACF) must be configured:

1. Security levels must be defined using the RDEFINE SECDATA SECLEVEL command
2. Security categories must be defined using the RDEFINE SECDATA CATEGORY command
3. Security labels must be defined using the RDEFINE SECLABEL command
4. Security labels must be activated using the SETROPTS MLACTIVE command
5. Users must be permitted to use specific security labels via the PERMIT command

Job Submission Validation

When a job with SECLABEL is submitted:

1. The security system verifies that the submitting user has access to the specified security label
2. If verification fails, the job is rejected with a security violation message
3. If verification succeeds, the job runs with the specified security label

Common Use Cases

Government and Defense Applications

• Processing classified information at different sensitivity levels
• Enforcing compartmentalization of information between projects
• Complying with regulatory requirements for information handling

Financial and Healthcare Applications

• Protecting personally identifiable information (PII)
• Segregating financial data by sensitivity
• Meeting compliance requirements like HIPAA, PCI DSS, or GDPR

Commercial Applications

• Protecting trade secrets and intellectual property
• Enforcing need-to-know access to sensitive business information
• Segregating customer data in multi-tenant environments

Best Practices

1. Use descriptive security label names that clearly indicate their purpose
2. Document the security label scheme to ensure consistent application
3. Test jobs with various security labels to ensure proper access controls
4. Implement the principle of least privilege by using the lowest appropriate security label
5. Create procedures for handling security label exceptions when normal processing is blocked
6. Regularly audit security label usage to ensure compliance with security policies
7. Consider setting default security labels for users to simplify job submissions

Troubleshooting

Common Issues

Common Error Messages

• ICH408I USER(userid) ... INSUFFICIENT ACCESS AUTHORITY ... SECLABEL=seclabel-name - User does not have access to the specified security label
• ICH408I USER(userid) ... RESOURCE NOT PROTECTED ... CLASS=SECLABEL RESOURCE=seclabel-name - The specified security label is not defined

Related Concepts

• JOB Statement - The statement where SECLABEL is specified
• USER Parameter - Often used with SECLABEL to specify the user ID under which the job runs
• PASSWORD Parameter - Used with USER parameter for authentication
• GROUP Parameter - Specifies the security group for the job, another security-related parameter

System-Specific Considerations

z/OS with RACF

In z/OS with RACF, security labels are fully supported with comprehensive features:

• Labels can be defined with multiple security levels and categories
• Mandatory access control (MAC) can be strictly enforced
• Security label checking can be done for various system resources

Other Security Products

Other security products may have different implementations:

• ACF2 and Top Secret have similar concepts but may use different terminology
• Implementation details and syntax may vary between security products
• Consult your specific security product documentation for details