HP UX Security Products and Features Software manual Security features, File access policies

Page 9

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 and encryption 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

 

generating policies that are enforced within the kernel domain.

 

WLI then grants access only to applications meeting the policy

 

requirements for the protected files.

Capabilities

When WLI is installed, certain system resources known to be

 

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

Image 9
Contents HP-UX Whitelisting A.01.00 Administrator Guide Copyright 2010 Hewlett-Packard Development Company, L.P Table of Contents HP Serviceguard considerations Glossary Index List of Figures List of Examples Page Security features File access policiesFile lock access controls Capabilities Identity-based access controls4 api Page WLI architecture Product overviewApplication API CommandsApplications WLI metadata files WLI database3 .$WLISIGNATURE$ Page Generating keys Key usageUser keys Administrator keysInstalling, removing, and upgrading Installation requirementsInstalling WLI Removing WLI Upgrading WLI Page Configuring Authorizing the recovery keyAuthorizing administrator keys Backing up the WLI database Signing DLKMsRebooting to restricted mode Page Enhancing security with WLI Signing an executable binaryCreating a Flac policy Removing a file access policy Enabling DLKMs to load during bootCreating an Ibac policy Wlisign -a -k adminpriv /usr/sbin/kcmodule # wlisign -a -k /home/admin1/adminpriv /usr/conf/mod/cissLoading unsigned DLKMs # kcmodule ciss=unusedPage Backup and restore considerations OverviewWLI database files Write protected Policy protected and metadata filesRead/write protected files RecommendationsFlac policies Ibac policiesMetadata files Page HP Serviceguard considerations AdministrationWLI database Policy protected files Software distributor issues Troubleshooting and known issuesWLI reinstallation Lost WLI administrator key or passphraseSu root # rm -r /etc/wli Wlisyspolicy -s mode=maintenance -k adminkey# tar -xf /tmp/wlikeydb.tar # kcmodule wli=unused # shutdown -rSupport and other resources Contacting HPRelated information Typographic conventions WebsitesUser input Times Page Instructions # make clean# make all # su wliusr1Ibac add and delete program Flac add and delete programIbac add and delete program Page Administration examples Su root # wlisign -a -k adm1.pvt /usr/bin/tar Wlicert -s -c wli.admin1 -o wmd -k adm1.pvtBdf mydir Tar -vtf tartest.tarCat /tmp/.$WLIFSPARMS$ Wlisys -k adm1.pvt -s wmdstoretype=pseudoBprestore -f backuplist Bpbackup -f backuplistConfiguring WLI Quick setup examplesAuthorizing an administrator key Authorizing a user keyFlac policies Testing a Flac policyCreating a Flac policy Enabling a Flac policyIbac policies Removing an Ibac policy Disabling an Ibac policyASM GlossaryPage Index SymbolsIndex
Related manuals
Manual 130 pages 58.55 Kb