Go to main content

Developer's Guide to Oracle® Solaris 11.3 Security

Exit Print View

Updated: April 2020

System Security

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 Framework

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.

Using the sxadm Command to Manage Security Extensions

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/bash
Example 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>
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
$ elfedit -e 'dyn:sunw_sx aslr disable' a.out
$ elfdump -d a.out | grep ASLR

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.

Debugging When Using Security Extensions

    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.