Go to main content

man pages section 8: System Administration Commands

Exit Print View

Updated: Wednesday, July 27, 2022
 
 

sxadm(8)

Name

sxadm - manage Solaris security extensions configuration

Synopsis

sxadm enable [-c property=value[,property=value,...]]
     extension[,extension,...]
sxadm exec [-i] [-s extension=value,...] command
sxadm delcust [extension,...]
sxadm disable extension[,extension,...]
sxadm get [-p] [-o field[,...]] property[,...] [extension]
sxadm help [subcommand]
sxadm set property=value[,property=value,...] extension
sxadm status [-p] [-o field[,...]] [extension]

Description

The sxadm command configures and provides information regarding Solaris security extensions.

The sxadm exec subcommand provides for enabling or disabling security extensions for a specific command. These extensions apply to the associated process, and can be inherited by any child process using the –i option. See SECURITY EXTENSIONS.

All other sxadm subcommands configure and provide information regarding system level security extensions. These extensions apply both to global zones and non-global zones.

Security extensions for a process are determined by exec(2), and become effective for a process from that point forward. Extensions persist for the lifetime of the process until the process exits or calls exec(2) again. System level extensions can affect all processes. Process level extensions affect individual processes, and are inherited by any child processes, providing the child process is not privileged. See SECURITY EXTENSIONS.

Individual executables can be tagged with security extension requirements when built with ld(1). This tagging ensures the associated process requirements are met regardless of any system level extensions. Executables with tagged security extensions can be overridden with process level extensions. See EXECUTABLE TAGGED EXTENSIONS.

Some security extensions restrict an application, providing defenses that constrain borderline behavior. As a consequence, some existing applications may fail, or experience a performance degradation, when security extensions are applied. Generally, newer defenses are more likely to cause application failure. Over time, as a class of protection becomes more mainstream, programming practices are influenced, and failures due to applying security extensions diminish.

Some security extensions may affect performance, by enabling additional checks or reducing the usage of certain caches and buffers. System administrators may need to choose between performance and security depending on the requirements of their environment.

SECURITY EXTENSIONS

The following security extensions are available. These extensions may reduce the chances of attackers finding known entry points, planting exploitation code in locations that can later be executed, or taking advantage of CPU implementations.

ADIHEAP - ADI based protections for heap allocators

Application Data Integrity is a feature introduced with SPARC M7 processors that allow ranges of memory to be tagged with unique identifiers. See adi(7). These identifiers can be used to automatically detect invalid reads and writes via pointers with non-matching identifiers. Heap allocators may use this feature to reliably detect adjacent buffer overflows and statistically defend against stray pointers and use-after-free.

ADI is a powerful technology, but can be incompatible with applications that do low level address computations. In particular, since pointers are tagged, an application relying on pointer math needs to first normalize the pointer. In addition, accesses beyond buffer limits are also detected as fatal. Some applications are known to use these accesses as designed optimizations and can fail under ADI. If an application has run successfully under a memory checker (for example, valgrind), there is a fair chance that it won't show these problems. For these reasons, the 'all' model for ADIHEAP is not supported, and extra care should be taken while testing applications that enable ADIHEAP through binary tagging.

The ADIHEAP extension is available only from certain memory allocators and only on SPARC systems that support ADI.

ADISTACK - ADI based protections for stacks

ADI identifiers can be used to enable the automatic detection of buffer overflows that overwrite the register save area of a stack frame when the save area contains valid contents.

Some applications or interpreted languages may intentionally read or modify their own stack directly. For this reason, the 'all' model for ADISTACK is not supported, and extra care should be taken while testing applications that enable ADISTACK through binary tagging.

The ADISTACK extension is available only on SPARC systems that support ADI.

ASLR - Address Space Layout Randomization

ASLR activates the randomization of the location of key areas of the process, such as the stack, brk-based heap, and memory segment mappings. The memory mappings of an application that is built as a position-independent executable are also randomized under ASLR.

HW_BTI - Hardware BTI Mitigation

HW_BTI provides hardware-based mitigation for CVE-2017-5715 (Branch Target Injection, Spectre Variant 2) for SPARC CPUs. When enabled, some applications might experience lower performance.


Note - sxadm(8) only displays the current state of HW_BTI. Enabling or disabling HW_BTI is controlled by the ILOM interface. See the Oracle ILOM Administrator's Guide for Firmware Release 4.0.x for more information. A host reboot is required to make changes.
IBPB - Indirect Branch Prediction Barrier

IBPB is a mitigation for CVE-2017-5715 for Intel CPUs. It is used in the kernel to guarantee that older indirect branches cannot influence predictions of indirect branches in the future. It is enabled by default on systems where it is required and supported. When it is enabled some applications might experience lower performance.

A reboot is required after enabling or disabling IBPB for the changes to take effect.

IBRS - Indirect Branch Restricted Speculation

IBRS is a mitigation for CVE-2017-5715 for Intel CPUs. It is called on every entry into the kernel and restricts the speculation of indirect branches. It is enabled by default on systems where it is required and supported. When it is enabled some applications might experience lower performance.

A reboot is required after enabling or disabling IBRS for the changes to take effect.

IF_PSCHANGE_MC_NO - Machine Check Error on Page Size Change Mitigation

IF_PSCHANGE_MC_NO is a readonly extension that is enabled only if the CPU includes a hardware mitigation for the Machine Check Error on Page Size Change (aka IFU) vulnerability (CVE-2018-12207).

KADI - ADI based protections for kernel heap

KADI catches memory corruption in the kernel heap using Application Data Integrity. KADI provides protection against buffer overflows, use-after-frees, use-after-reallocs, and double frees.

A reboot is required after enabling or disabling KADI for the changes to take effect.

KADI is a development-only feature to be used as a debugging aid by developers of device drivers and other kernel modules. It may decrease system stability, so is not recommended for use on production systems at this time. A future release may declare KADI suitable for production deployment.

KPTI - Kernel Page Table Isolation

KPTI isolates kernel page tables from user space processes to reduce the opportunity for kernel data leakage. On Intel CPUs this can mitigate CVE-2017-5754 Rogue Data Cache Load (RDCL) and other vulnerabilities.

KPTI is always enabled and can not be disabled on SPARC systems. KPTI is enabled by default on x86 systems. A reboot is required on x86 systems after enabling or disabling KPTI for the changes to take effect.

L1DF - Level 1 Data Cache Flush

L1DF is a mitigation for CVE-2018-3646 for Intel CPUs only. It flushes sensitive data from the L1D cache to prevent an untrusted guest virtual machine from inferring data from other guest virtual machines. This flush is performed every time the host system enters a virtual machine (VM entry). As part of this mitigation disabling hyper-threading (HT) while running virtual machines is strongly recommended.


Note - While this mitigation is only needed when running non-trusted kernel zones, full mitigation also requires disabling hyper-threading (HT).

This mitigation is enabled by default on systems where it is required and supported.

A reboot is required after enabling or disabling L1DF for the changes to take effect.

MD_CLEAR - Microarchitectural Data Sampling Avoidance Mitigation

MD_CLEAR is a mitigation for the Microarchitectural Data Sampling (MDS) series of vulnerabilities for Intel CPUs only. The vulnerabilities are CVE-2018-12126 Microarchitectural Store Buffer Data Sampling (MSBDS), CVE-2018-12130 Microarchitectural Fill Buffer Data Sampling (MFBDS), CVE-2018-12127 Microarchitectural Load Port Data Sampling (MLPDS), CVE-2019-11091 Microarchitectural Data Sampling Uncacheable Memory (MDSUM). The mitigation overwrites the store and fill buffers on the logical processors that are affected by MDS.


Note - Full mitigation also requires disabling hyper-threading (HT).

This mitigation is enabled by default on systems where it is required and supported.

A reboot is required after enabling or disabling MD_CLEAR for the changes to take effect.

MDS_NO - Microarchitectural Data Sampling Hardware Avoidance Mitigation

MDS_NO is a readonly extension that is only enabled if the CPU is not vulnerable to the Microarchitectural Data Sampling (MDS) series of vulnerabilities that are mitigated in software by the MD_CLEAR extension.


Note - On Intel CPUs that have the MDS_NO mitigation enabled, the MD_CLEAR extension will always be enabled as a readonly extension.
NXHEAP - Non-Executable Heap

NXHEAP prevents pages allocated for the process heap from being executable.

NXSTACK - Non-Executable Stack

NXSTACK prevents pages allocated for the process stack from being executable. Backward compatibility with legacy /etc/system, noexec_user_stack and noexec_user_stack_log settings is maintained, although such controls are deprecated and sxadm should be used instead.

RDCL_NO - Rogue Data Cache Avoidance Mitigation

RDCL_NO is a readonly extension that is only enabled if the CPU is not vulnerable to the Rogue Data Cache Load (RDCL) and Microarchitectural Fill Buffer Data Sampling (MFBDS) vulnerabilities (CVE-2017-5754, CVE-2018-3646 and CVE-2018-12130).


Note - Intel CPUs that have the RDCL_NO mitigation enabled also have the L1DF vulnerability (CVE-2018-3646) mitigated by the CPU. On these CPUs the L1DF extension will always be enabled as a readonly extension.
RSBS - Return Stack Buffer Speculation Mitigation

RSBS is a mitigation for CVE-2018-15572. Enabled by default, it restricts speculation based on the Return Stack Buffer state.

RSBS is always enabled on SPARC systems and cannot be disabled.

On x86 systems, RSBS may be enabled or disabled. A reboot is required for the change to take effect.

SMAP - Supervisor Mode Access Prevention

SMAP is mechanism to disallow supervisor mode execution of text mapped only in userland on Intel CPUs. It is enabled by default when it is supported by the hardware. Certain applications or drivers can fail when SMAP is enabled.

A reboot is required after enabling or disabling SMAP for the changes to take effect.

SSBD - Speculative Store Bypass Disable

SSBD is a mitigation for CVE-2018-3639. It restricts loads from speculating around older stores. It is enabled by default on systems where it is required and supported. When enabled, some applications might experience lower performance.

On SPARC, sxadm(8) only displays the current state of SSBD. Enabling or disabling SSBD can be done on Fujitsu SPARC systems that support SSBD via an XSCF command. See XSCF Reference Manual of your system for more information. A host reboot is required to make changes.

On x86 systems, SSBD is enabled per-process, either by tagging the executable with the ssbd elf tag (see ld(1)) or by executing the process via the sxadm command and enabling the feature.

On affected Intel systems with the 2021.2 IPU or later microcode updates, the SSBD extension also enables the Predictive Store Forwarding Disable (PSFD) mitigation for CVE-2021-0145.

TAA_NO - Intel TSX Asynchronous Abort (TAA) Hardware Avoidance Mitigation

TAA_NO is a readonly extension that has a status of enabled if and only if the CPU supports the Intel TSX feature and is not vulnerable to the TSX Asynchronous Abort (TAA) vulnerability (CVE-2019-11135) due to a hardware mitigation provided by the CPU. Otherwise, it has a status of not supported.

TSX_DISABLE - Intel TSX Asynchronous Abort (TAA) Avoidance Mitigation by disabling TSX

TSX_DISABLE is a readonly extension that has a status of enabled if the kernel has disabled TSX via an available control register. If both TAA_NO and TSX_DISABLE have a status of not supported, and MDS_NO also has a status of not supported, TAA may be mitigated by enabling the MD_CLEAR extension and rebooting if not already enabled. If MDS_NO has a status of enabled, then if both TAA_NO and TSX_DISABLE have a status of not supported, TAA can not be mitigated and a microcode update is necessary before TAA can be mitigated.

UMIP - User-Mode Instruction Prevention

UMIP is a mechanism on Intel CPUs that restricts the execution of specific instructions if the CPU is running outside of its highest privileged mode (e.g. running in user mode). This is a security feature to prevent potential manipulation of system software data structures by malicious userland applications. It is enabled by default when it is supported by the hardware.

A reboot is required after enabling or disabling UMIP for the changes to take effect.

By default, the global zone and all non-global zones have the ASLR, NXHEAP, ADIHEAP, ADISTACK, and SSBD extensions enabled only for tagged binaries, while the NXSTACK extension is enabled for all processes.

SECURITY EXTENSION PROPERTIES

A security extension can have one or more properties. All extensions have a model property. This property defines what the extension is applied to. Following are the model properties that exist.

model=all

Enable the security extension for all processes.

model=tagged-files

Enable the security extension for tagged binaries.

model=default

Follow the security extension system default. See SECURITY EXTENSIONS.

Security extensions may have additional properties.

NXHEAP and NXSTACK provide a logging property, which when enabled, reports attempts to execute from non-executable memory ranges (stack for NXSTACK, heap and data for NXHEAP).

log=enable

Enable logging.

log=disable

Disable logging. (Default configuration)

MANAGING SECURITY EXTENSIONS

Security extensions can be modified system wide using the sxadm subcommands enable, disable, set, and delcust. For example, the following sxadm commands enable extensions system wide.

# sxadm enable nxstack
# sxadm enable aslr,nxheap

The following sxadm command also enables extensions system wide by specifically identifying each property.

# sxadm enable -c model=all aslr
# sxadm enable -c model=all -c log=enable nxstack

Security extensions can also be enabled or disabled for a process using the sxadm subcommand exec. This subcommand only affects the status of the security extension. Any other properties of the extension are inherited from the system properties. The following sxadm command ensures the foobar process executes with disabled extensions.

$ sxadm exec -s aslr=disable -s nxheap=disable foobar

Security extensions can also be configured system wide using smf(7). The security extensions service is system/security/security-extensions, and properties are named in the form '[extension]/[property]' where extension is the name of the security extension and property is the name of the property you wish to access.

The extension status can be configured through the '[extension]/config' property, which may have the following values:

enable:    the extension is enabled at boot
disable:   the extension is disabled at boot
default:   the extension has the Oracle provided default setting

All extensions in Oracle Solaris are shipped with configuration=default.

EXECUTABLE TAGGED EXTENSIONS

Individual executables can be tagged with security extension requirements when built with the following ld(1) options.

–z sx=adiheap[=mode]

Control ADI heap allocator usage tagging.

–z sx=adistack[=mode]

Control ADI stack protection tagging.

–z sx=aslr[=mode]

Control ASLR tagging.

–z sx=nxheap[=mode]

Control non-executable heap tagging.

–z sx=nxstack[=mode]

Control non-executable stack tagging.

–z sx=ssbd[=mode]

Control SSBD mitigation tagging.

The mode can be enable or disable. If the mode is not supplied, then enabled is the default.

The security extension defined within a tagged executable interacts with any system wide security settings in the following manner.

  • Security settings within tagged executables that disable a specific extension are honored without consulting the system security settings.

  • Security settings within tagged executables that enable a specific extension are honored only when the system security setting is tagged-files.

  • Security settings specified via sxadm exec override tagged executable settings.

Sub Commands

The sxadm command has the following subcommands.

sxadm enable [–c property=value[,property=value,...]] extension[,extension,...]

Enable the specified extension for the current zone. The –c option allows sxadm to pass property values for the specific extension.

If the extension is not configurable, the command fails. If the change requires a reboot, the extension status is not modified and the extension is marked as pending changes upon reboot in the FLAGS output.

sxadm exec [–i] [–s extension=value],... command

Execute the specified command with a specific configuration for security extensions. For each security extension not explicitly configured on the command line, the system configuration is used. A child process spawned by command does not inherit the security extension configuration that is specified on the command line. Inheritance can be enabled using the –i option. setuid and privileged binaries do not inherit any configuration. Multiple configurations can be expressed from the command line using multiple –s options. If the same extension is configured more than once, the last occurrence takes precedence. In the following example, foobar is executed with ASLR enabled.

$ sxadm exec -s aslr=disable -s aslr=enable foobar

The sxadm exec subcommand is designed to accommodate the common case in which a debugger is applied to a single process started directly by the debugger. It may not be sufficient for more complex scenarios. In such cases, it may be necessary to use sxadm to change the system or zone level security extension defaults, or to apply per-object tagging using ld(1), in order to facilitate debugging.

This feature is primarily of interest when extensions based on a randomized secret are active (for example, ASLR), since changing memory addresses can complicate some debugging scenarios. This feature is also useful for explicitly testing applications with different security extension configurations.

sxadm delcust [extension,...]

Restore the extension to the default configuration. This option effectively deletes any customizations.

sxadm disable extension[,extension,...]

Disable the specified extension for the current zone.

sxadm help [subcommand]

Display usage information about sxadm or more detailed information for each subcommand.

sxadm status [–p –o field[,...]] [extension]

Report information on the status of all security extensions for the current zone. If the –p option is specified, the output is displayed in a format that can be easily parsed. Specifying an extension on the command line filters for the specific extension.

Machine parseable output is a list of colon-separated fields.

extension:status[.model]:configuration[.model]:flag[[.flag]...]

where:

extension

The name of the extension

status

The current status for the extension (enabled or disabled)

model

The current model enabled for the security extension (all, default, tagged-binaries)

configuration

The stored configuration for the extension (enabled, disabled, or system default)

flag

Flags describing the extension. Each flag is separated by a "." within the flags field.

Extensions FLAGS are as follows:

u: userland security extension
k: kernel security extension
c: the extension is configurable
r: configuration changes require a reboot
p: the extension has pending configuration changes which will be
   activated upon reboot

The characters colon (:), null sign (\0), and newline (\n) are not permitted for any of the components.

sxadm get [–p –o field[,...]] property[,...] [extension]

Display the value of security extensions properties. The property can be defined as the token "all", to display all properties. If extension is specified, display the value of the property only for the specified extension. For each property, the following columns are displayed:

extension: the extension the property refers to
name: the name of the property
value: the value of the property

All columns are displayed by default; specify specific or all columns, using the –o option. If the –p option is specified, the output is displayed in an easily parseable format. Such format is a list of colon-separated fields.

extension:name:value

The characters colon (:), null sign (\0), and newline (\n) are not permitted for any of the components.

sxadm set property=value[,property=value,...] extension

Assign value to the property of the specified extension.

Examples

Example 1 Displaying the current Security Extensions Configuration
$ sxadm status -p -o extension,status
aslr:enabled.tagged-files:u.c
nxstack:enabled.all):u.c
[...]
$

$ sxadm status
EXTENSION        STATUS                   FLAGS
aslr             enabled (tagged-files)   u-c---
nxstack          enabled (all)            u-c---
[...]
$
Example 2 Use set/get to set/retrieve Security Extensions Properties
$ sxadm get model aslr
EXTENSION       PROPERTY          VALUE
aslr            model             default

# sxadm set log=enable nxheap
# sxadm get log nxheap
EXTENSION       PROPERTY         VALUE
nxheap          log              enable
Example 3 Running a Debugging Session

The following command sequence illustrates a debugging session being conducted with ASLR disabled.

$ sxadm exec -i -s aslr=disable /bin/bash

# Because all processes (except privileged ones) inherit the
# (disabled) ASLR configuration, commands such as mdb and truss
# have repeatable results.

$ truss -t mmap /bin/true
mmap(0x00000000, 32, PROT_READ|PROT_WRITE,
    MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFE5B0000
mmap(0x00000000, 4096, PROT_READ|PROT_WRITE,
    MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFE5A0000
mmap(0x00000000, 4096, PROT_READ|PROT_WRITE,
    MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFE590000
[...]
$ truss -t mmap /bin/true
mmap(0x00000000, 32, PROT_READ|PROT_WRITE,
    MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFE5B0000
mmap(0x00000000, 4096, PROT_READ|PROT_WRITE,
    MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFE5A0000
mmap(0x00000000, 4096, PROT_READ|PROT_WRITE,
    MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFE590000
[...]
$ truss -t mmap /bin/true
mmap(0x00000000, 32, PROT_READ|PROT_WRITE,
    MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFE5B0000
mmap(0x00000000, 4096, PROT_READ|PROT_WRITE,
    MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFE5A0000
mmap(0x00000000, 4096, PROT_READ|PROT_WRITE,
    MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFE590000
[...]

Exit Status

0

The command completed successfully.

1

The command exited due to an error.

Attributes

See attributes(7) for descriptions of the following attributes:

ATTRIBUTE TYPE
ATTRIBUTE VALUE
Availability
system/core-os
Interface Stability
Committed

See Also

ld(1), exec(2), sx_enabled(3C), adi(7), attributes(7)

Oracle ILOM Administrator's Guide for Configuration and Maintenance Firmware Release 4.0.x

Fujitsu XSCF Reference Manual

History

The sxadm command was added in Oracle Solaris 11.1.0.

Support for the following security extensions was first added in the listed Oracle Solaris release:

EXTENSION
RELEASE
UMIP 11.4.30
TAA_NO, TSX_DISABLE 11.4.25
IF_PSCHANGE_MC_NO 11.4.21
RSBS 11.4.18
MD_CLEAR, MDS_NO 11.4.15
RDCL_NO 11.4.9
SSBD (SPARC - see below) 11.4.5
L1DF, SSBD (x86) 11.4.3
ADIHEAP, ADISTACK, HW_BTI, IBPB, IBRS, KADI, KPTI, SMAP 11.4.0
NXHEAP, NXSTACK 11.3.0
ASLR 11.1.0

The SSBD extension for SPARC systems was originally delivered in Oracle Solaris 11.4.5 under the name HW_SSB, and was then renamed to SSBD in 11.4.18.