Go to main content

Securing Systems and Attached Devices in Oracle® Solaris 11.3

Exit Print View

Updated: April 2019
 
 

Using Verified Boot

Malicious programs can pass information to third parties as well as alter the behavior of Oracle Solaris. Although third-party modules are typically non-malicious, they might violate policies that control site changes. Therefore, the system also needs protection from unauthorized installation of these modules.

    Verified boot in Oracle Solaris secures a system's boot process. You must enable this feature, which protects the system from threats such as the following:

  • Corruption of kernel modules

  • Insertion or substitution of malicious programs that masquerade as legitimate kernel modules, such as Trojan viruses, spyware, and rootkits

  • Installation of unauthorized third-party kernel modules

A firmware upgrade may be required to use verified boot. For information, see Firmware Upgrade for Verified Boot.

SPARC: Firmware Upgrade for Verified Boot

SPARC firmware is installed at the factory. For some SPARC platforms, an expanded bootblock is incompatible with verified boot functionality. If the verified boot level is set to enforce, the system will not boot, and messages similar to the following display:

WARNING: Total size of bootblk fcode greater than expected
FATAL: Bootblk fcode extraction failed
Missing cmn-xxx[ caused cmn-append with 'verified boot policy = 
enforce, halting boot' argument to fail

If the verified boot level is set to warning, messages similar the following display:

WARNING: Bootblk fcode extraction failed
WARNING: Signature verification of boot-archive bootblk failed

    Update the firmware on SPARC systems where verified boot is enabled as follows:

  • T5-Series, M5-Series, and M6-Series – Upgrade to firmware 9.6.5 or later.

  • T7-Series and M7-Series – Upgrade to firmware 9.7.1 or later.

  • Fujitsu M10 – Upgrade to XCP 2320 or later.

To update firmware, see the fwupdate (1M) man page.

Verified Boot and ELF Signatures

In Oracle Solaris, boot verification is performed by means of elfsign signatures or keys. At the factory, Oracle Solaris kernel modules are signed with these keys. Because of their file format, these modules are also called ELF objects. The signature is created by using the SHA-256 checksums of selected ELF records in an object file. The SHA-256 checksums are signed with a RSA-2048 private and public key pair. The public key is distributed from the /etc/certs/elfsign directory while the private key is not distributed.

All keys are stored in the system's pre-boot environment, which is the software or firmware that runs prior to the booting of Oracle Solaris. The firmware loads and boots platform/.../unix.

    The pre-boot environment differs for each category of SPARC systems, as follows:

  • SPARC systems with verified boot support in their Oracle Integrated Lights Out Manager (ILOM) – Keys and configuration settings are stored in ILOM.

    Because Oracle ILOM is outside the operating system's file system, verified boot configuration is protected from tampering by users of the operating system, including those with administrator (root) privileges. Thus, verified boot in this category of systems is more secure.

    You must ensure that access to ILOM is secure to prevent unauthorized changes to the verified boot configuration. For more information about securing ILOM, refer to the documentation at System Management and Diagnostics Documentation (http://www.oracle.com/goto/ilom/docs).

  • SPARC M5-Series, SPARC M6-Series, and SPARC T5-Series – Configuration settings are stored in the system's ILOM. The SPARC firmware sends the configuration information to Oracle Solaris.

  • Fujitsu SPARC M12 and Fujitsu M10 systems – Configuration settings are stored in the system's XSCF. The Fujitsu SPARC M12 and Fujitsu M10 XSCF firmware send the configuration information, such as policies for verified boot and enabling certificates, to Oracle Solaris. OpenBoot (OBP) reads this configuration information before booting the Oracle Solaris system.

    All XCP firmware on Fujitsu SPARC M12 systems supports verified boot. For more information about configuring verified boot, refer to the following guides:

    • Fujitsu SPARC M12 and M10/SPARC M10 System Operation and Administration Guide

    • Fujitsu M10/SPARC M10 Systems Product Notes – For the XCP firmware version that supports verified boot on Fujitsu M10 systems

Verification Sequence During System Boot

Verified boot automates the verification of the elfsign signatures of Oracle Solaris kernel modules. With verified boot, the administrator can create a verifiable chain of trust in the boot process beginning from system reset through the completion of the boot process.

During a system boot, each block of code that is started in the boot process verifies the next block that needs to be loaded. The sequence of verification and loading continues until the last kernel module is loaded.

When a power cycle is subsequently performed on the system, a new sequence of verification begins. The administrator can also configure verified boot to take the appropriate action in the event of verification failure.

The following illustrates the boot flow of Oracle Solaris on a SPARC system:

Firmware -> Bootblock -> /platform/.../unix -> genunix -> other kernel modules

The firmware verifies and then loads the Oracle Solaris /platform/.../unix module, the initial Oracle Solaris module. In turn, the Oracle Solaris kernel runtime loader krtld, which is part of the unix module, verifies and loads the generic UNIX (genunix) module and subsequent modules.

Policy for Verified Boot

In this release, verified boot has only one policy property: boot_policy. The boot_policy property manages verified boot behavior when loading kernel modules during the boot process.

On legacy SPARC systems and x86 systems, the boot_policy property is defined in the /etc/system file. On SPARC systems with Oracle ILOM verified boot support, boot_policy is a property of ILOM in /HOSTn/verified_boot, where n is the physical domain (PDomain) number.

    The boot_policy property can be configured with one of the following values:

  • none – No boot verification is performed. This is the default.

  • warning – The elfsign signature of each kernel module is verified before the module is loaded. If verification fails on a module, the module is still loaded. The discrepancies are recorded on the system console or, if available, in the system log. By default, the log is /var/adm/messages.

  • enforce – The elfsign signature of each kernel module is verified before the module is loaded. If verification fails on a module, the module is not loaded. The discrepancies are recorded on the system console or, if available, in the system log. By default, the log is /var/adm/messages.

Note -  By default, any logical domain that was created on an Oracle VM Server for SPARC version earlier than 3.4 sets boot-policy=warning. If the kernel module is unsigned or corrupted, this setting results in warning messages being issued while the domain boots after an update to the server.

Public Key Certificates for Verified Boot

    Verified boot uses public key certificates from the following sources:

  • /etc/certs/elfsign directory

    If your image contains ELF objects that are signed by a third-party vendor, you must add the vendor's certificate to this directory.

  • Kernel Zones, as added by the zoneadm command

  • Oracle ILOM for SPARC

    Oracle ILOM for SPARC that supports verified boot provides a preinstalled verified boot certificate file, /etc/certs/elfsign/ORCLS11SE. The certificate contains the RSA public key that is used to verify the elfsign signatures in ELF objects that Oracle Solaris signed. All certificates are loaded and managed on each individual PDomain.

  • ILOM syntax varies according to hardware platform and firmware version. To configure certificates using Oracle ILOM, review Configuring SPARC Verified Boot Properties in Oracle® ILOM Administrator's Guide for Configuration and Maintenance Firmware Release 3.2.x.

You can also manually verify a kernel module's signature. Manual verification can be useful during diagnostics to confirm that the signature is present and correct.

Example 1  Manually Verifying a Kernel Module's Signature

Use the elfsign verify -v kernel_module command syntax as follows:

$ elfsign verify -v /kernel/misc/sparcv9/bignum
elfsign: verification of /kernel/misc/sparcv9/bignum passed.
Elfsign signature format: rsa_sha256
Signer: O=Oracle Corporation, OU=Corporate Object Signing, OU=Solaris Signed Execution, CN=Solaris 11
Copyright © 2002, 2019, Oracle and/or its affiliates. All rights reserved. 
Previous
Next