Skip Navigation Links | |
Exit Print View | |
Developer's Guide to Oracle Solaris 11 Security Oracle Solaris 11.1 Information Library |
1. Oracle Solaris Security for Developers (Overview)
Overview of Oracle Solaris Security Features for Developers
2. Developing Privileged Applications
3. Writing PAM Applications and Services
4. Writing Applications That Use GSS-API
7. Writing Applications That Use SASL
8. Introduction to the Oracle Solaris Cryptographic Framework
9. Writing User-Level Cryptographic Applications
10. Introduction to the Oracle Solaris Key Management Framework
A. Secure Coding Guidelines for Developers
B. Sample C-Based GSS-API Programs
For system security, the Oracle Solaris OS provides process privileges. Process privileges are 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 Chapter 2, Developing Privileged Applications.
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 and the Trusted Extensions User’s Guide for more information.
Oracle Solaris provides the following public interfaces for security:
Cryptographic framework – The cryptographic framework is the backbone of cryptographic services in the Oracle Solaris OS. The framework provides standard Extended PKCS#11, v2.20 Amendment 3 Library , henceforth referred to as PKCS #11, 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 plug-ins. See Chapter 8, Introduction to the Oracle Solaris Cryptographic Framework for an overview of the cryptographic framework. See Chapter 9, 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 RSA PKCS #11 specification. Both consumers and providers communicate with the user-level cryptographic framework through standard PKCS #11 calls.
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 http://www.oracle.com/technetwork/java/javase/tech/index-jsp-136007.htm.
ASLR is a feature of the Oracle Solaris system that randomizes the starting address of key portions of the process address space such as stack, libraries, and brk-based heap. By default, ASLR is enabled for binaries explicitly tagged to request ASLR. The following command provides information about the status of ASLR:
% sxadm info
EXTENSION STATUS CONFIGURATION aslr enable (tagged-files) enable (tagged-files)
The -z option to the ld(1) command is used to tag a newly created object with an ASLR requirement. The usage is as shown below:
ld -z aslr[=mode]
where mode can be set to enable or disable. If mode is not specified, enable is assumed.
The following example demonstrates the use of the -z option to create an executable with ASLR enabled:
% cat hello.c #include <stdio.h> int main(int argc, char **argv) { (void) printf("Hello World!\n"); return (0); } % cc hello.c -z aslr
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_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_aslr enable' a.out % elfdump -d a.out | grep ASLR [29] SUNW_ASLR 0x2 ENABLE
% elfedit -e 'dyn:sunw_aslr disable' a.out % elfdump -d a.out | grep ASLR [29] SUNW_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(1) 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.
The sxadm(1) command is used to control the default ASLR default behavior for the system. Binaries that are explicitly tagged to disable ASLR take precedence over the system default behavior established by sxadm.
Address Space Randomization may be problematic during debugging. Some debugging situations require that repeated invocations of the program use the same address mappings. You can temporarily disable ASLR in one of the following ways:
Temporarily disable ASLR system wide
% sxadm exec -s aslr=disable /bin/bash
Use ld or elfedit commands to tag the associate binary to disable ASLR
Establish an ASLR disabled shell in which to carry out debugging
% sxadm exec -s aslr=disable /bin/bash
Note - This ASLR modification cannot be applied to SUID or privileged binaries.
See the sxadm(1M) man page and Chapter 2, Configuring Oracle Solaris Security, in Oracle Solaris 11 Security Guidelines for more information.