For system security, the Oracle Solaris OS provides many features, including features that developers can use.
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 the Trusted Extensions Developer’s Guide and the Trusted Extensions User’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.20 Amendment 3 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 https://www.oracle.com/technetwork/java/javase/tech/index-jsp-136007.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.
You can use the sxadm status command to view the status of a security extension. For example:
$ sxadm status EXTENSION STATUS CONFIGURATION aslr enabled (tagged-files) default (default) nxstack enabled (all) default (default) nxheap enabled (tagged-files) default (default)
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 Managing Security Extensions in Objects With elfdump and
elfedit
ASLR tagging is provided by an entry in the object's dynamic section, which can be inspected with elfdump (1) .
$ 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:
Using Application Data Integrity (ADI) in Oracle Solaris 11.3 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 commands 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.