Solaris Verified Boot Introduction

Verified Boot here refers to verification of object modules before execution using digial signatures. If enabled, Solaris Verified Boot checks the factory-signed signature in a kernel module before loading and executing the module. This is to detect accidental or malicious modification of a module. The action taken is configurable and, when enabled, will either print a warning message and continue loading and executing the module or will fail and not load and execute the module.

Threats

Solaris protects against the loading of rogue kernel modules. Verified Boot increases the security and robustness of Solaris by verifying kernel modules before execution. Examples of these kinds of threats include:

• Corrupted (accidently modified) kernel modules
• Insertion or substitution of malicious programs masquerading as legitimate kernel modules (Trojans, viruses, spy-ware, root-kits). These malicious programs can relay information to a third-party or alter the behavior of Solaris
• Installation of unauthorized third-party kernel modules. Although usually non-malicious, they may be unauthorized and not vetted for security threats or violate site change control policies

Verified Boot Functionality

Before Verified Boot	After Verified Boot
(Disclaimer: this result has not yet been verified by an independent lab.)

Solaris Verified Boot checks kernel modules before execution and reports if the module is modified. Optionally on failures, the module is not loaded. For Solaris, Solaris Verified Boot will verify kernel modules before execution, beginning with the initial bootstrap SPARC “bootblk” sectors and initial "unix" module. Both of these are verified by SPARC OpenBoot (because Solaris is not running yet). The Solaris kernel loader (krtld) then takes over and verifies the main (generic) "genunix" module and all subsequent modules loaded by the Solaris kernel.

The policy to use on failures is configurable with three policy settings: none, warning, and enforce. The default policy is none (that is, Verified Boot is disabled).

• None is the default behavior—no verification before execution.
• Warning logs failures to the console and system log. The module is loaded and executed, however.
• Enforce logs and does not load the module (the module fails to load).

Verified Boot has two policies, boot_policy and module_policy:

• boot_policy is used in early boot and controls checking of the bootblk and initial "unix" and "genunix" modules.
• module_policy is used after module genunix is loaded controls checking of subsequent kernel modules (such as from modload(1M)).

The policy settings are stored in Oracle ILOM, which manages the hardware platform. The policy settings are purposely stored outside of the booted Solaris environment because we don't trust Solaris (including root or Administrator) to not tamper with these settings.

Chain of Trust

Solaris Verified Boot operates in a "chain of trust" fashion. An verified software is not used to verify other code or even itself until it's verified. Only after verification may software verify other software. Consider this simple diagram showing Solaris boot flow:

OpenBoot→ bootblock→ /platform/.../unix→ genunix→ . . .→ sha2

The chain of trust starts with OpenBoot firmware. The firmware is factory-installed or customer-installed from factory-signed packages. OpenBoot verifies the SPARC boot block (bootblk) sectors and the initial Solaris /platform/.../unix module and starts execution in the bootblk. Bootblk executes the initial Solaris module, unix. From there, the Solaris kernel loader, part of module unix, takes over. Krtld verifies genunix (Generic UNIX) and loads it and verifies all subsequent kernel modules. SHA-256 functionality, required to verify kernel modules, is contained in a yet-to-be-loaded module, sha2. Until sha2 is loaded, Solaris uses temporary, unoptimized "standalone" code to calculate SHA-256 digests as part of verifying the RSA-2048 signature.

Solaris Security Ecosystem

Solaris Verified Boot is not a standalone Security solution independent of everything else. By interacting with other Solaris security solutions, it makes for a more robust, secure environment:

• Solaris SPARC firmware is signed using DSA-2048. Only signed firmware can be installed on SPARC platforms.
• Secure Auto-Install (AI) and signed IPS packages (pkgsign(1)) help ensure the software you're installing is legitimate and has not been corrupted.
• Immutable Global Zones implements a read-only root filesystem for the Global Zone and Kernel Zones.
• Packaging Solaris packages are factory-signed at Oracle. Third-party packages may be signed by the software vendor.
• Boot Environments Multiple Boot Environments (BEs) allow one of several instances of Solaris to be booted. When the platform is configured with BEs, switching between BEs does not allow one to bypass the Verified Boot policy. If the system is configured to perform a fully-verified boot ("enforce"), but the BE being booted contains unsigned or corrupt kernel modules, the system administrator may need to loosen the boot policy (set it to "warning").
• TPM Solaris Verified Boot has no impact on the Trusted Platform Module (TPM) chip or TPM software (TrouSerS). However, the TPM still serves complementary functions such as providing a secure keystore or taking measurements of firmware executibles.

Together, these security solutions provide an end-to-end solution to help secure against tampering, from firmware to operating system software.

Elfsign Keys

Solaris executable object, including kernel modules, are factory-signed with elfsign(1) by Oracle Solaris Release Engineering with a RSA-2048 public/private key pair. The private key is not distributed by Oracle. The public key is distributed in /etc/certs/ORCLS11SE.

The current public key cert for Solaris 11 Updates is in /etc/certs/ORCLS11SE. This code signing cert is issued by Verisign to Oracle and object is signed and verified with the elfsign(1) command.

Solaris Verified Boot cannot trust Solaris to store the keys in the filesystem (as a key in /etc/certs/ can be modified or a key can be added by any privileged user), so the key must be stored outside in the pre-boot environment. For SPARC, for example, this will be in Oracle ILOM.

The elfsign public key certificate is represented as a X.509 text file. For Solaris 11 Update, elfsign uses rsa_sha1 (rsa-2048 of sha1). Other elfsign public keys may be present for:

• Third-party software modules (usually for hardware drivers). These can be signed with a code-signing certificate issued by Verisign or some other CA, or can be signed with a self-issued certificate.
• Customer-signed software modules (including self-issued certificates) to sign unsigned third-party modules (that is, software not signed by the software author). This includes compiled open source modules and hardware-specific modules.
• Oracle (factory) signed software. All Solaris kernel modules are signed with elfsign before release to customers. For external Solaris 11 (or S11 update), this can be verified with "elfsign verify" using the public key cert in file /etc/certs/ORCLS11SE. The following command displays the contents of a X.509 certificate file:

  openssl x509 -noout -text -in /etc/certs/ORCLS11SE

For more information on elfsign see my earlier article"Elfsign Object Signing on Solaris".

Setting Verified Boot Policy Values in Oracle ILOM

Verified Boot settings are maintained by Oracle ILOM. They can be modified or viewed by the ILOM UI, spsh, or the BUI (web) interface. From the ILOM UI, you can configure and display policy settings, pre-installed system certificates, and custom (user-provided) certificates. For this purpose the verified_boot target is /HOSTx/verified_boot (where "HOSTx" is "HOST" for T5 systems and other systems with only one physical domain , or HOST0, HOST1, HOST2, ... for systems with multiple physical domains). Changes in the policy settings or certificates in Oracle ILOM are not available to the Solaris host immediately, but are not used until the next reboot of the guest to OpenBoot (a complete host reboot/shutdown is not needed).

ILOM provides boot_policy and module_policy properties to set Verified Boot policies. The following example sets boot_policy to enforce and module_policy to warning:

-> set /HOST1/verified_boot/ boot_policy=warning Set 'boot_policy' to 'warning' -> set /HOST1/verified_boot/ module_policy=enforce Set 'module_policy' to 'enforce' -> show /HOST1/verified_boot/ /HOST1/verified_boot Targets: system_certs user_certs Properties: boot_policy = warning module_policy = enforce Commands: cd show

ILOM Certificate Management

If you only use Oracle Solaris kernel modules and drivers, no certificate management is necessary. That's because the Oracle Solaris certificate used by elfsign, /etc/certs/ORCLS11SE, is built-in ILOM and Solaris Verified Boot. However, if you use third-party modules or drivers, you need to add the public key X.509 certificate (cert). This is not needed for third-party libraries and executible files as Verified Boot only checks Solaris kernel modules. The certificate may be issued by a Certificate Authority (CA) or be self-signed. The chain of trust is established by installing the cert in ILOM.

ILOM allows adding and viewing of both system-provided or "built-in" certs (target system_certs) and user provided certs (target user_certs). Initially under /HOSTx/verified_boot/system_certs is a single target, /HOSTx/verified_boot/system_certs/1, that corresponds to the pre-installed certificate file for Solaris. Updates to ILOM may add more numerically identified system certificate files to support newer versions of Solaris. The system-provided cert is represented by the ILOM target /HOSTx/verified_boot/system_certs/1. Pre-installed certificates for future OS releases will populate target /HOSTx/verified_boot/system_certs/2 and beyond. User-installed certificates are preserved across firmware updates. Valid certificate files are plain ASCII text in X.509 format.

The following example displays the system-provided cert:

-> show /HOST1/verified_boot/system_certs/1 /HOST1/verified_boot/system_certs/1 Targets: Properties: issuer = /C=US/O=Oracle Corporation/OU=VeriSign Trust Network/OU=Class 2 Managed PKI Individual Subscriber CA/CN=Object Signing CA subject = /O=Oracle Corporation/OU=Corporate Object Signing/OU=Solaris Signed Execution/CN=Solaris 11 valid_from = Mar 1 00:00:00 2012 GMT valid_until = Mar 1 23:59:59 2015 GMT Commands: cd show

ILOM User-managed Certificates

The /HOSTx/verified_boot/user_certs/{ID} UI supports load and reset of up to 5 custom certificate files for each domain:

• The load command loads the certificate from the user-provided URL.
• The reset command removes removes the specified user certificate.
• The show command displays a certificate.

Below are examples for show, load, and reset of the certificate file:

-> set /HOST1/verified_boot/user_certs/1 load_uri=http://someserver.com/ORCLS11SE Load successful. -> show /HOST1/verified_boot/user_certs/3 /HOST1/verified_boot/user_certs/3 Targets: Properties: clear_action = (Cannot show property) issuer = /O=Dog Wash Software/OU=Release Engineering/CN=dogwashsoftware.com load_uri = (Cannot show property) subject = /O=Dog Wash Software/OU=Release Engineering/CN=dogwashsoftware.com valid_from = Oct 4 21:08:00 2013 GMT valid_until = Sep 27 21:08:00 2023 GMT Commands: cd load reset set show -> reset /HOST1/verified_boot/user_certs/2 Are you sure you want to reset /HOST1/verified_boot/user_certs/2 (y/n)? y Performing reset on /HOST1/verified_boot/user_certs/2 -> show /HOST1/verified_boot/user_certs/2 issuer /HOST1/verified_boot/user_certs/2 Properties: clear_action = (Cannot show property) issuer = (none) <--- not installed load_uri = (Cannot show property) subject = (none) valid_from = (none) valid_until = (none) Commands: cd load reset show

Here's an example of loading a certificate by pasting the contents into the ILOM console. Terminate the console input with a ctrl-z.

-> set /HOST1/verified_boot/user_certs/1 load_uri=console Begin cut-and-paste below. Enter [ctrl-z] to save and process information. Enter [ctrl-c] to exit and discard changes -----BEGIN CERTIFICATE----- MIIDUTCCAjugAwIBAgIEDQbwDTALBgkqhkiG9w0BAQswWzEeMBwGA1UEChMVQ2Fu aW5lIFNvZnR3YXJlIFdvcmtzMRcwFQYDVQQLEw5TZWxmLXNpZ25lZCBDQTEgMB4G A1UEAxMXY2FuaW5lc29mdHdhcmV3b3Jrcy5jb20wHhcNMTMwODA3MjExOTAwWhcN MTgwODA2MjExOTAwWjBbMR4wHAYDVQQKExVDYW5pbmUgU29mdHdhcmUgV29ya3Mx FzAVBgNVBAsTDlNlbGYtc2lnbmVkIENBMSAwHgYDVQQDExdjYW5pbmVzb2Z0d2Fy ZXdvcmtzLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMO+qyzu USOtEshf5H/9cjlu4xZDu7hJuJK8fB8FWrQIRlxSXBg/S/cqLlLXG5yoG/1mvmjN E5u9C4thNaKKvAkKDTVBDN3JWpY7fgdYvReFDe0tRZpYAHLw/65A9y5JfOw3hfGo 7560yE2lxPUJGbh9WgBpoPtjbAdU7+fwlmPOEWfiydoAlg72+mWJxBVUjAOsmnVS xgz5w6JNU7pGWwefZOx777Onbb5gSLaLjRdkAcChkZxcAqbcDYhAqXsumKw6b8Cr 941Ba2RzOj+ajZHa3sYN6HTUbQqctIpqgk6/VwdrvXKRkjf9OEE6ErACOkhLMvBB eniuL1s4OINU+F8CAwEAAaMhMB8wHQYDVR0OBBYEFIoh5OiDFE5ZoeWWFKFXkN/5 vv6oMAsGCSqGSIb3DQEBCwOCAQEAqd2nY0O9CC8TD+Wrqa7oGMmkOsndWYpLPxAc PwdSzUcDeHMV9icYEKGkm+jsz5jhwN4ZnE9hKZIk5vsRuxCLH2sE06fNNv2GQEfT oOktmsE7rCyChWbu7woYsP+qFAEhOGNLnLmyMUyFjGB/4HdWP5bYRBQPO9ewNq2j Ta9iRdaVz00Ptbwwos2mHf5O0HBZz81WghsntjkutfNr2+pi25KR8joBto4rqXQ1 Z2Pte3eO7LVcdTFq0ug8x3VUZzsZNCE0Wl6x6RrO/OogvQgiiSG/hl00zYhX6Ssr BhM8Cx1XyAD9U9OTAF/MkMoRfdYV5ZLzNiJCtLbdIHLyyZs4og== -----END CERTIFICATE----- ^Z Load successful.

ILOM Web Interface

The web interface also supports setting of the Verified Boot policy variables and and management of Certificate files, providing the same functionality as the CLI. Just navigate to the "Verified Boot" link under the "Host Management" navigation menu.

ILOM Security Considerations

The SPARC M5/M4/T5 pre-boot environment stores Verified Boot settings in ILOM. Anyone with ILOM spsh shell access can modify these settings. One can reach the ILOM shell with ssh to the ILOM console. If the password can be easily guessed, these settings can be modified. ILOM console access should be isolated to a separate management network that's separate from the general network with restricted access to ILOM administrators. If feasible, ILOM access can be restricted to the ILOM serial port with no network access.

In order to use Verified Boot, the "use-nvram" setting must be set to false in OpenBoot. This prevents OpenBoot from being modified to disable Verified Boot functionality. The default value is false and can be viewed in Solaris by typing:

$ /usr/sbin/eeprom/eeprom use-nvramrc? use-nvramrc?=false

If set to true it can be modified in OpenBoot. For example,

{900} ok printenv use-nvramrc? use-nvramrc? = true {900} ok setenv use-nvramrc? false use-nvramrc? = false {900} ok printenv use-nvramrc? use-nvramrc? = false

Implementation

Verified Boot verifies the elfsign signature contained in a kernel module. These signatures have been present since Solaris 10. For Solaris 11.2 the signature format is a RSA-2048 signature of a SHA-256 or SHA-1 digest.

To verify, the Solaris krtld loader extracts the signature from the kernel module and calculates the ELF file digest (which excludes the signature, among other things). The expected digest is calculated from the signature and public key as follows: signature⁶⁵⁵³⁷ % public-key.

If the expected digest (excluding PKCS#1 padding) matches the actual digest just calculated, the signature is OK. This process is repeated for every cert until a match is found. Here's a diagram of the process:

Performance

Verified Boot has little performance impact. That's because loading kernel modules are mostly I/O bound, most systems only load ~200-300 modules during boot, and the additional time for signature verification is negligible. The overall boot time increases by ~2.5 seconds on a T5.

Availability

Solaris Verified Boot is initially available with Solaris 11.2 for SPARC T5/M5/M6 hardware platforms for host domains. It requires Firmware FW 9.1.0 or better. Verified Boot is supported for the host domain in the Global Zone. Non-global, non-kernel zones do not have their own copy of the Solaris kernel and do not load kernel modules.

Verified Boot is not supported initially for Solaris on X86, T4 or older SPARC platforms, LDoms guest domains, or Kernel Zones. We plan to support more hardware and software platforms in the future, but there is no commitment to do so.

More Information

Here's some sources for further information. Most of these documents are available at docs.oracle.com

• Oracle Solaris Administration: Security Services
• Securing Systems and Attached Devices in Oracle Solaris 11.2
• Booting and Shutting Down Oracle Solaris 11.2
• "Configuring SPARC Verified Boot Properties", Oracle ILOM< Documentation Collection for FW 3.2.x
• SPARC M5-32 and SPARC M6-32 Servers Administration Guide,"Configuring Domain Components: Verified Boot Commands". Note that this hardware document is being updated for the Solaris 11.2 release, so check back later for Verified Boot documentation.
• "Elfsign Signing on Solaris", https://blogs.oracle.com/DanX/entry/elfsign_object_signing_on_solaris"
• elfsign(1) man page. The elfsign man page covers details of signing ELF format files, including Solaris kernel modules. The man page has one minor error—it mentions directory /etc/crypto/certs/. This is wrong—elfsign actually searches directory /etc/certs/ (/etc/crypto/certs/ is reserved for a handful of crypto libraries). For more information see bug 18092519.