Hi. I'm Glenn Faden, one of the architects for Oracle Solaris 11. Although I retired last year, my Oracle blog postings are still available, and Darren Moffat recently posted a new entry about Application Sandboxing. I also developed the new file and process labeling features which can be used to restrict access to sensitive data, which is a core requirement for every organization. Inadequate information classification and policy enforcement have contributed to embarrassing and costly data breaches. Administrators with root access have often been responsible for such data loss. Oracle Solaris 11.4 provides a set of unique access controls that can prevent processes, even with root privileges, from reading sensitive data.
The root account has traditionally been all powerful in UNIX systems. Oracle Solaris 8 introduced Role Based Access Control (RBAC) which made it possible to limit root access to authorized users. Oracle Solaris 10 extended RBACwith a new privilege model that greatly reduced the need for root access. At the same time the concepts of basic privileges and the limit privilege set were introduced, enabling the Principle of Least Privilege to be applied to any process, even those running as root. Oracle Solaris 11 added immutable zones, making it possible to lock down the security policy configuration. Even a process with all privileges cannot modify an immutable configuration.
Oracle Solaris 11.4 adds the concept of data classification so that access is further restricted based on process clearance. This clearance policy supplements the existing Discretionary Access Policy (DAC - based on users and groups), and the Solaris privilege policy. Although a process with sufficient privilege can override the DAC policy, there are no privileges to override the clearance policy. Users with sufficient clearance can apply sensitivity labels to ZFS file system objects and to IPC objects such as shared memory. Newly created files and directories automatically inherit the label of their parent directory. ZFS file systems and their snapshots are also automatically labeled with the maximum label of their contents. These labeled objects are only accessible to processes with sufficient clearance.
Process clearance is established at login time based on the user's RBAC attributes via Pluggable Authentication Modules (PAM). Although any process can lower its clearance, there is no interface by which a process can raise its clearance. Roles are also assigned clearances; when an authorized user assumes a role via su(8), the resulting process clearance is set to the minimum of the current user clearance and the role's clearance. Similarly, users with full sudo(8) access are still limited by their process clearance. Processes with insufficient clearance cannot observe, trace, or debug other processes; nor can they observe or modify kernel memory.
Clearances are defined using labels whose components are configured via labelcfg(8) based on an organization's security policies. The table below is based on the clearances that are specified in /etc/security/tsol/label_codings.compliance, which is further described here. It demonstrates how process clearances are reduced when switching to another user. Bob and Alice have each been granted the root role, but they have disjoint clearances. The label C Internal Use Only is the greatest lower bound (minimum label) that they share.
|Using su or sudo||to Bob||to Alice||to root|
|from Bob||C Payment Data||C Internal Use Only||C Payment Data|
|from Alice||C Internal Use Only||C Health Records||C Health Records|
|from root||C Payment Data||C Health Records||Admin_High|
Process clearances are also maintained by the Service Management Facility (SMF) which sets the specified or default clearance for each service. Only a few services need explicit clearances, such as those that assign clearances to user processes. Services such as login, ssh, and the Remote Access Daemon (RAD) are started with the maximum clearance.
Although a process cannot raise its own clearance, there are provisions for authorized users to instantiate new processes with an elevated clearance. These facilities include RBAC profiles, sandboxing, and the Trusted Path Domain.
Readers who are familiar with Trusted Solaris or its successor, Trusted Extensions, know that labeling has been an optional feature of Solaris for decades. In fact, the new labeling and clearance functionality shares much of its infrastructure with Trusted Extensions. However, Trusted Extensions enforces a more restrictive policy in which data labels must be preserved when data is moved or copied, even over the network. The new Oracle Solaris clearance policy is more flexible and does not prevent users with sufficient clearance from sharing labeled data with uncleared users. This flexibility is appropriate because the policy is enabled by default in Solaris 11.4. Its effects are generally transparent until clearances and labels are explicitly assigned to users and data. Trusted Extensions remains an alternative policy which can be enabled using labeladm(8).