The following is a description of the elements, types, and attributes that compose the Linux specific tests found in Open Vulnerability and Assessment Language (OVAL). Each test is an extension of the standard test element defined in the Core Definition Schema. Through extension, each test inherits a set of elements and attributes that are shared amongst all OVAL tests. Each test is described in detail and should provide the information necessary to understand what each element and attribute represents. This document is intended for developers and assumes some familiarity with XML. A high level description of the interaction between the different tests and their relationship to the Core Definition Schema is not outlined here. The OVAL Schema is maintained by the OVAL Community. For more information, including how to get involved in the project and how to submit change requests, please visit the OVAL website at http://oval.cisecurity.org. Linux Definition 5.11.1:1.2 11/30/2016 09:00:00 AM Copyright (c) 2016, Center for Internet Security. All rights reserved. The contents of this file are subject to the terms of the OVAL License located at https://oval.cisecurity.org/terms. See the OVAL License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the OVAL Schema, this license header must be included. The AppArmor Status Test is used to check properties representing the counts of profiles and processes as per the results of the "apparmor_status" or "aa-status" command. It extends the standard TestType as defined in the oval-definitions-schema and one should refer to the TestType description for more information. The required object element references an apparmorstatus_object and the optional state element specifies the data to check. apparmorstatus_test apparmorstatus_object apparmorstatus_state apparmorstatus_item - the object child element of a apparmorstatus_test must reference a apparmorstatus_object - the state child element of a apparmorstatustest must reference a apparmorstatus_state The apparmorstatus_object element is used by an apparmorstatus test to define the different information about the current AppArmor polciy. There is actually only one object relating to AppArmor Status and this is the system as a whole. Therefore, there are no child entities defined. Any OVAL Test written to check AppArmor status will reference the same apparmorstatus_object which is basically an empty object element. The AppArmor Status Item displays various information about the current AppArmor policy. This item maps the counts of profiles and processes as per the results of the "apparmor_status" or "aa-status" command. Please refer to the individual elements in the schema for more details about what each represents. Displays the number of loaded profiles Displays the number of profiles in enforce mode Displays the number of profiles in complain mode Displays the number of processes which have profiles defined Displays the number of processes in enforce mode Displays the number of processes in complain mode Displays the number of processes which are unconfined but have a profile defined The dpkginfo test is used to check information for a given DPKG package. It extends the standard TestType as defined in the oval-definitions-schema and one should refer to the TestType description for more information. The required object element references a dpkginfo_object and the optional state element specifies the data to check. dpkginfo_test dpkginfo_object dpkginfo_state dpkginfo_item - the object child element of an dpkginfo_test must reference an dpkginfo_object - the state child element of an dpkginfo_test must reference an dpkginfo_state The dpkginfo_object element is used by a dpkginfo test to define the object to be evaluated. Each object extends the standard ObjectType as defined in the oval-definitions-schema and one should refer to the ObjectType description for more information. The common set element allows complex objects to be created using filters and set logic. Again, please refer to the description of the set element in the oval-definitions-schema. A dpkginfo object consists of a single name entity that identifies the package being checked. State referenced in filter for '' is of the wrong type. This is the package name to check. The dpkginfo_state element defines the different information that can be used to evaluate the specified DPKG package. This includes the architecture, epoch number, release, and version numbers. Please refer to the individual elements in the schema for more details about what each represents. This is the DPKG package name to check. This is the architecture for which the package was built, like : i386, ppc, sparc, noarch. This is the epoch number of the DPKG. For a null epoch (or '(none)' as returned by dpkg) the string '(none)' should be used. This is the release number of the build, changed by the vendor/builder. This is the version number of the build. This represents the epoch, upstream_version, and debian_revision fields, for a Debian package, as a single version string. It has the form "EPOCH:UPSTREAM_VERSION-DEBIAN_REVISION". Note that a null epoch (or '(none)' as returned by dpkg) is equivalent to '0' and would hence have the form 0:UPSTREAM_VERSION-DEBIAN_REVISION. Warning: There are differences in the algorithms for how the version strings of Debian and RPM packages are compared. As a result, a new debian_evr_string datatype was added to the OVAL Language and should be used, for this entity, instead of the evr_string datatype. The iflisteners_test is used to check what applications such as packet sniffers that are bound to an interface on the system. This is limited to applications that are listening on AF_PACKET sockets. Furthermore, only applications bound to an ethernet interface should be collected. It extends the standard TestType as defined in the oval-definitions-schema and one should refer to the TestType description for more information. The required object element references an iflisteners_object and the optional iflisteners_state element specifies the data to check. iflisteners_test iflisteners_object iflisteners_state iflisteners_item - the object child element of an iflisteners_test must reference an iflisteners_object - the state child element of an iflisteners_test must reference an iflisteners_state The iflisteners_object element is used by an iflisteners_test to define the specific interface to be evaluated. Each object extends the standard ObjectType as defined in the oval-definitions-schema and one should refer to the ObjectType description for more information. The common set element allows complex objects to be created using filters and set logic. Again, please refer to the description of the set element in the oval-definitions-schema. State referenced in filter for '' is of the wrong type. The interface_name entity specifies the name of the interface (eth0, eth1, fw0, etc.) to check. The iflisteners_state element defines the different information that can be used to evaluate the specified applications that are listening on interfaces on the system. This includes the interface name, protocol, hardware address, program name, pid, and user id. Please refer to the individual elements in the schema for more details about what each represents. This is the name of the interface (eth0, eth1, fw0, etc.). This is the physical layer protocol used by the AF_PACKET socket. This is the hardware address associated with the interface. This is the name of the communicating program. The pid is the process ID of a specific process. The numeric user id, or uid, is the third column of each user's entry in /etc/passwd. It represents the owner, and thus privilege level, of the specified program. The inet listening servers test is used to check what applications are listening on the network. This is limited to applications that are listening for connections that use the TCP or UDP protocols and have addresses represented as IPv4 or IPv6 addresses (AF_INET or AF_INET6). It is generally using the parsed output of running the command netstat -tuwlnpe with root privilege. It extends the standard TestType as defined in the oval-definitions-schema and one should refer to the TestType description for more information. The required object element references an inetlisteningservers_object and the optional state element specifies the data to check. inetlisteningservers_test inetlisteningservers_object inetlisteningservers_state inetlisteningserver_item - the object child element of an inetlisteningservers_test must reference an inetlisteningservers_object - the state child element of an inetlisteningservers_test must reference an inetlisteningservers_state The inetlisteningservers_object element is used by an inet listening servers test to define the specific protocol-address-port to be evaluated. Each object extends the standard ObjectType as defined in the oval-definitions-schema and one should refer to the ObjectType description for more information. The common set element allows complex objects to be created using filters and set logic. Again, please refer to the description of the set element in the oval-definitions-schema. An inet listening servers object consists of three entities. The first identifies a specific IP address. The second entity represents a certain port number. While the third identifies the protocol. State referenced in filter for '' is of the wrong type. The protocol entity defines a certain transport-layer protocol, in lowercase: tcp or udp. This is the IP address of the network interface on which an application listens. Note that the IP address can be IPv4 or IPv6. This is the TCP or UDP port on which an application would listen. Note that this is not a list -- if a program listens on multiple ports, or on a combination of TCP and UDP, each will be represented by its own object. The inetlisteningservers_state element defines the different information that can be used to evaluate the specified inet listening server. This includes the local address, foreign address, port information, and process id. Please refer to the individual elements in the schema for more details about what each represents. The protocol entity defines the specific transport-layer protocol, in lowercase: tcp or udp, associated with the inet listening server. This is the IP address of the network interface on which the program listens. Note that the IP address can be IPv4 or IPv6. This is the TCP or UDP port number associated with the inet listening server. This is the IP address and network port number associated with the inet listening server, equivalent to local_address:local_port. Note that the IP address can be IPv4 or IPv6. This is the name of the communicating program. This is the IP address with which the program is communicating, or with which it will communicate, in the case of a listening server. Note that the IP address can be IPv4 or IPv6. This is the TCP or UDP port to which the program communicates. In the case of a listening program accepting new connections, the value will be 0. This is the IP address and network port to which the program is communicating or will accept communications from, equivalent to foreign_address:foreign_port. Note that the IP address can be IPv4 or IPv6. The pid is the process ID of a specific process. The numeric user id, or uid, is the third column of each user's entry in /etc/passwd. It represents the owner, and thus privilege level, of the specified program. The partition_test is used to check the information associated with partitions on the local system. It extends the standard TestType as defined in the oval-definitions-schema and one should refer to the TestType description for more information. The required object element references a partition_object and the optional state element references a partition_state that specifies the information to check. partition_test partition_object partition_state partition_item - the object child element of a partition_test must reference a partition_object - the state child element of a partition_test must reference a partition_state The partition_object is used by a partition_test to define which partitions on the local system should be collected. Each object extends the standard ObjectType as defined in the oval-definitions-schema and one should refer to the ObjectType description for more information. The common set element allows complex objects to be created using filters and set logic. Again, please refer to the description of the set element in the oval-definitions-schema. State referenced in filter for '' is of the wrong type. The mount_point element specifies the mount points of the partitions that should be collected from the local system. The partition_state element defines the different information associated with a partition. This includes the name, filesystem type, mount options, total space, space used, and space left. Please refer to the individual elements in the schema for more details about what each represents. The mount_point element contains a string that represents the mount point of a partition on the local system. The device element contains a string that represents the name of the device. The uuid element contains a string that represents the universally unique identifier associated with a partition. The fs_type element contains a string that represents the type of filesystem on a partition. The mount_options element contains a string that represents the mount options associated with a partition. Implementation note: not all mount options are visible in /etc/mtab or /proc/mounts. A complete source of additional mount options is the f_flag field of 'struct statvfs'. See statvfs(2). /etc/fstab may have additional mount options, but it need not contain all mounted filesystems, so it MUST NOT be relied upon. Implementers MUST be sure to get all mount options in some way. The total_space element contains an integer that represents the total number of physical blocks on a partition. The space_used element contains an integer that represents the number of physical blocks used on a partition. The space_left element contains an integer that represents the number of physical blocks left on a partition available to be used by privileged users. The space_left_for_unprivileged_users element contains an integer that represents the number of physical blocks remaining on a partition that are available to be used by unprivileged users. The block_size element contains an integer that represents the actual byte size of each physical block on the partition's block device. This is the same block size used to compute the total_space, space_used, and space_left. The rpminfo_test is used to check the RPM header information for a given RPM package. It extends the standard TestType as defined in the oval-definitions-schema and one should refer to the TestType description for more information. The required object element references a rpminfo_object and the optional state element specifies the data to check. rpminfo_test rpminfo_object rpminfo_state rpminfo_item - the object child element of an rpminfo_test must reference an rpminfo_object - the state child element of an rpminfo_test must reference an rpminfo_state The rpminfo_object element is used by a rpm info test to define the object to be evaluated. Each object extends the standard ObjectType as defined in the oval-definitions-schema and one should refer to the ObjectType description for more information. The common set element allows complex objects to be created using filters and set logic. Again, please refer to the description of the set element in the oval-definitions-schema. A rpm info object consists of a single name entity that identifies the package being checked. State referenced in filter for '' is of the wrong type. This is the package name to check. The rpminfo_state element defines the different information that can be used to evaluate the specified rpm. This includes the architecture, epoch number, and version numbers. Most of this information can be obtained through the rpm function. Please refer to the individual elements in the schema for more details about what each represents. This is the package name to check. This is the architecture for which the RPM was built, like : i386, ppc, sparc, noarch. In the case of an apache rpm named httpd-2.0.40-21.11.4.i686.rpm, this value would be i686. This is the epoch number of the RPM, this is used as a kludge for version-release comparisons where the vendor has done some kind of re-numbering or version forking. For a null epoch (or '(none)' as returned by rpm) the string '(none)' should be used.. This number is not revealed by a normal query of the RPM's information -- you must use a formatted rpm query command to gather this data from the command line, like so. For an already-installed RPM: rpm -q --qf '%{EPOCH}\n' installed_rpm For an RPM file that has not been installed: rpm -qp --qf '%{EPOCH}\n' rpm_file This is the release number of the build, changed by the vendor/builder. This is the version number of the build. In the case of an apache rpm named httpd-2.0.40-21.11.4.i686.rpm, this value would be 2.0.40. This represents the epoch, version, and release fields as a single version string. It has the form "EPOCH:VERSION-RELEASE". Note that a null epoch (or '(none)' as returned by rpm) is equivalent to '0' and would hence have the form 0:VERSION-RELEASE. Comparisons involving this datatype should follow the algorithm of librpm's rpmvercmp() function. This field contains the 64-bit PGP key ID that the RPM issuer (generally the original operating system vendor) uses to sign the key. Note that the value should NOT contain a hyphen to separate the higher 32-bits from the lower 32-bits. It should simply be a 16 character hex string. PGP is used to verify the authenticity and integrity of the RPM being considered. Software packages and patches are signed cryptographically to allow administrators to allay concerns that the distribution mechanism has been compromised, whether that mechanism is web site, FTP server, or even a mirror controlled by a hostile party. OVAL uses this field most of all to confirm that the package installed on the system is that shipped by the vendor, since comparing package version numbers against patch announcements is only programmatically valid if the installed package is known to contain the patched code. This represents the name, epoch, version, release, and architecture fields as a single version string. It has the form "NAME-EPOCH:VERSION-RELEASE.ARCHITECTURE". Note that a null epoch (or '(none)' as returned by rpm) is equivalent to '0' and would hence have the form NAME-0:VERSION-RELEASE.ARCHITECTURE. The 'gpg-pubkey' virtual package on RedHat and CentOS should use the string '(none)' for the architecture to construct the extended_name. This field contains the absolute path of a file or directory included in the rpm. The RpmInfoBehaviors complex type defines a set of behaviors for controlling what data, for installed rpms, is collected. This behavior aligns with the rpm command. 'filepaths', when true, this behavior means collect all filepaths (directory and file information) from the rpm database for the package. The rpmverify_test is used to verify the integrity of installed RPMs. This test aligns with the rpm -V command for verifying RPMs. It extends the standard TestType as defined in the oval-definitions-schema and one should refer to the TestType description for more information. The required object element references a rpmverify_object and the optional state element specifies the data to check. rpmverify_test rpmverify_object rpmverify_state rpmverify_item 5.10 Replaced by the rpmverifyfile_test and the rpmverifypackage_test. The rpmverify_test was split into two tests to distinguish between the verification of the files in an rpm and the verification of an rpm as a whole. By making this distinction, content authoring is simplified and information is no longer duplicated across items. See the rpmverifyfile_test and rpmverifypackage_test. This test has been deprecated and will be removed in version 6.0 of the language. DEPRECATED TEST: ID: - the object child element of an rpmverify_test must reference an rpmverify_object - the state child element of an rpmverify_test must reference an rpmverify_state The rpmverify_object element is used by a rpmverify_test to define a set of files within a set of RPMs to verify. Each object extends the standard ObjectType as defined in the oval-definitions-schema and one should refer to the ObjectType description for more information. The common set element allows complex objects to be created using filters and set logic. Again, please refer to the description of the set element in the oval-definitions-schema. State referenced in filter for '' is of the wrong type. 5.10 Replaced by the rpmverifyfile_object and rpmverifypackage_object. The rpmverify_test was split into two tests to distinguish between the verification of the files in an rpm and the verification of an rpm as a whole. By making this distinction, content authoring is simplified and information is no longer duplicated across items. See the rpmverifyfile_object and rpmverifypackage_object. This object has been deprecated and will be removed in version 6.0 of the language. DEPRECATED OBJECT: ID: This is the package name to check. The filepath element specifies the absolute path for a file or directory in the specified package. The rpmverify_state element defines the different information that can be used to evaluate the specified rpm. This includes the architecture, epoch number, and version numbers. Most of this information can be obtained through the rpm function. Please refer to the individual elements in the schema for more details about what each represents. 5.10 Replaced by the rpmverifyfile_state and rpmverifypackage_state. The rpmverify_test was split into two tests to distinguish between the verification of the files in an rpm and the verification of an rpm as a whole. By making this distinction, content authoring is simplified and information is no longer duplicated across items. See the rpmverifyfile_state and rpmverifypackage_state. This state has been deprecated and will be removed in version 6.0 of the language. DEPRECATED STATE: ID: This is the package name to check. The filepath element specifies the absolute path for a file or directory in the specified package. The size_differs entity aligns with the first character ('S' flag) in the character string in the output generated by running rpm –V on a specific file. The mode_differs entity aligns with the second character ('M' flag) in the character string in the output generated by running rpm –V on a specific file. The md5_differs entity aligns with the third character ('5' flag) in the character string in the output generated by running rpm –V on a specific file. The device_differs entity aligns with the fourth character ('D' flag) in the character string in the output generated by running rpm –V on a specific file. The link_mismatch entity aligns with the fifth character ('L' flag) in the character string in the output generated by running rpm –V on a specific file. The ownership_differs entity aligns with the sixth character ('U' flag) in the character string in the output generated by running rpm –V on a specific file. The group_differs entity aligns with the seventh character ('U' flag) in the character string in the output generated by running rpm –V on a specific file. The mtime_differs entity aligns with the eighth character ('T' flag) in the character string in the output generated by running rpm –V on a specific file. The size_differs entity aligns with the ninth character ('P' flag) in the character string in the output generated by running rpm –V on a specific file. The configuration_file entity represents the configuration file attribute marker that may be present on a file. The documentation_file entity represents the documenation file attribute marker that may be present on a file. The ghost_file entity represents the ghost file attribute marker that may be present on a file. The license_file entity represents the license file attribute marker that may be present on a file. The readme_file entity represents the readme file attribute marker that may be present on a file. The RpmVerifyBehaviors complex type defines a set of behaviors that for controlling how installed rpms are verified. These behaviors align with the verify-options of the rpm command with the addition of two behaviors that will indicate that a file with a given attribute marker should not be collected. 5.10 Replaced by the RpmVerifyFileBehaviors and the RpmVerifyPackageBehaviors. The RpmVerifyBehaviors complex type is used by the rpmverify_test which was split into two tests to distinguish between the verification of the files in an rpm and the verification of an rpm as a whole. By making this distinction, content authoring is simplified and information is no longer duplicated across items. The new tests utilize the RpmVerifyFileBehaviors and RpmVerifyPackageBehaviors complex types, and as a result, the RpmVerifyBehaviors complex type is no longer needed. This complex type has been deprecated and will be removed in version 6.0 of the language. 'nodeps' when true this behavior means, don't verify dependencies of packages. 'nodigest' when true this behavior means, don't verify package or header digests when reading. 'nofiles' when true this behavior means, don't verify any attributes of package files. 'noscripts' when true this behavior means, don't execute the %verifyscript scriptlet (if any). 'nosignature' when true this behavior means, don't verify package or header signatures when reading. 'nolinkto' when true this behavior means, don't verify symbolic links attribute. 'nomd5' when true this behavior means, don't verify the file md5 attribute. 'nosize' when true this behavior means, don't verify the file size attribute. 'nouser' when true this behavior means, don't verify the file owner attribute. 'nogroup' when true this behavior means, don't verify the file group owner attribute. 'nomtime' when true this behavior means, don't verify the file mtime attribute. 'nomode' when true this behavior means, don't verify the file mode attribute. 'nordev' when true this behavior means, don't verify the file rdev attribute. 'noconfigfiles' when true this behavior means, skip files that are marked with the %config attribute marker. 'noghostfiles' when true this behavior means, skip files that are maked with %ghost attribute marker. The rpmverifyfile_test is used to verify the integrity of the individual files in installed RPMs. This test aligns with the rpm -V command for verifying RPMs. It extends the standard TestType as defined in the oval-definitions-schema and one should refer to the TestType description for more information. The required object element references a rpmverifyfile_object and the optional state element specifies the data to check. rpmverifyfile_test rpmverifyfile_object rpmverifyfile_state rpmverifyfile_item - the object child element of an rpmverifyfile_test must reference an rpmverifyfile_object - the state child element of an rpmverifyfile_test must reference an rpmverifyfile_state The rpmverifyfile_object element is used by a rpmverifyfile_test to define a set of files within a set of RPMs to verify. Each object extends the standard ObjectType as defined in the oval-definitions-schema and one should refer to the ObjectType description for more information. The common set element allows complex objects to be created using filters and set logic. Again, please refer to the description of the set element in the oval-definitions-schema. State referenced in filter for '' is of the wrong type. This is the package name to check. This is the epoch number of the RPM, this is used as a kludge for version-release comparisons where the vendor has done some kind of re-numbering or version forking. For a null epoch (or '(none)' as returned by rpm) the string '(none)' should be used.. This number is not revealed by a normal query of the RPM's information -- you must use a formatted rpm query command to gather this data from the command line, like so. For an already-installed RPM: rpm -q --qf '%{EPOCH}\n' installed_rpm For an RPM file that has not been installed: rpm -qp --qf '%{EPOCH}\n' rpm_file This is the version number of the build. In the case of an apache rpm named httpd-2.0.40-21.11.4.i686.rpm, this value would be 2.0.40. This is the release number of the build, changed by the vendor/builder. This is the architecture for which the RPM was built, like : i386, ppc, sparc, noarch. In the case of an apache rpm named httpd-2.0.40-21.11.4.i686.rpm, this value would be i686. The filepath element specifies the absolute path for a file or directory in the specified package. The rpmverifyfile_state element defines the different information that can be used to determine if a set of files within a set of RPMs passed verification. This includes the architecture, epoch number, version numbers, and the verification of various file attributes. Most of this information can be obtained through the rpm function. Please refer to the individual elements in the schema for more details about what each represents. This is the package name to check. This is the epoch number of the RPM, this is used as a kludge for version-release comparisons where the vendor has done some kind of re-numbering or version forking. For a null epoch (or '(none)' as returned by rpm) the string '(none)' should be used.. This number is not revealed by a normal query of the RPM's information -- you must use a formatted rpm query command to gather this data from the command line, like so. For an already-installed RPM: rpm -q --qf '%{EPOCH}\n' installed_rpm For an RPM file that has not been installed: rpm -qp --qf '%{EPOCH}\n' rpm_file This is the version number of the build. In the case of an apache rpm named httpd-2.0.40-21.11.4.i686.rpm, this value would be 2.0.40. This is the release number of the build, changed by the vendor/builder. This is the architecture for which the RPM was built, like : i386, ppc, sparc, noarch. In the case of an apache rpm named httpd-2.0.40-21.11.4.i686.rpm, this value would be i686. The filepath element specifies the absolute path for a file or directory in the specified package. This represents the name, epoch, version, release, and architecture fields as a single version string. It has the form "NAME-EPOCH:VERSION-RELEASE.ARCHITECTURE". Note that a null epoch (or '(none)' as returned by rpm) is equivalent to '0' and would hence have the form NAME-0:VERSION-RELEASE.ARCHITECTURE. The size_differs entity aligns with the first character ('S' flag) in the character string in the output generated by running rpm –V on a specific file. The mode_differs entity aligns with the second character ('M' flag) in the character string in the output generated by running rpm –V on a specific file. The md5_differs entity aligns with the third character ('5' flag) in the character string in the output generated by running rpm –V on a specific file. 5.11.1:1.1 Replaced by the filedigest_differs entity. This entity has been deprecated and will be removed in version 6.0 of the language. The filedigest_differs entity aligns with the third character ('5' flag) in the character string in the output generated by running rpm –V on a specific file. This replaces the md5_differs entity due to naming changes for verification and reporting options. The device_differs entity aligns with the fourth character ('D' flag) in the character string in the output generated by running rpm –V on a specific file. The link_mismatch entity aligns with the fifth character ('L' flag) in the character string in the output generated by running rpm –V on a specific file. The ownership_differs entity aligns with the sixth character ('U' flag) in the character string in the output generated by running rpm –V on a specific file. The group_differs entity aligns with the seventh character ('U' flag) in the character string in the output generated by running rpm –V on a specific file. The mtime_differs entity aligns with the eighth character ('T' flag) in the character string in the output generated by running rpm –V on a specific file. The size_differs entity aligns with the ninth character ('P' flag) in the character string in the output generated by running rpm –V on a specific file. The configuration_file entity represents the configuration file attribute marker that may be present on a file. The documentation_file entity represents the documenation file attribute marker that may be present on a file. The ghost_file entity represents the ghost file attribute marker that may be present on a file. The license_file entity represents the license file attribute marker that may be present on a file. The readme_file entity represents the readme file attribute marker that may be present on a file. The RpmVerifyFileBehaviors complex type defines a set of behaviors that for controlling how the individual files in installed rpms are verified. These behaviors align with the verify-options of the rpm command with the addition of two behaviors that will indicate that a file with a given attribute marker should not be collected. 'nolinkto' when true this behavior means, don't verify symbolic links attribute. 'nomd5' when true this behavior means, don't verify the file md5 attribute. 5.11.1:1.1 Replaced by the nofiledigest RpmVerifyFileBehaviors option. This Behavior has been deprecated and will be removed in version 6.0 of the language. 'nosize' when true this behavior means, don't verify the file size attribute. 'nouser' when true this behavior means, don't verify the file owner attribute. 'nogroup' when true this behavior means, don't verify the file group owner attribute. 'nomtime' when true this behavior means, don't verify the file mtime attribute. 'nomode' when true this behavior means, don't verify the file mode attribute. 'nordev' when true this behavior means, don't verify the file rdev attribute. 'noconfigfiles' when true this behavior means, skip files that are marked with the %config attribute marker. 'noghostfiles' when true this behavior means, skip files that are maked with %ghost attribute marker. 'nofiledigest' when true this behavior means, don't verify the file digest attribute. 'nocaps' when true this behavior means, don't verify the presence of file capabilities. The rpmverifypackage_test is used to verify the integrity of installed RPMs. This test aligns with the rpm -V command for verifying RPMs. It extends the standard TestType as defined in the oval-definitions-schema and one should refer to the TestType description for more information. The required object element references a rpmverifypackage_object and the optional state element specifies the data to check. rpmverifypackage_test rpmverifypackage_object rpmverifypackage_state rpmverifypackage_item - the object child element of an rpmverifypackage_test must reference an rpmverifypackage_object - the state child element of an rpmverifypackage_test must reference an rpmverifypackage_state The rpmverifypackage_object element is used by a rpmverify_test to define a set of RPMs to verify. Each object extends the standard ObjectType as defined in the oval-definitions-schema and one should refer to the ObjectType description for more information. The common set element allows complex objects to be created using filters and set logic. Again, please refer to the description of the set element in the oval-definitions-schema. State referenced in filter for '' is of the wrong type. This is the package name to check. This is the epoch number of the RPM, this is used as a kludge for version-release comparisons where the vendor has done some kind of re-numbering or version forking. For a null epoch (or '(none)' as returned by rpm) the string '(none)' should be used.. This number is not revealed by a normal query of the RPM's information -- you must use a formatted rpm query command to gather this data from the command line, like so. For an already-installed RPM: rpm -q --qf '%{EPOCH}\n' installed_rpm For an RPM file that has not been installed: rpm -qp --qf '%{EPOCH}\n' rpm_file This is the version number of the build. In the case of an apache rpm named httpd-2.0.40-21.11.4.i686.rpm, this value would be 2.0.40. This is the release number of the build, changed by the vendor/builder. This is the architecture for which the RPM was built, like : i386, ppc, sparc, noarch. In the case of an apache rpm named httpd-2.0.40-21.11.4.i686.rpm, this value would be i686. The rpmverifypackage_state element defines the different information that can be used to verify the integrity of installed rpms. This includes the architecture, epoch number, version numbers, verification of variuos attributes of an rpm. Most of this information can be obtained through the rpm function. Please refer to the individual elements in the schema for more details about what each represents. This is the package name to check. This is the epoch number of the RPM, this is used as a kludge for version-release comparisons where the vendor has done some kind of re-numbering or version forking. For a null epoch (or '(none)' as returned by rpm) the string '(none)' should be used.. This number is not revealed by a normal query of the RPM's information -- you must use a formatted rpm query command to gather this data from the command line, like so. For an already-installed RPM: rpm -q --qf '%{EPOCH}\n' installed_rpm For an RPM file that has not been installed: rpm -qp --qf '%{EPOCH}\n' rpm_file This is the version number of the build. In the case of an apache rpm named httpd-2.0.40-21.11.4.i686.rpm, this value would be 2.0.40. This is the release number of the build, changed by the vendor/builder. This is the architecture for which the RPM was built, like : i386, ppc, sparc, noarch. In the case of an apache rpm named httpd-2.0.40-21.11.4.i686.rpm, this value would be i686. This represents the name, epoch, version, release, and architecture fields as a single version string. It has the form "NAME-EPOCH:VERSION-RELEASE.ARCHITECTURE". Note that a null epoch (or '(none)' as returned by rpm) is equivalent to '0' and would hence have the form NAME-0:VERSION-RELEASE.ARCHITECTURE. The dependency_check_passed entity indicates whether or not the dependency check passed. If the dependency check is not performed, due to the 'nodeps' behavior, this entity must not be collected. The digest_check_passed entity indicates whether or not the verification of the package or header digests passed. If the digest check is not performed, due to the 'nodigest' behavior, this entity must not be collected. 5.11 The digest_check_passed entity can not be collected as implemented, and has become irrelevant. This entity has been deprecated and will be removed in version 6.0 of the language. DEPRECATED ELEMENT: ID: The verification_script_successful entity indicates whether or not the verification script executed successfully. If the verification script is not executed, due to the 'noscripts' behavior, this entity must not be collected. The signature_check_passed entity indicates whether or not the verification of the package or header signatures passed. If the signature check is not performed, due to the 'nosignature' behavior, this entity must not be collected. 5.11 The signature_check_passed entity can not be collected as implemented, and has become irrelevant. This entity has been deprecated and will be removed in version 6.0 of the language. DEPRECATED ELEMENT: ID: The RpmVerifyPackageBehaviors complex type defines a set of behaviors that for controlling how installed rpms are verified. These behaviors align with the verify-options of the rpm command. 'nodeps' when true this behavior means, don't verify dependencies of packages. 'nodigest' when true this behavior means, don't verify package or header digests when reading. 5.11 The nodigest behavior has become irrelevant since the element it impacts has been deprecated. This test has been deprecated and will be removed in version 6.0 of the language. DEPRECATED BEHAVIOR: ID: 'noscripts' when true this behavior means, don't execute the %verifyscript scriptlet (if any). 'nosignature' when true this behavior means, don't verify package or header signatures when reading. 5.11 The nosignature behavior has become irrelevant since the element it impacts has been deprecated. This test has been deprecated and will be removed in version 6.0 of the language. DEPRECATED BEHAVIOR: ID: The selinuxboolean_test is used to check the current and pending status of a SELinux boolean. It extends the standard TestType as defined in the oval-definitions-schema and one should refer to the TestType description for more information. The required object element references a selinuxboolean_object and the optional state element references a selinuxboolean_state that specifies the metadata to check. selinuxboolean_test selinuxboolean_object selinuxboolean_state selinuxboolean_item - the object child element of an selinuxboolean_test must reference an selinuxboolean_object - the state child element of an selinuxboolean_test must reference an selinuxboolean_state The selinuxboolean_object element is used by an selinuxboolean_test to define the items to evaluate based on a specified state. State referenced in filter for '' is of the wrong type. The name of the SELinux boolean. The selinuxboolean_state element defines the different information that can be used to evaluate the specified SELinux boolean. This includes SELinux boolean's current and pending status. Please refer to the individual elements in the schema for more details about what each represents. The name of the SELinux boolean. The current_status entity represents the current state of the specified SELinux boolean. The pending_status entity represents the pending state of the specified SELinux boolean. The selinuxsecuritycontext_test is used to check the security context of a file or process on the local system. It extends the standard TestType as defined in the oval-definitions-schema and one should refer to the TestType description for more information. The required object element references a selinuxsecuritycontext_object and the optional state element references a selinuxsecuritycontext_state that specifies the metadata to check. selinuxsecuritycontext_test selinuxsecuritycontext_object selinuxsecuritycontext_state selinuxsecuritycontext_item - the object child element of an selinuxsecuritycontext_test must reference an selinuxsecuritycontext_object - the state child element of an selinuxsecuritycontext_test must reference an selinuxsecuritycontext_state The selinuxsecuritycontext_object element is used by an selinuxsecuritycontext_test to define the security contexts of files and processes to collect from the local system. Each object extends the standard ObjectType as defined in the oval-definitions-schema and one should refer to the ObjectType description for more information. The common set element allows complex objects to be created using filters and set logic. Again, please refer to the description of the set element in the oval-definitions-schema. State referenced in filter for '' is of the wrong type. The filepath element specifies the absolute path for a file on the machine. A directory cannot be specified as a filepath. - the max_depth, recurse, and recurse_direction behaviors are not allowed with a filepath entity - the recurse_file_system behavior MUST not be set to 'defined' when a pattern match is used with a filepath entity. The path element specifies the directory component of the absolute path to a file on the machine. - the recurse_file_system behavior MUST not be set to 'defined' when a pattern match is used with a path entity. - the max_depth behavior MUST not be used when a pattern match is used with a path entity. - the recurse_direction behavior MUST not be used when a pattern match is used with a path entity. - the recurse behavior MUST not be used when a pattern match is used with a path entity. The filename element specifies the name of a file to evaluate. If the xsi:nil attribute is set to true, then the object being specified is the higher level directory object (not all the files in the directory). In this case, the filename element should not be used during collection and would result in the unique set of items being the directories themselves. For example, one would set xsi:nil to true if the desire was to test the attributes or permissions associated with a directory. Setting xsi:nil equal to true is different than using a .* pattern match, which says to collect every file under a given path. - filename entity cannot be empty unless the xsi:nil attribute is set to true or a var_ref is used The pid entity is the process ID of the process. If the xsi:nil attribute is set to true, the process ID shall be the tool's running process. The selinuxsecuritycontext_state element defines the different information that can be used to evaluate the specified SELinux security context. This includes SELinux security context's user, type role, low sensitivity, low category, high sensitivity, high category, raw low sensitivity, raw low category, raw high sensitivity, and raw high category. This state follows the SELinux security context structure: user:role:type:low_sensitivity[:low_category]- high_sensitivity [:high_category]. Please refer to the individual elements in the schema for more details about what each represents. The filepath element specifies the absolute path for a file on the machine. A directory cannot be specified as a filepath. The path element specifies the directory component of the absolute path to a file on the machine. The name of the file. If the xsi:nil attribute is set to true, then the item being represented is the higher directory represented by the path entity. This is the process ID of the process. The user element specifies the SELinux user that either created the file or started the process. The role element specifies the types that a process may transition to (domain transitions). Note that this entity is not relevant for files and will always have a value of object_r. The type element specifies the domain in which the file is accessible or the domain in which a process executes. The low_sensitivity element specifies the current sensitivity of a file or process. The low_category element specifies the set of categories associated with the low sensitivity. The high_sensitivity element specifies the maximum range for a file or the clearance for a process. The high_category element specifies the set of categories associated with the high sensitivity. The rawlow_sensitivity element specifies the current sensitivity of a file or process but in its raw context. The rawlow_category element specifies the set of categories associated with the low sensitivity but in its raw context. The rawhigh_sensitivity element specifies the maximum range for a file or the clearance for a process but in its raw context. The rawhigh_category element specifies the set of categories associated with the high sensitivity but in its raw context. The slackware package info test is used to check information associated with a given Slackware package. It extends the standard TestType as defined in the oval-definitions-schema and one should refer to the TestType description for more information. The required object element references a slackwarepkginfo_object and the optional state element specifies the data to check. slackwarepkginfo_test slackwarepkginfo_object slackwarepkginfo_state slackwarepkginfo_item - the object child element of an slackwarepkginfo_test must reference an slackwarepkginfo_object - the state child element of an slackwarepkginfo_test must reference an slackwarepkginfo_state The slackwarepkginfo_object element is used by a slackware package info test to define the object to be evaluated. Each object extends the standard ObjectType as defined in the oval-definitions-schema and one should refer to the ObjectType description for more information. The common set element allows complex objects to be created using filters and set logic. Again, please refer to the description of the set element in the oval-definitions-schema. A slackware package info object consists of a single name entity that identifies the package being checked. State referenced in filter for '' is of the wrong type. This is the package name to check. The slackwarepkginfo_state element defines the different information that can be used to evaluate the specified package. This includes the version, architecture, and revision. Please refer to the individual elements in the schema for more details about what each represents. This is the package name to check. This is the version number of the package. The systemdunitdependency_test is used to retrieve information about dependencies of a single systemd unit in the form of a list. This list contains all dependencies, including transitive dependencies. For more information see the output generated by systemctl list-dependencies --plain $unit. It extends the standard TestType as defined in the oval-definitions-schema and one should refer to the TestType description for more information. The required object element references a systemdunitdependency_object and the optional state element specifies the data to check. systemdunitdependency_test systemdunitdependency_object systemdunitdependency_state systemdunitdependency_item - the object child element of a systemdunitdependency_test must reference a systemdunitdependency_object - the state child element of a systemdunitdependency_test must reference a systemdunitdependency_state The systemdunitdependency_object element is used by a systemdunitdependency_test to define the specific units to check the dependencies of. Each object extends the standard ObjectType as defined in the oval-definitions-schema and one should refer to the ObjectType description for more information. The common set element allows complex objects to be created using filters and set logic. Again, please refer to the description of the set element in the oval-definitions-schema. State referenced in filter for '' is of the wrong type. The unit entity refers to the full systemd unit name, which has a form of "$name.$type". For example "cupsd.service". This name is usually also the filename of the unit configuration file located in the /etc/systemd/ and /usr/lib/systemd/ directories. The systemdunitdependency_state element holds dependencies of a specific systemd unit. Please refer to the individual elements in the schema for more details about what each represents. The unit entity refers to the full systemd unit name, which has a form of "$name.$type". For example "cupsd.service". This name is usually also the filename of the unit configuration file located in the /etc/systemd/ and /usr/lib/systemd/ directories. The dependency entity refers to the name of a unit that was confirmed to be a dependency of the given unit. The systemdunitproperty_test is used to retrieve information about systemd units in form of properties. For more information see the output generated by systemctl show $unit. It extends the standard TestType as defined in the oval-definitions-schema and one should refer to the TestType description for more information. The required object element references a systemdunitproperty_object and the optional state element specifies the data to check. systemdunitproperty_test systemdunitproperty_object systemdunitproperty_state systemdunitproperty_item - the object child element of a systemdunitproperty_test must reference a systemdunitproperty_object - the state child element of a systemdunitproperty_test must reference a systemdunitproperty_state The systemdunitproperty_object element is used by a systemdunitproperty_test to define the specific unit and property combination to be evaluated. Each object extends the standard ObjectType as defined in the oval-definitions-schema and one should refer to the ObjectType description for more information. The common set element allows complex objects to be created using filters and set logic. Again, please refer to the description of the set element in the oval-definitions-schema. State referenced in filter for '' is of the wrong type. The unit entity refers to the full systemd unit name, which has a form of "$name.$type". For example "cupsd.service". This name is usually also the filename of the unit configuration file located in the /etc/systemd/ and /usr/lib/systemd/ directories. The property entity refers to the systemd unit property that we are interested in. The systemdunitproperty_state element holds information about properties of a specific systemd unit. Please refer to the individual elements in the schema for more details about what each represents. The unit entity refers to the full systemd unit name, which has a form of "$name.$type". For example "cupsd.service". This name is usually also the filename of the unit configuration file located in the /etc/systemd/ and /usr/lib/systemd/ directories. The name of the property associated with a systemd unit. The value of the property associated with a systemd unit. The FileBehaviors complex type defines a number of behaviors that allow a more detailed definition of a set of files or file related items to collect. Note that using these behaviors may result in some unique results. For example, a double negative type condition might be created where an object entity says include everything except a specific item, but a behavior is used that might then add that item back in. It is important to note that the 'max_depth' and 'recurse_direction' attributes of the 'behaviors' element do not apply to the 'filepath' element, only to the 'path' and 'filename' elements. This is because the 'filepath' element represents an absolute path to a particular file and it is not possible to recurse over a file. 'max_depth' defines the maximum depth of recursion to perform when a recurse_direction is specified. A value of '0' is equivalent to no recursion, '1' means to step only one directory level up/down, and so on. The default value is '-1' meaning no limitation. For a 'max_depth' of -1 or any value of 1 or more the starting directory must be considered in the recursive search. Note that the default recurse_direction behavior is 'none' so even though max_depth specifies no limitation by default, the recurse_direction behavior turns recursion off. Note that this behavior only applies with the equality operation on the path entity. 'recurse' defines how to recurse into the path entity, in other words what to follow during recursion. Options include symlinks, directories, or both. Note that a max-depth other than 0 has to be specified for recursion to take place and for this attribute to mean anything. Also note that this behavior does not apply to Windows systems since they do not support symbolic links. On Windows systems the 'recurse' behavior is always equivalent to directories. Note that this behavior only applies with the equality operation on the path entity. 'recurse_direction' defines the direction to recurse, either 'up' to parent directories, or 'down' into child directories. The default value is 'none' for no recursion. Note that this behavior only applies with the equality operation on the path entity. 'recurse_file_system' defines the file system limitation of any searching and applies to all operations as specified on the path or filepath entity. The value of 'local' limits the search scope to local file systems (as opposed to file systems mounted from an external system). The value of 'defined' keeps any recursion within the file system that the file_object (path+filename or filepath) has specified. For example, if the path specified was "/", you would search only the filesystem mounted there, not other filesystems mounted to descendant paths. The value of 'defined' only applies when an equality operation is used for searching because the path or filepath entity must explicitly define a file system. The default value is 'all' meaning to search all available file systems for data collection. Note that in most cases it is recommended that the value of 'local' be used to ensure that file system searching is limited to only the local file systems. Searching 'all' file systems may have performance implications. The EntityStateRpmVerifyResultType complex type restricts a string value to the set of possible outcomes of checking an attribute of a file included in an RPM against the actual value of that attribute in the RPM database. The empty string is also allowed to support the empty element associated with variable references. Note that when using pattern matches and variables care must be taken to ensure that the regular expression and variable values align with the enumerated values. 'pass' indicates that the test passed and is equivalent to the '.' value reported by the rpm -V command. 'fail' indicates that the test failed and is equivalent to a bold charcter in the test result string reported by the rpm -V command. 'not performed' indicates that the test could not be performed and is equivalent to the '?' value reported by the rpm -V command. The empty string value is permitted here to allow for empty elements associated with variable references. The EntityStateProtocolType complex type restricts a string value to the set of physical layer protocols used by AF_PACKET sockets. The empty string is also allowed to support the empty element associated with variable references. Note that when using pattern matches and variables care must be taken to ensure that the regular expression and variable values align with the enumerated values. Ethernet loopback packet. Xerox PUP packet. Xerox PUP Address Transport packet. Internet protocol packet. CCITT X.25 packet. Address resolution packet. G8BPQ AX.25 ethernet packet. Xerox IEEE802.3 PUP packet. Xerox IEEE802.3 PUP address transport packet. DEC assigned protocol. DEC DNA Dump/Load. DEC DNA Remote Console. DEC DNA Routing. DEC LAT. DEC Diagnostics. DEC Customer use. DEC Systems Comms Arch. Reverse address resolution packet. Appletalk DDP. Appletalk AARP. 802.1Q VLAN Extended Header. IPX over DIX. IPv6 over bluebook. Slow Protocol. See 802.3ad 43B. Web-cache coordination protocol. PPPoE discovery messages. PPPoE session messages. MPLS Unicast traffic. MPLS Multicast traffic. MultiProtocol Over ATM. Frame-based ATM Transport over Ethernet. ATA over Ethernet. TIPC. Dummy type for 802.3 frames. Dummy protocol id for AX.25. Every packet. 802.2 frames. Internal only. DEC DDCMP: Internal only Dummy type for WAN PPP frames. Dummy type for PPP MP frames. Dummy type for Atalk over PPP. Localtalk pseudo type. 802.2 frames. Mobitex. Card specific control frames. Linux-IrDA. Acorn Econet. HDLC frames. 1A for ArcNet. The empty string value is permitted here to allow for empty elements associated with variable references.