Oracle Solaris Security Hardening Guide: Zones, RBAC and Immutable Global Zones

Oracle Solaris still runs billing, trading, telecoms signalling and database estates, and those hosts are often hardened once at build time and then left to drift for years. Solaris 11.4 ships strong controls that Linux administrators may not recognise: root as a role rather than a login account, rights profiles evaluated by profile shells, kernel privileges that can be removed from users and services, and immutable zones that make the operating system read-only even to root. This guide covers how identity and privilege work on Solaris 11.4, how to configure zones and the immutable global zone, how to audit and assess against the built-in compliance benchmarks, and the misconfigurations that undo these protections. It is written for Unix administrators, platform security engineers and auditors responsible for Solaris estates.

Key takeaways

• Keep root a role. Solaris 11.4 makes root a role by default, so administrators log in as themselves and assume root, which keeps a named person in every audit record. Converting root back into a login user removes that accountability.
• Grant rights through profiles, not privileges. Oracle warns that a privilege assigned directly to a user can be used anywhere the kernel checks it; assigning it as an attribute of a command inside a rights profile limits it to that command.
• Immutable zones change the threat model. A file-mac-profile of fixed-configuration or strict stops package installation and most file changes even for root, and the global zone can be made immutable too.
• Use the compliance tool, then tailor. The compliance command assesses against the Solaris Baseline and Recommended profiles and a PCI DSS benchmark; the CIS Benchmark for Oracle Solaris is a separate product from CIS.
• Audit the role assumption, not just the logins. The AUE_PFEXEC event and the cusa metaclass record what administrators did with their rights; send audit trails off the host.

How identity and access work in Oracle Solaris

Solaris implements user and process rights management (often still called RBAC) as an alternative to the all-or-nothing superuser model. Four building blocks decide what an account can do:

• Profile shells: Commands in a rights profile only run with their extra attributes when a profile shell (for example pfbash) or pfexec interprets them. Users are not given a profile shell by default, which is a usability trap: administrators who forget it fall back to asking for broader rights.
• Name service scope: The rights databases can live locally or in LDAP. In a large estate, store rights centrally so revocation is one change, and check the search order the system uses for assigned rights.
• Qualified attributes: Solaris 11.4 lets you qualify an account so it can assume rights only on specific systems, which is the Solaris answer to "admin everywhere" accounts.
• System-wide policy as SMF properties: In 11.4 the account-policy SMF service holds login policy, password policy, umask, account locking and system-wide rights, replacing hand-edited files such as policy.conf where you enable it.

For the general model behind roles and profiles, see the Authorisation Models Guide.

Admin roles and privileged access

Root as a role

On Solaris 11.4 root is a role by default. Check it with userattr type root (the value should be role) and list who can assume it with roles <user>. Oracle documents converting root into a normal user with rolemod -K type=normal root, mainly for tools that need a direct root login or for sites that keep the traditional superuser model. Treat that change as an exception requiring sign-off: a direct root login no longer tells the audit trail which person acted. Oracle also notes that some sites disallow root as a usable account on production systems; you can remove the root role from every user (usermod -K roles= <user>) while root keeps a password for single-user maintenance.

Designing administrative roles

• Split duties: Oracle's own auditing example uses two administrators, one with the Audit Configuration profile who sets flags and one with Audit Control who activates them. Apply the same split to security policy versus operations.
• Zone administration: Use the Zone Configuration, Zone Management and Zone Migration rights profiles rather than root. Assigning any profile requires solaris.delegate.*, so keep that authorisation with a very small group.
• Authenticated rights profiles: Place sensitive authorisations in an authenticated rights profile so the user must re-enter a password before the command runs.
• Removing basic privileges: Oracle documents removing unneeded basic privileges from ordinary users, for example the ability to see other users' processes, and removing rights system-wide through SMF.
• Break glass: Keep the console route documented. If no account can assume root, recovery is single-user mode at the console, which should be reachable only through a controlled ILOM or serial path.

Feed these role holders into the same vaulting and session controls as other Unix administrators. See the Privileged Access Management Guide.

Integrations, API tokens and service accounts

Most Solaris compromises of interest do not start with a person typing a password. They start with the machine identities that let other systems manage the host.

Inventory these accounts like any other non-human identity: owner, purpose, credential type, last rotation. See the Linux Service Accounts and Keytab Management Guide, whose practices transfer directly to Solaris.

Zones and immutable zones

Non-global zones are the primary isolation boundary on Solaris. Zone processes are limited to a subset of privileges so that one zone cannot affect another or the global zone. Oracle lists privileges reserved for the global zone that cannot be added to a non-global zone, including dtrace_kernel, proc_zone, sys_config, sys_devices, sys_ip_config and sys_mount. Check a zone's set with ppriv -l from inside the zone. Every privilege you add to a zone's defaults (DTrace is the common request) widens what a compromised zone can do, so record each addition.

The MWAC policies

Immutable zones use mandatory write access control (MWAC), set with zonecfg through the file-mac-profile property. All values other than none make /var/pkg read-only inside the zone.

Immutable global zone

• Configuration: The MWAC policy is set on the global zone with zonecfg. Oracle states that no reboot is needed: the global zone becomes immutable as soon as the configuration is committed and the boot archive is updated.
• Datasets: The rpool dataset is restricted. An immutable global zone can run zones only from unrestricted datasets added with zonecfg add dataset, and children of an unrestricted dataset are also unrestricted, so keep that list short.
• Administration: The most secure way to maintain it is the Trusted Path Domain, available only on the console. After console trusted path login is configured, root cannot log in and administer the zone; an authorised user logs in on the trusted path and then assumes a role.
• Updates: Running pkg update makes the first boot read-write so the system can complete self-assembly, then it returns to immutable automatically.
• Non-global zones: Administer either by making the zone temporarily mutable from the global zone, or (more securely) by leaving it immutable and entering the Trusted Path Domain from the console or RAD.

Immutability is one of the few controls that directly defeats persistence by an attacker who has gained root, which maps to ATT&CK T1543 Create or Modify System Process. For the wider pattern of isolation layers, see the Hypervisor and Virtualisation Security Guide.

Logging and detection

• Audit administrative actions: Oracle points to event 116:AUE_PFEXEC (execve with pfexec enabled) and the cusa metaclass for roles. Its worked example sets system default flags with auditconfig -setflags lo,pf and activates them with audit -s. Read /etc/security/audit_class on your release before choosing classes.
• Get logs off the host: With strict zones logging is remote only, and in any zone a root-level attacker can tamper with local trails. Forward audit records and syslog to a collector the host administrators cannot alter.
• Watch rights changes: Alert on changes to user_attr, prof_attr and exec_attr (locally or in LDAP), on rolemod -K type=normal root, and on any new assignment of All, solaris.delegate.* or zone profiles.
• Watch immutability: A zone changing to file-mac-profile=none, an unexpected read-write boot, or a new unrestricted dataset are high-signal events.
• CVE status: The compliance guide documents monitoring CVE status and the Critical Patch Update package; track it alongside assessment results.

See the CIS Control 8 Audit Log Management Guide.

Hardening baseline

Solaris 11 installs "secure by default". The Solaris Security Policy benchmark has two profiles: Baseline, which closely matches the secure by default install, and Recommended, which is stricter and implies Baseline. Oracle states that the Solaris benchmark does not satisfy the PCI DSS, CIS or DISA STIG benchmarks for Solaris, so organisations that must evidence CIS or STIG compliance need those benchmarks too. The CIS Benchmark for Oracle Solaris is published by CIS, which provides its own assessment tooling.

1. Assess first: Install the compliance package and run an assessment against Recommended. The Compliance Assessor rights profile (which carries solaris.compliance.assess) is needed to run assessments; Compliance Reporter can only view them.
2. Tailor, do not edit: Create a tailoring from the benchmark, select alternate rule values where your policy differs, export it and package it with a package manifest so every host gets the same tailoring through IPS.
3. Schedule assessments: Enable svc:/application/security/compliance:default and set the scheduled property group (for example a weekly run at 02:00) so drift is visible without manual effort.
4. Centralise results: Use remote assessments and a common store, tagging assessments with metadata such as environment and owner.
5. Apply rights hardening: Root as a role, no direct privileges, account locking and password policy through account-policy, restrictive umask.
6. Lock down services: Disable unused SMF services, apply extended privilege policy to network services, and restrict SSH (no root login, key-based automation).
7. Make it immutable: Move application zones to fixed-configuration or strict, then the global zone, after testing patching and console trusted path access in a pilot.
8. Rollback plan: For each step keep the reverse command (for example setting a zone back to none from the global zone) and confirm the console path works before you need it.

For benchmark selection across platforms, see the CIS Benchmarks Guide and the DISA STIG Guide.

Framework mapping

Common misconfigurations

• Root turned back into a user: Often done once for an agent install and never reverted, leaving shared root passwords and anonymous privileged sessions.
• The All profile handed out: The root account's own attributes include profiles=All and auths=solaris.*; copying those to named users rebuilds superuser under another name.
• Direct privilege grants: Adding a privilege such as file_dac_read to a user instead of to a command in a profile, which Oracle explicitly describes as not secure.
• Immutable in name only: Zones on flexible-configuration where fixed-configuration would work, or long lists of unrestricted datasets under an immutable global zone.
• Benchmark mismatch: Reporting a Solaris Recommended pass as CIS or STIG compliance, which Oracle says it is not.
• Logs only on the box: Local audit trails that the same administrators can delete, so investigations cannot reconstruct who assumed root.

Practitioner checklist

• Confirm root is a role on every host and list every user who can assume it.
• Remove direct privilege assignments and move them into rights profiles tied to commands.
• Restrict solaris.delegate.*, the All profile and zone profiles to named, reviewed administrators.
• Inventory SMF service accounts, SSH automation keys, keytabs and agent accounts with owners.
• Run compliance against Recommended, build a packaged tailoring, and schedule weekly assessments.
• Add the CIS or DISA STIG benchmark where your regulators or customers require it.
• Move production zones to fixed-configuration or strict, then pilot an immutable global zone.
• Test console Trusted Path Domain access and pkg update on immutable hosts before production.
• Enable auditing of AUE_PFEXEC and role activity and forward trails off the host.
• Alert on rights database changes, MWAC policy changes and new unrestricted datasets.

Standards and references

• Oracle: Oracle Solaris 11.4 Compliance Guide
• Oracle: Securing Users and Processes in Oracle Solaris 11.4
• Oracle: Creating and Using Oracle Solaris Zones, Setting the MWAC Security Policy
• Oracle: Maintaining an Immutable Global Zone
• Oracle: Privileges in a Non-Global Zone
• Oracle: Managing Secure Shell Access in Oracle Solaris 11.4
• NIST: SP 800-53 Rev. 5
• MITRE ATT&CK: Create or Modify System Process

Related NHI Mgmt Group resources: Privileged Access Management Guide · CIS Benchmarks Guide · Linux Service Accounts and Keytab Management Guide · Configuration Drift and Baseline Enforcement Guide · Oracle WebLogic Server Hardening Guide