This section provides specific overview information for the following key OES components:
AppArmor provides easy-to-use application security for both servers and workstations. You specify which files a program can read, write, and execute.
AppArmor enforces good application behavior without relying on attack signatures and prevents attacks even if they are exploiting previously unknown vulnerabilities.
For more information, see the AppArmor Documentation Web site.
OES includes the NSS Auditing Engine, which is installed by default with NSS.
The auditing engine provides an interface for auditing client applications, such as Novell Sentinel and various third-party products to access. Information about the auditing engine SDK is available on the OpenText Web site.
Using the SDK, client applications can be developed to audit various NSS file system operations on files and directories, including:
delete
create
open
close
rename
link
metadata modified
trustee add/delete
inherited rights modified
Novell Sentinel Log Manager runs on a 64-bit SLES host. You can download the suite from the Software Licenses and Downloads (SLD). For installation and usage instructions, see the Novell Sentinel Readme and Release Notes included as a link on the download page.
For information about third-party partner applications that leverage the NSS Auditing Engine, see the OES partners’ page.
The Novell International Cryptography Infrastructure (NICI) is the cryptography service for NetIQ eDirectory, NetIQ Modular Authentication Services (NMAS), NetIQ Certificate Server, NetIQ SecretStore, and TLS/SSL.
NICI includes the following key features:
Industry standards: It implements the recognized industry standards.
Certified: It is FIPS-140-1 certified on selected platforms.
Cross-platform support: It is available on both OES platforms.
Governmental export and import compliance: It has cryptographic interfaces that are exportable from the U.S. and importable into other countries with government-imposed constraints on the export, import, and use of products that contain embedded cryptographic mechanisms.
Secure and tamper-resistant architecture: The architecture uses digital signatures to implement a self-verification process so that consuming services are assured that NICI has not been modified or tampered with when it is initialized.
In the early days of NICI development, some NICI problems could be solved only by deleting the NICI configuration files and starting over. The issues that required this were solved years ago, but as is often the case, the practice persists, and some administrators attempt to use this as a remedy when they encounter a NICI problem.
No one should ever delete the NICI configuration files unless they are directly told to do so by a member of the NICI development team. And in that rare case, they should be sure to back up the files before doing so. Failure to do this makes restoring NICI impossible.
For more information on how to use NICI, see the Novell International Cryptographic Infrastructure (NICI) 2.7.6 Administration Guide.
In addition to the information explained and referenced in this section, the OES online documentation contains links to “security issues”.