For system security, the Oracle Solaris OS provides many features, including features that developers can use. In this release, file labeling provides labels to sensitive data to comply with isolation requirements from corporate security, legislation, and standards bodies. For more information, see Chapter 3, Labeling Files for Data Loss Protection in Securing Files and Verifying File Integrity in Oracle Solaris 11.4 and Chapter 6, Labeling Processes for Data Loss Protection in Securing Users and Processes in Oracle Solaris 11.4.
For highly stringent system security, the Oracle Solaris OS provides the Trusted Extensions feature, which is outside of the scope of this book. The Trusted Extensions feature enables system administrators to specify the applications and files that a particular user can access. See Trusted Extensions Developer’s Guide for more information.
Oracle Solaris provides the following public interfaces for security:
Process privileges – Privileges provide an alternative to the standard, superuser-based UNIX model for granting access to privileged applications. The system administrator assigns users a set of process privileges that permit access to privileged applications. A user does not need to become superuser to use a privileged application.
Privileges enable system administrators to delegate limited permission to users to override system security instead of giving users complete root access. Accordingly, developers who create new privileged applications should test for specific privileges instead of checking for UID = 0. See Developing Privileged Applications.
Cryptographic Framework – The Cryptographic Framework is the backbone of cryptographic services in Oracle Solaris. The framework provides standard Extended PKCS#11, v2.40 Errata 01 Library, henceforth referred to as PKCS #11, which contains interfaces to accommodate consumers and providers of cryptographic services. The framework has two parts: the user Cryptographic Framework for user-level applications and the kernel Cryptographic Framework for kernel-level modules. Consumers that are connected to the framework need no special knowledge of the installed cryptographic mechanisms. Providers plug into the framework with no special code necessary for the different types of consumers.
The consumers of the Cryptographic Framework include security protocols, certain mechanisms, and applications that need to perform cryptography. The providers to the framework are cryptographic mechanisms as well as other mechanisms in hardware and software plugins. See Introduction to the Oracle Solaris Cryptographic Framework for an overview of the Cryptographic Framework. See Writing User-Level Cryptographic Applications to learn how to write user-level applications that consume services from the framework.
The library for the Cryptographic Framework is an implementation of the PKCS #11 specification. Both consumers and providers communicate with the user-level cryptographic framework through standard PKCS #11 calls.
Key management framework – The key management framework helps the developers and system administrators to choose among several different keystore systems when designing systems that employ PKI technologies. For more information, see Introduction to the Oracle Solaris Key Management Framework.
Java API – Java security technology includes a large set of APIs, tools, and implementations of commonly used security algorithms, mechanisms, and protocols. The Java security APIs span a wide range of areas, including cryptography, public key infrastructure, secure communication, authentication, and access control. Java security technology provides the developer with a comprehensive security framework for writing applications, and also provides the user or administrator with a set of tools to securely manage applications. See Java SE Security (https://www.oracle.com/java/technologies/javase/javase-tech-security.html).
Security extensions in Oracle Solaris provide system-level and process-level security. These extensions reduce the chances of attackers finding known entry points, or planting exploitation code for later execution.
The following security extensions are available in Oracle Solaris:
aslr – Address Space Layout Randomization (aslr) randomizes the starting address of key portions of the process address space such as stack, libraries, and brk-based heap. By default, binaries are explicitly tagged with the aslr extension which helps in requesting aslr extension.
nxheap – Non-Executable Heap (nxheap) prevents pages allocated for the process heap from being executable. By default, this extension is enabled.
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. By default, this extension is enabled.
adiheap – Provides a reliable defense against linear buffer overflows and a valid mitigation against use-after-free issues. adiheap can also uncover subtle, latent bugs that have not affected the binary behavior yet, but can be triggered by an otherwise innocuous code change.
For more information about Application Data Integrity (ADI) heap protection, see Preventing Process Heap Corruption Using adiheap in Securing Systems and Attached Devices in Oracle Solaris 11.4.
For more information about developing applications that use ADI, see the adi(2) and adi(3C) man pages. See also Using Application Data Integrity (ADI) in Oracle Solaris 11.4 Programming Interfaces Guide and Hardware-Assisted Checking Using Silicon Secured Memory (SSM).
adistack – Enables the use of Application Data Integrity (ADI) for the detection of buffer overflows that overwrite the register save area of a stack frame in a SPARC 64-bit user process. adistack protection works only with SPARC 64-bit applications running on platforms that support ADI.
When adistack is enabled, protection is active by default on the main stack of the application and the default stack of application threads created by the thr_create() or pthread_create() function.
The application must enable ADI on the stack memory to enable adistack protection if one of the following conditions is true:
If an application explicitly allocates stack memory for threads created by thr_create() or pthread_create().
If an application allocates a signal stack set up with sigaltstack().
ADI can be enabled by specifying MAP_ADI when allocating memory using the mmap() function or by specifying the MC_ENABLE_ADI operation with the memcntl() function.
For more information, see the thr_create(3C), sigaltstack(2), memcntl(2), mmap(2) and pthread_create(3C) man pages.
For more information about ADI-based stack protection, see ADI-Based Stack Protection Using adistack in Securing Systems and Attached Devices in Oracle Solaris 11.4.
kadi – Uses ADI to assist in debugging kernel ADI errors. For more information, see Using KADI in Writing Device Drivers in Oracle Solaris 11.4.
For a full list of developer interfaces, see Using Application Data Integrity (ADI) in Oracle Solaris 11.4 Programming Interfaces Guide.
You can use the sxadm status command to view the status of a security extension. For example, the following output is from a SPARC T7 system with a debug kernel:
$ sxadm status EXTENSION STATUS FLAGS adiheap enabled (tagged-files) u-c-- adistack enabled (tagged-files) u-c-- aslr enabled (tagged-files) u-c-- hw_bti enabled ---r- hw_ssb not supported ----- kadi enabled -kcr- kpti enabled ----- mds_no enabled ----- nxheap enabled (tagged-files) u-c-- nxstack enabled (all) u-c-- rdcl_no enabled -----
You can enable or disable the security extensions at the system level by using the sxadm utility, for example:
$ sxadm exec -s aslr=disable
Binaries that are explicitly tagged to disable the security extension take precedence over the system default behavior established by sxadm utility:
$ sxadm exec -s aslr=enable /usr/bin/bashExample 1 Enabling ASLR in a Program
The following example demonstrates the use of the –z sx option to create an executable with ASLR enabled. The following examples are also applicable to other security extensions.
$ cat hello.c
#include <stdio.h>
int
main(int argc, char **argv)
{
(void) printf("Hello World!\n");
return (0);
}
$ cc hello.c -z sx=aslr
To enable the security extensions at build time, use the ld command.
$ ld -z sx=extension={enable | disable}
Example 2 Using elfdump and elfedit to Manage Security
Extensions in Objects
ASLR tagging is provided by an entry in the object's dynamic section, which can be inspected with the elfdump command.
$ elfdump -d a.out | grep ASLR [28] SUNW_SX_ASLR 0x2 ENABLE
The elfedit(1) command can be used to add or modify the ASLR dynamic entry in an existing object.
$ cc hello.c $ elfedit -e 'dyn:sunw_sx aslr enable' a.out $ elfdump -d a.out | grep ASLR [29] SUNW_SX_ASLR 0x2 ENABLE
$ elfedit -e 'dyn:sunw_sx aslr disable' a.out $ elfdump -d a.out | grep ASLR [29] SUNW_SX_ASLR 0x1 DISABLE
The ASLR requirements for a given process are established at process startup, and cannot be modified once the process has started. For this reason, the ASLR tagging is only meaningful for the primary executable object in the process.
The pmap utility can be used to examine the address mappings for a process. When used to observe the mappings for an executable which has ASLR enabled, the specific addresses used for the stack, library mappings, and the brk-based heap will differ for every invocation.
For more information, refer to:
Requesting Security Extensions in Oracle Solaris 11.4 Linkers and Libraries Guide
Using Application Data Integrity (ADI) in Oracle Solaris 11.4 Programming Interfaces Guide
Security extensions can be problematic during debugging. You can temporarily disable the security extension in one of the following ways:
Temporarily disable a security extension system wide
$ sxadm disable extension
Use the ld or elfedit command to tag the associated binary to disable the security extension
Disable the security extension in a shell in which you want to carry out debugging
$ sxadm exec -i -s extension=disable /usr/bin/bash
–i passes the extension setting to the inheriting child process.