HP HP-UXlisting Administrator's Guide

HP-UX Whitelisting A.01.00 Administrator Guide

HP-UX 11iv3

HP Part Number: 5992-5210 Published: September 2010 Edition: 1

Confidential computersoftware. Valid license from HP required for possession, use or copying. Consistent with FAR 12.211 and 12.212, Commercial

Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under

vendor's standardcommercial license.The informationcontained hereinis subject to change without notice. The only warranties forHP products

and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as

constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein.

Itanium™, Xeon™, and Pentium™ are trademarks of Intel Corporation in the U.S. and other countries. UNIX® is a registered trademark of The

Open Group.

1 Security features..............................................................................................................9

1.1 File access policies.............................................................................................................................9

1.1.1 File lock access controls.............................................................................................................9

1.1.2 Identity-based access controls.................................................................................................10

1.2 Capabilities......................................................................................................................................10

1.2.1 mem...........................................................................................................................................10

1.2.2 wmd...........................................................................................................................................10

1.2.3 dlkm........................................................................................................................................10

1.2.4 api...........................................................................................................................................11

2 Product overview..........................................................................................................13

2.1 WLI architecture..............................................................................................................................13

2.1.1 Commands..............................................................................................................................14

2.1.1.1 Application API...............................................................................................................14

2.1.1.2 Applications....................................................................................................................15

2.1.1.3 Stackable file system module..........................................................................................15

2.1.1.4 Policy enforcement manager...........................................................................................15

2.1.1.5 File systems.....................................................................................................................16

2.2 WLI database...................................................................................................................................16

2.3 WLI metadata files..........................................................................................................................16

2.3.1 .$WLI_FSPARMS$..................................................................................................................17

2.3.2 .$WLI_POLICY$.....................................................................................................................17

2.3.3 .$WLI_SIGNATURE$..............................................................................................................17

3 Key usage.....................................................................................................................19

3.1 Generating keys...............................................................................................................................19

3.2 User keys.........................................................................................................................................20

3.3 Administrator keys..........................................................................................................................20

4 Installing, removing, and upgrading..........................................................................21

4.1 Installation requirements................................................................................................................21

4.2 Installing WLI..................................................................................................................................21

4.3 Removing WLI................................................................................................................................22

4.4 Upgrading WLI...............................................................................................................................23

5 Configuring...................................................................................................................25

5.1 Authorizing the recovery key..........................................................................................................25

5.2 Authorizing administrator keys......................................................................................................25

5.3 Signing DLKMs...............................................................................................................................26

5.4 Backing up the WLI database..........................................................................................................26

5.5 Rebooting to restricted mode............................................................................................................27

6 Enhancing security with WLI.......................................................................................29

6.1 Signing an executable binary..........................................................................................................29

6.2 Creating a FLAC policy...................................................................................................................29

6.3 Creating an IBAC policy..................................................................................................................30

6.4 Removing a file access policy..........................................................................................................30

Table of Contents 3

6.5 Enabling DLKMs to load during boot.............................................................................................30

6.6 Loading unsigned DLKMs..............................................................................................................31

7 Backup and restore considerations............................................................................33

7.1 Overview.........................................................................................................................................33

7.2 WLI database files...........................................................................................................................33

7.2.1 Write protected........................................................................................................................34

7.2.2 Read/write protected files.......................................................................................................34

7.2.3 Recommendations...................................................................................................................34

7.3 Policy protected and metadata files................................................................................................34

7.3.1 FLAC policies..........................................................................................................................35

7.3.2 IBAC policies...........................................................................................................................35

7.3.3 Metadata files..........................................................................................................................35

7.3.4 Recommendations...................................................................................................................35

8 HP Serviceguard considerations.................................................................................37

8.1 Overview.........................................................................................................................................37

8.2 Administration................................................................................................................................37

8.2.1 WLI database...........................................................................................................................37

8.2.2 Policy protected files...............................................................................................................38

9 Troubleshooting and known issues.............................................................................39

9.1 Software distributor issues..............................................................................................................39

9.2 WLI reinstallation............................................................................................................................39

9.3 Lost WLI administrator key or passphrase ....................................................................................39

9.4 WLI database corruption.................................................................................................................39

10 Support and other resources.....................................................................................41

10.1 Contacting HP...............................................................................................................................41

10.1.1 Before you contact HP...........................................................................................................41

10.1.2 HP contact information.........................................................................................................41

10.1.3 Subscription service...............................................................................................................41

10.1.4 Documentation feedback.......................................................................................................41

10.2 Related information.......................................................................................................................41

10.3 Typographic conventions..............................................................................................................42

A libwliapi example.................................................................................................45

A.1 Instructions.....................................................................................................................................45

A.2 makefile.......................................................................................................................................45

A.3 FLAC add and delete program......................................................................................................46

A.4 IBAC add and delete program.......................................................................................................46

B Administration examples.............................................................................................49

C Quick setup examples.................................................................................................53

C.1 Installing WLI.................................................................................................................................53

C.2 Configuring WLI............................................................................................................................53

C.2.1 Authorizing an administrator key..........................................................................................53

C.2.2 Authorizing a user key...........................................................................................................53

C.3 FLAC policies..................................................................................................................................54

4 Table of Contents

C.3.1 Creating a FLAC policy..........................................................................................................54

C.3.2 Enabling a FLAC policy..........................................................................................................54

C.3.3 Testing a FLAC policy............................................................................................................54

C.3.4 Disabling a FLAC policy........................................................................................................55

C.3.5 Removing a FLAC policy.......................................................................................................55

C.4 IBAC policies..................................................................................................................................55

C.4.1 Creating an IBAC policy.........................................................................................................55

C.4.2 Enabling an IBAC policy........................................................................................................55

C.4.3 Testing an IBAC policy...........................................................................................................55

C.4.4 Disabling an IBAC policy.......................................................................................................56

C.4.5 Removing an IBAC policy......................................................................................................56

Glossary............................................................................................................................57

Index.................................................................................................................................59

Table of Contents 5

List of Figures

2-1 WLI architecture............................................................................................................................14

6 List of Figures

List of Examples

B-1 Execute manual WLI configuration..............................................................................................49

B-2 Backing up policy protected files..................................................................................................49

B-3 Restoring policy protected files.....................................................................................................50

B-4 Backup and restore without wliwrap..........................................................................................51

1 Security features

HP-UX Whitelisting (WLI) provides security features complementary to discretionary access controls, sometimes referred to as DAC restrictions. DAC restrictions are based on defined users and groups, and the ownership and permission bits associated with every type of file. DAC restrictions are generated through user commands and enforced within the kernel domain on the processes comprising every application.

WLI is a cryptographic key-based product. Whitelisting security features are based on RSA key ownership andencryption technology. WLI security features are imposed through RSA signatures and enforced through signature verification. Therefore, regular files and directories may be protected from access by any user including superuser.

Whitelisting security features are divided into the following categories: File access policies WLI users can restrict access to regular and directory files by

Capabilities When WLI is installed, certain system resources known to be

generating policies that are enforced within the kernel domain. WLI then grants access only to applications meeting the policy requirements for the protected files.

security risks are prevented from access by all applications. A user owning an administrator key can authorize a WLI-signed application to access these resources. Other users, as well as the owner of the administrator key, can then execute the signed application and access the protected resource. In WLI terminology, a capability is granted to an application to permit access to a protected resource.

1.1 File access policies

WLI file access policies are generated with the wlipolicy command and enforced by WLI kernel components when access is requested by application threads. Enforcement of these policies does not include alteration of ownership, permissions bits, and other file status information stored on physical media. Enforcement is accomplished by cryptographic verification of application and policy signatures stored in metadata, followed by access denial to threads that do not meet policy rules.

User ID and group ID values are not factors within WLI policy enforcement. However, the traditional UNIX ownership and permission bit restrictions are not avoided by files with WLI file access policies. After WLI allows access to a policy-restricted file, the executing thread continues into file-system-specific processing as if WLI is not installed.

1.1.1 File lock access controls

This policy type is abbreviated as FLAC in WLI manpages and other literature. A FLAC policy assigned to a regular file prevents it from being modified, deleted, or renamed within the parent directory. A FLAC policy permits read access if allowed by file permission bits.

A FLAC policy assigned to a directory prevents its content from changing; files cannot be added to or deleted from the directory. A FLAC policy on a directory also locks all its files against modification or renaming. Files in subdirectories of a FLAC-protected directory are not affected.

The user ID or effective user ID of a process is not a factor for enforcement of this policy type. Even root or the file owner may not override a FLAC policy. A FLAC policy does not replace file permission bit restrictions. The policy is enforced in addition to permission bit restrictions. Read and execute permission for a FLAC protected file is controlled entirely by its permission bits.

1.1 File access policies 9

A FLAC policy prevents modification of file status information such as modification time, permission bits, owner ID, and group ID stored within the file inode.

1.1.2 Identity-based access controls

Abbreviated as IBAC, this policy type denies access to a designated file or directory for all executables except those specifically authorized. File or directory access is normally granted to an executing binary if all access restrictions are met. In addition to traditional UNIX restrictions, an IBAC policy identifies a specific executable binary that, once authenticated, is permitted to access the protected file. A single file can have multiple IBAC policies, each one identifying a particular executable.

An IBAC policy prevents unauthorized executables from opening a file. An executable specified in an IBAC policy is sometimes referred to as an authorized executable for the IBAC-protected file. If access to an IBAC protected file is permitted by WLI, then read, write, and execute permissions are determined by the file permission bits and effective userid. Other restrictions imposed outside of WLI, such as ACLs, are not be affected by WLI.

The user ID or effective user ID of a process is not directly involved in the enforcement of this policy type as well. A binary executable must have a valid WLI signature for it to be included in an IBAC policy. When an IBAC protected file is opened, the signature on the binary executing the open() is verified through the corresponding public key.

1.2 Capabilities

The WLI A.01.00 release provides the following capabilities corresponding to system operations that are protected when WLI security mode is restricted. Capabilities may be granted to binary executables on a permanent basis using wlisign, or only for a single execution with wliwrap.

1.2.1 mem

WLI does not allow read or write operations on the memory image files /dev/mem and /dev/ kmem unless mem capability is granted to the binary executable attempting the open(). Some

commands like adb open the memory image files to query and update kernel memory. Because these are device special files, WLI file access policies cannot be assigned to them.

If mem capability is granted to an executing process that is attempting to open one of the memory image files, the open() is still subject to failure from traditional open() restrictions such as those imposed by file permission bits.

1.2.2 wmd

WLI does not allow its metadata to be created or written to unless wmd capability is granted to the executable requesting access. The wmd capability also allows read access on metadata files with WLI read protection. These restrictions are enforced whetherthe metadata is stored in VxFS name streams or protected metadata files. For more information about WLI metadata files, see

Section 2.3 (page 16). This capability is useful for backup and restore commands like tar.

1.2.3 dlkm

WLI permits the system to load a DLKM if the DLKM has been signed with wlisign using an authorized key. The signature on the DLKM is not required to include dlkm capability. The authorized key used for the signing also does not require dlkm capability.

Unsigned DLKMs can also be loaded. If the key authorizing wliwrap execution is granted dlkm capability, the wliwrap command grants dlkm capability to its child process. The child process can be an executing instance of kcmodule. The command file /usr/sbin/kcmodule must also be signed to be recognized as an authorized executable. The signature on /usr/sbin/ kcmodule is not required to include dlkm capability.

10 Security features

This capability is intended to alleviate a security issue associated with dynamic loading. The user must have root authority to dynamically load, and a WLI administrator key must grant dlkm capability directly or through another authorized key.

1.2.4 api

WLI permits an application to execute functions contained within the shared object library /opt/ wli/lib/libwliapi.so by granting api capability. This library provides functions to

programmatically create, delete, and update policies described in Section 1.1 (page 9). The key signing the executable that invokes libwliapi.so functions must be granted api capability through wlicert. The executable is not required to have api capability.

The services provided by libwliapi are also provided by the wlipolicy command to users holding an authorized key. For an implementation example using libwliapi, see “libwliapi

example” (page 45).

1.2 Capabilities 11

2 Product overview

WLI is a security enhancement product that relies on RSA keys and cryptographic algorithms to restrict access to regular files, directories, and certain protected resources. WLI is complementary to the traditional access restrictions imposed by file ownership and permission bits. An executable permitted by WLI to access a file does not bypass permission bit checks, ACLs, or other security mechanisms.

For more detail on WLI commands and files, see the manpages installed with WLI. For a complete list of manpages and more technical information, see wli(5).

In discussionsinvolving RSA, “key” is synonymous with “private key” throughout this document, because a private key holds all key information and the public key is merely a subset.

IMPORTANT: WLI requires OE B.11.31.0909 or later.

For more information, see Section 4.2 (page 21).

IMPORTANT: WLI is supportedon VxFS file systems at revision 4.1 or laterand on other HP-UX

11iv3 non-VxFS file systems such as HFS.

WLI file access policy enforcement is supported only for regular files and directories residing on HFS, VxFS, and NFS file systems. Some applications access physical storage directly, bypassing the supported file systems. Examples are Oracle ASM and Veritas CFS.

2.1 WLI architecture

For an illustration of WLI architecture, see Figure 2-1 (page 14). WLI commands restrict access to designated files by generating access policies. Some system resources are also restricted. WLI kernel software enforces access restrictions by examining policy information in real time during access requests on files.

2.1 WLI architecture 13

Figure 2-1 WLI architecture

2.1.1 Commands

WLI commandsare described in detail throughthe HP-UX manpage facilityon installed platforms, and are not reproduced here. The following briefly describes these commands:

wlipolicy

wlisign

wlitool

wliwrap

wlixfr

wliadm

wlicert

wlisys

wlisyspolicy

wlitrace

2.1.1.1 Application API

The shared library /opt/wli/lib/libwliapi.so provides API functions for applications to add, delete, and verify access rights for WLI file access policies. For details on libwliapi functions, see libwliapi(3).

Manage WLI file access policies

Manage WLI signatures on binary executables

Sign ELF executable files with or without WLI installed

Run commands with WLI capabilities

Transfer WLI file access policies from one file to another

Manage WLI administrator keys

Manage WLI user keys and capabilities

Manage WLI configuration attributes

Manage WLI security attributes

Unsupported diagnostic tool for HP support personnel only

14 Product overview

The ability to execute functions within this library is a resource protected by WLI. As with other resources protected by WLI, access must explicitly be granted through WLI using authorized RSA keys.

2.1.1.2 Applications

Enforcement of WLI file access policies and resource restrictions is imposed on all applications and commands.Application binaries and files have no requirements for modification or relinking.

A user may restrict application access to local files and directories through WLI commands. Applications arepermitted access to files andresources protected by WLIthrough WLI commands.

When the WLI security mode is restricted, access policies on all local regular files and directories are enforced. All user applications, including those invoked by root user (uid 0), are not permitted to override access restrictions imposed by WLI.

WLI also provides the security mode maintenance. This mode is unsecure and only recommended when the system is inaccessible to all but administration personnel. WLI policy enforcement and resource protection are not enabled in this mode.

WLI uses FIPS 140-2 certified OpenSSL 1.1.2 archive libcrypto.a, based on OpenSSL A.00.09.07m. This archive is stored at /opt/openssl/fips/0.9.7/lib/hpux64/ libcrypto.a when included with an OpenSSL version such as A.00.09.08l.003. For more information about FIPS 140-2 (Federal Information Processing Standard 140-2), see http://

www.openssl.org/docs/fips.

Because functions from this archive are statically linked into WLI commands, the archive is not required to be present on platforms where WLI is installed. WLI uses libcrypto.a functions to parse RSA key files generated by all OpenSSL versions. The OpenSSL license is stored at /opt/ wli/OpenSSL.LICENSE as part of the WLI installation.

2.1.1.3 Stackable file system module

The HP-UX Stackable File System allows modification of the kernel file system stack through inclusion of one or more executable modules that conform to the VFS interface. A module can be inserted into the file system stack between the VFS layer and one or more file system type modules such as VxFS (JFS) or HFS.

Modifing existing filesystem type modules is not necessary; the kernel is relinked and rebooted. When the relinked kernel becomes active, the inserted module becomes a component in the file system stack.

When WLI installs, its file system module is inserted between VFS and the local file system type modules that handle local data storage. When a file is opened by an application for read or write access, the WLI file system module causes the open() to fail if a WLI policy on the file would be violated.

2.1.1.4 Policy enforcement manager

This componentenforces WLI file access rules. Only the following access policy types are provided:

• A FLAC policy limits access to a specific WLI-signed binary executable.

• An IBAC policy limits access to a designated set of executables.

A WLI administrator key may also allow access to specific system resources protected by WLI, such as the /dev/mem and /dev/kmem special files.

WLI maintains a database of file access policies and resource restrictions generated by users and administrators. This database is referenced by the Policy Enforcement Manager from within the kernel domain. The Policy Enforcement Manager is called by the WLI file system module to determine if a restriction imposed by WLI should prevent access.

2.1 WLI architecture 15

2.1.1.5 File systems

WLI security features are imposed on all directories and regular files that reside in file systems called through the VFS layer.

WLI generates metadata to keep track of its file access policies. Policy metadata might become scattered in files throughout a file system. VxFS (aka JFS) at revision 5.0.1 or later is an exception because metadata can be stored within a named stream. A named stream is associated with a file inode, but is not accessible through the usual open() on the file.

Because a proprietary utility like Symantec NetBackup is required for backing up named streams, the administrator may choose to have metadata stored on files only.

WLI also generates signature metadata for signed executable binaries. For native ELF binaries, the metadata is stored within a special section of the file. PA-RISC binaries are also executable on IA platforms, but their metadata is stored in files similar to policy metadata files.

Special device files within file systems are not affected by WLI with the exception of /dev/mem and /dev/kmem. In restricted mode, access to these files is denied except to applications explicitly granted the mem capability. For more information on WLI capabilities, see “Security features”

(page 9) and wli(5).

2.2 WLI database

WLI maintains a set of regular files and directories under /etc/wli. Some files contain configuration data referenced during system boot, and others maintain user and administrator key associations within WLI. These files are installed with WLI or are generated when WLI is initialized, as described in “Configuring” (page 25). WLI prohibits write access to these files in restricted mode. In maintenance mode, the entire database can be read or written without WLI restrictions.

The following directories are under /etc/wli:

/etc/wli/keys

/etc/wli/certificates

The following files are under /etc/wli: /etc/wli/wlicert.conf

/etc/wli/wlisyspolicy.conf

/etc/wli/wlisys.conf

2.3 WLI metadata files

WLI generates at least one metadata file. The number of metadata files generated depends on file system version, value of the wmdstoretype attribute, and file system type.

The following sections describe the metadata file types. All metadata file types have WLI write protection in restricted mode. To override WLI protection for file backup, see Section 1.2.2

(page 10).

Directory containing password-encrypted administrator private keys, one per file. In maintenance mode, the directory can be read and written. Read/write access is prohibited for all files in this directory in restricted mode.

Directory containing public keys authorized for run-time verification of file access policies.

File mapping WLI capabilities to authorized public keys. For details on content, see wlicert.conf(4). WLI does not permit write access to this file in restricted mode.

File containing security parameters read into kernel memory early in the HP-UX boot process. For details on content, see wlisys(1M) and wlisyspolicy(1M).

File containing initialization parameters for WLI kernel components. For details on content, see wlisys(1M).

16 Product overview

2.3.1 .$WLI_FSPARMS$

These metadata files are regular files containing metadata storage types for the file system where they reside. This file always appears in the root directory of a file system that also contains WLI metadata. The metadata storage type is indicated by the wmdstoretype parameter. For details, see wlisys(1M). The following storage types are available:

auto If the file system is VxFS at revision 5.0.1 or later, metadata is stored in a named

stream. A named stream is associated with the protected file inode and not accessible to most commands. For VxFS file systems at revision 5.0 or earlier and all other file system types, metadata storage is the same as described in the following entry for pseudo.

pseudo Metadata is stored separately in files within directories always named

.$WLI_POLICY$, described in the following section. These metadata directories always reside in the parent directory of the policy protected files.

2.3.2 .$WLI_POLICY$

Directories named.$WLI_POLICY$ contain policy metadata files, and appear if the wmdstoretype parameter has value pseudo, or the file system type is VxFS 5.0 or earlier. These directories also appear for all non-VxFS file systems. In addition to write protection, WLI does not allow read access to all files under directories with this name.

Each file in this directory has the same name as a file that is assigned an access policy through wlipolicy in the parent directory. For example, if /tmp contains the following files with WLI access policies:

% ls -l /tmp/JdMB4NJ1 /tmp/T1df07xe

-rw------- 1 joe users 2723 May 4 14:49 /tmp/JdMB4NJ1

-rw------- 1 joe users 8199 Jun 3 20:46 /tmp/T1df07xe

Then, /tmp/ .$WLI_POLICY$ contains the corresponding policy metadata files:

% ls -l /tmp/.\$WLI_POLICY\$

-rw------- 1 joe users 2048 Jul 15 15:29 JdMB4NJ1

-rw------- 1 joe users 2048 Jun 3 20:47 T1df07xe

NOTE: The ’\’ escape character is used to escape ‘$’, a special character to shell interpreters.

2.3.3 .$WLI_SIGNATURE$

Directories named .$WLI_SIGNATURE$ contain signature metadata files. In addition to write protection, WLI does not allow read access to all files under directories with this name.

Each file in this directory has the same name as a non ELF binary that is signed with wlisign in the parent directory. For example, if /tmp contains non ELF binaries:

% ls -l CXkiELYm wpSzpxzI

-rw------- 1 joe users 1809 Dec 9 2009 /tmp/CXkiELYm

-rw------- 1 joe users 1809 Mar 21 03:13 /tmp/wpSzpxzI

Then, /tmp/ .$WLI_SIGNATURE$ contains the corresponding signature metadata files:

% ls -l /tmp/.\$WLI_SIGNATURE\$

-rw------- 1 joe users 2048 Jul 15 01:33 /tmp/CXkiELYm

-rw------- 1 joe users 2048 Jul 15 01:36 /tmp/wpSzpxzI

NOTE: The ’\’ escape character is used to escape ‘$’, a special character to shell interpreters.

ELF-formatted binaries signed by wlitool or wlisign store their signature metadata within a section of the binary file and do not have separate metadata files.

2.3 WLI metadata files 17

3 Key usage

WLI defines two key types. User keys can sign executable binaries and generate file access policies. Administrator keys have all the authority of user keys, but also can be used to authorize changes to the WLI database.

WLI dependson RSA keys for authorization of many of its command operations. A WLI command with the “1M” manpage designation means an administrator key is required to execute at least one command option, not the traditional root user (user ID 0). A “1” manpage indicates the command options can be authorized with a user key. Except for wliadm -i, WLI does not reference user or group ID for command operations.

Because an RSA private key contains all the information held within the corresponding public key, the term “key” is synonymous with “private key”. This terminology is common in cryptographic literature.

3.1 Generating keys

WLI administrator and user keys are generated with the openssl command tool installed on HP-UX as part of the OpenSSL product. For the highest level of security, a 2048 bit key length is recommended. Other supported key lengths are 512, 1024, and 1536 bits. Files with RSA keys in PEM format are required for WLI command operations that require keys.

The openssl command also provides several cipher options for passphrase encryption of RSA keys. The aes256 cipher is among the ciphers offered by OpenSSL. This cipher is the AES-256 cipher from the Advanced Encryption Standard chosen by the U.S. government in 2001 as a standard for encryption. The aes256 cipher is highly recommended but not required. Any cipher offered by OpenSSL is supported by WLI.

The genrsa subcommand creates an RSA private key. For a complete synopsis, see genrsa(1). The following is sufficient to generate keys for WLI:

% openssl genrsa [-passout <arg>] -<cipher> -out <file> <length>

where:

<arg> is the passphrase source and value if -passout is used. Ifnot supplied, the /dev/

tty device prompts for it. For details, see openssl(1).

<file>

If a passphrase is not specified with genrsa, the user is prompted to enter a passphrase. Using the cipher and length recommendations mentioned previously, an example of key creation key is:

% openssl genrsa -aes256 -out /wli/priv.pem 2048

The rsa subcommand displays the numerical components of an RSA key. To view the key created in the previous example:

% openssl rsa -in /wli/priv.pem -noout -text

A prompt appears for the passphrase in this example because it is not included. RSA protocol for encrypting and decrypting messages intends that the private key and its passphrase are secret quantities. WLI follows this convention.

is the algorithm for encrypting the private key.

is the file containing the generated private key. The default file format is PEM, the only RSA key file format recognized by WLI.

is the number of bits in the generated private key.

The RSA public key is a subset of the information comprising the private key. For the key /wli/

priv.pem generated above, the public key /wli/pub.pem can be extracted with the following rsa subcommand:

% openssl rsa -in /wli/priv.pem -out /wli/pub.pem -pubout

3.1 Generating keys 19

+ 43 hidden pages