The rule "unix-def_selinuxsecuritycontext_objectfilepath2" should be renamed to the more accurate "linux-def_selinuxsecuritycontext_objectfilepath2" in oval-definitions-schematron.sch.

n/a

We should add a function for performing bitwise operations (e.g. AND, OR, XOR, and NOT). This function would be similar to the arithmetic function and would make sense for integer and binary data.

Please see the following oval-developer-list post for more information.

http://making-security-measurable.1364806.n2.nabble.com/Bitwise-and-in-OVAL-tp7415374p7415374.html

n/a

Consider deprecating datatype on OVAL Items. Datatype here is not ever used since OVAL is really loosely typed. The only datatype that matters is the datatype specified on the OVAL Object or OVAL State.

n/a

We should further explore the use of a concrete path to specify where a pattern match search should begin rather than relying on optimizations that require the parsing of a regular expression.

Please see the following oval-developer-list post for additional information.

http://making-security-measurable.1364806.n2.nabble.com/Pattern-matching-for-paths-td6718764.html

n/a

We should look into netconf and yang which is a data modeling language for the Network Configuration Protocol (NETCONF).

n/a

We should consider adding ignore_case, single line, and multiline behavior support to the ios:line_test to allow for better processing of the show command output which may contain multiple lines of data.

Please see the following links for additional information.

http://making-security-measurable.1364806.n2.nabble.com/Behavior-proposal-for-line-object-ios-tp6612121p6612121.html

http://www.jaytmedia.com/cisco/ios.html#show

n/a

This topic was discussed on the oval-developer-list here:
Subject: Re: [OVAL-DEVELOPER-LIST] OVAL Malware Artifact Hunting, SCAP and Validation
Date: Wed 7/20/2011 7:36 AM

n/a

Need to be able to enumerate all handles associate with a process. This includes:
 - Sockets (source, dest, sourceport, destport, protocol)
 - Mutants (name)
 - Others: File, Registry, Pipes, etc

Handle information is available via NtQuerySystemInformation (http://msdn.microsoft.com/en-us/library/ms724509(v=vs.85).aspx). Note that the GetProcessHandleCount Function is preferred (http://msdn.microsoft.com/en-us/library/ms683214(v=vs.85).aspx) since it is a supported api.

This request does overlap in part with the Mutex community suggestion, handles could be considered system wide objects outside of the scope of the Process Object.

Details of this request are outlined in the following developer list message:
http://making-security-measurable.1364806.n2.nabble.com/Developer-Days-Artifact-Hunting-Slides-tp6463048p6463048.html
See slide 10.

Date Added: 2011-07-19 14:19:24
This item will be deferred in version 5.10. handle information should be addressed more broadly once there is better community understanding of how this sort of test will be used.

Need to be able to enumerate Loaded Modules associated with a process
 - Access to modules as PE files - EnumProcessModules()

Get the module name with GetModuleFileNameEx Function (http://msdn.microsoft.com/en-us/library/ms683198(v=vs.85).aspx)


Details of this request are outlined in the following developer list message:
http://making-security-measurable.1364806.n2.nabble.com/Developer-Days-Artifact-Hunting-Slides-tp6463048p6463048.html
See slide 11.

Date Added: 2011-07-19 14:28:00
This item will be deferred in version 5.10. Further community discussion around the need to gather and make assertions around module names is needed.

Access to Alternate Data Streams
- May require extension of the File Object in OVAL
- Tool vendors have multiple implementation options, but none are perfect
   - FindFirstStreamW() / FindNextStreamW() available on 2003 and later (http://msdn.microsoft.com/en-us/library/aa364424(v=vs.85).aspx) also see the WIN32_FIND_STREAM_DATA Structure.
   - BackupRead() - performance implications
   - NtQueryInformationFile / ZwQueryInformationFile - undocumented/unsupported


Details of this request are outlined in the following developer list message:
http://making-security-measurable.1364806.n2.nabble.com/Developer-Days-Artifact-Hunting-Slides-tp6463048p6463048.html
See slide 7.

Date Added: 2011-07-19 17:41:30
This item will be deferred in version 5.11. Further community discussion o the need to examine alternate data streams is needed.

Date Added: 2011-07-19 17:57:23
The previous comment should have said that this item will be deferred in version 5.10.

Content based file-type identification
 - Development of a standard set of content types, or
 - Formal OVAL construct for defining custom content types, or
 - Informally defined using byte-pattern tests

Details of this request are outlined in the following developer list message:
http://making-security-measurable.1364806.n2.nabble.com/Developer-Days-Artifact-Hunting-Slides-tp6463048p6463048.html
See slide 7.

Date Added: 2011-07-19 13:25:13
This item will be deferred in version 5.11. Content based file-type detection is currently out of scope for OVAL.

During the SCAP 1.2 discussion at 2011 developer days there was a bit of discussion around the need to differentiate the core constructs of the oval-definitions-schema by both @id and @version essentially treating the two as a composite key. 

This modification could be made to default to the current behavior and then allow for optional identification of specific versions of these things via all reference structures within OVAL. This would include at least:
- criterion references to tests
- test references to objects and states
- extend_definition references to definitions
- and many others

Minimally we need to ensure that there is a better shared understanding of how items are identified in OVAL and the tradeoffs of including the version as part of a composite key.

Date Added: 2011-07-14 15:06:01
This issue has been deferred from version 5.10. it may be considered in a future release. 

We have a few datatypes that are platform-specific and are only used in the corresponding component schemas.  We should consider moving them out of the core schemas and into the appropriate component schemas.  Platform-specific datatypes include:

evr_string (linux)
fileset_revision (hp-ux)
ios_version (cisco ios)

Date Added: 2011-06-27 16:21:01
We will defer this issue to a later release after version 5.10.

Resolving this issue will require a significant refactoring of the schema. The most significant challenge here is supporting the use of platform specific datatypes in variables. One possible solution would be to simply restrict variables to only use primitive datatypes like int, string, boolean, etc. Doing so would be a significant restriction in variable support. 

On the other hand, it is not clear that these platform specific datatypes are ever used in variables. 

The file system type can be collected using "diskutil info <device>".  We should add an fs_type entity for this value.  We should also consider whether or not other information that can be collected using "diskutil info <device>" needs to be collected.

Date Added: 2011-06-07 14:20:09
Is this advocating a partition_test like Linux has? The linux-def:partition_test collects similar info to Mac OS "diskutil info".

The ability to cast entities to a different datatype could be a useful capability when trying to check the state of a system.  We should investigate this topic further.  Please see the following oval-developer-list post for additional information.

http://making-security-measurable.1364806.n2.nabble.com/OVAL-5-8-s-rework-of-the-datatype-attribute-td6099259.html

Date Added: 2011-07-18 11:46:46
This topic was further discussed here:
http://making-security-measurable.1364806.n2.nabble.com/OVAL-Selected-Issues-Entity-Casting-tp6520654p6520654.html

Code signatures are a useful mechanism for verifying the integrity of 
software.  We should investigate the ability to check signed code in OVAL.

Date Added: 2011-03-31 19:09:03
Please see the following oval-developer-list discussion for additional information. 

http://making-security-measurable.1364806.n2.nabble.com/Proposal-for-amending-windows-file-state-to-support-digital-signatures-td6228224.html

Date Added: 2011-05-19 17:47:44
Having examined the code involved with creating a probe to support these changes, I'm concerned that the suggested additions may not be as simple as proposed. It may be difficult to reliably gather the data requested and/or the data gathered perhaps should be more complex - even lending itself to its own test.

I think the spsiteurl object entity and the sitecollectionurl object entity are referring to the same thing; that is, a SPSite object represents a Site Collection.

Overview of the Sharepoint object model:
http://msdn.microsoft.com/en-us/library/ms473633.aspx

These two entity names should be consistent.  Here are the usages for both:

spsiteurl
- splist_object
- spcrawlrule_object

sitecollectionurl:
- spsiteadministration_object
- spsite_object
- bestbet_object
- infopolicycoll_object
- spgroup_object
- spweb_object

This issue if further confused by the fact that the API object name is not exactly the same as the object model name.  In general, we should be consistent in the schema whether we want to use the API object names (prefixed by SP, like "SPSite", "SPWebApplication") or the object model names ("Site Collection", "Web Application").

Date Added: 2010-11-05 16:58:06
Aha, I already brought this up in an email to the team list.  In that email, I mentioned the same problem with SPWeb URLs.  It's worse in fact; I found 3 different names for the same thing :-P  If we add a tracker for SPSite URL entities, we should also add a tracker for SPWeb URL entities.

Date Added: 2011-07-18 18:08:41
Deferring this item in version 5.10 because it is a naming consistency issue that will require new versions of all affected tests. 

In several objects in the sharepoint schema, there is a farmname entity that specifies an SPFarm name.  However, it is not possible to get a SPFarm with only the farm name.  Accessing a SPFarm outside the local scope requires a detailed connection string, with the SPFarm.Open method.  If the user does not have permissions to access the farm, an exception will be thrown:

API: http://msdn.microsoft.com/en-us/library/ms453293.aspx
Example: http://social.msdn.microsoft.com/Forums/en/sharepointdevelopment/thread/e54c5fb2-fd0d-4843-844b-b68ff568c614
"Should be something like: SPFarm farm = SPFarm.Open("Data Source=server.domain.com;Initial Catalog=SharePoint_Config;Integrated Security=SSPI");"

I think accessing a non-local SPFarm (that is, a farm that does not own the current server, or a farm other than SPFarm.Local) may be out of scope for the sharepoint schema.  This depends on the way Sharepoint administration is done, and checking remote machines may not be in scope for the OVAL Interpreter: Is it common for a single user to administrate several Sharepoint Farms?

In the case that the Sharepoint schema applies only to the local farm, the following changes need to be made: the tests need to be rewritten to only apply to the local farm, the farmname (or spfarmname) entity should be removed from the object, and the schema noted that these tests will always gather information from the local farm.  The farmname entity may potentially remain on the state and item, if it is necessary to confirm the farm name.

This issue affects:
spantivirussettings_object
spdiagnosticsservice_object
spdiagnosticslevel_object
sppolicyfeature_object

Date Added: 2010-11-10 22:58:36
After further thought, it is not appropriate for the interpreter running on one machine to attempt to evaluate checks on another machine.  This would be the case even if we only search SPFarm.Local, which could contain multiple servers.  Therefore, the Sharepoint schema should no longer refer to SPFarms, and restrict all checks to the SPServices running on the local machine.

This issue affects:
spantivirussettings_object
spdiagnosticsservice_object
spdiagnosticslevel_object
sppolicyfeature_object

Date Added: 2011-07-18 18:14:43
Deferring this item from version 5.10.

spgroup_object does not properly specify a SPGroup object.  A Sharepoint Web Site (SPWeb) belongs to many Groups, and there are many SPWebs in a SPSite.  The current sitecollectionurl is insufficient to uniquely identify a SPGroup.

I propose the following changes:

1. Add a websiteurl entity to specify the SPWeb
2. Add a groupname entity to specify the SPGroup
3. Rename the "gname" state/item entity to "groupname"

This test is similar to the spweb_test, so they should be developed together.

Relevant API pages:
http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spgroup.aspx
http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spweb.aspx

Date Added: 2011-07-18 18:18:54
This item will be deferred in version 5.10.

The spweb_object has two entities, with the following documentation:

-- webcollectionurl - The webcollectionurl element defines the web application to evaluate specific web settings.

-- sitecollectionurl - The sitecollectionurl element defines the site collection to evaluate specific web settings.


I think the entities should be renamed to (and the corresponding entities changed in the state and item):
  
-- sitecollectionurl – specifies a site collection

-- websiteurl – specifies a web site (this is the SPWeb object we want)

This site outlines the SharePoint object model, and has a nice diagram at the top.  Further down the page is another diagram of the site architecture:
http://msdn.microsoft.com/en-us/library/ms473633.aspx

The important thing to note is that a Site Collection (SPSite object) contains a tree of Web Sites (SPWeb object).

Date Added: 2011-07-18 18:21:24
This item will be deferred in version 5.10.

We should discuss if functions and components, in variables, should really be returning errors or if the errors should be handled at a higher level such as at the entities that reference them through the var_ref attribute.


Please see the following link for more information.

http://making-security-measurable.1364806.n2.nabble.com/OVAL-5-x-documentation-inconsistency-tp5460954.html

Date Added: 2011-07-19 16:51:29
We are still investigating the issues outlined in this tracker and as a result it will be deferred for the OVAL 5.10 release.

when using a schema aware xpath 2.0 processor for evaluating the schematron rules there are several rules that do not work properly. While OVAL uses xpath 1.0 we should make a best effort to ensure that our xpath 1.0 paths work correctly as xpath 2.0 paths whenever possible. 

Date Added: 2011-07-18 18:22:07
This item will be deferred in version 5.10.

This request came out of discussions at the 2010 Security Automation Developer Days. 

Here is a summary of the discussion that explains this optional attribute:

If the assumption can be made that a definition author knows which items are most interesting to report then why not allow the author to highlight or flag those items?

This proposal suggests adding an optional report_value attribute to all State entities. This Boolean attribute would default to false and when true would indicate that the system value(s) should be highlighted or reported in the OVAL Results document. The current behavior would remain unchanged when the report_value attribute is false.

The second component to this proposal is the addition of an <oval-res:observed_value/> element in the existing <oval-res:tested_item/> element. A <oval-res:tested_item/> could have an unbounded set of child <oval-res:observed_value/> elements. Each <oval-res:observed_value/> would hold the name of the reported State entity, the data type observed on the system, and the observed value.

In considering this proposal it is important to note that this is not a complete solution. This solution would work quite well in simple cases, but more complex definition criteria would remain difficult to process and accurately report the underlying cause of a given Definition result. If accepted this proposal would also result in even larger full OVAL Result documents as it would essentially duplicate some of the data that is somewhat buried in an OVAL Results document.

Date Added: 2011-06-29 18:30:43
We started to write this issue up further, but decided to abort it and defer the item for the 5.10 release.  We attached the relevant files (detailing our additional work) here for reference.

>Previously, I have submitted a formal request for inclusion of the XML
>Encryption Standard(XMLENC) into OVAL. I think there is a great amount
>of overlap between XMLENC and MIL-STD-1840C.
>
>I am not sure as to the status of this RFE. However, it should easily
>integrate with OVAL as much of the algorithms coincide with those
>already required and recommended by the XML Digital Signature Standard.
>Which of course is already implemented and included within the OVAL
>Schemas.
>

Thomas, 

Do you think that OVAL needs to change to accommodate XMLENC?  As you mentioned we have explicitly included areas of support for XMLDSig in OVAL. This was done to allow for capabilities that we felt we could not achieve otherwise. Are there similar capabilities that we would gain from by incorporating support for XMLENC into the OVAL Schemas? Or is it adequate to simply allow people to encrypt OVAL content as they see fit? What would you suggest that we change to support XMLENC?

I of course curious to know if others would like to see OVAL support XMLENC, and what specifically is needed.

Date Added: 2010-05-07 19:48:43
Also see:

http://making-security-measurable.1364806.n2.nabble.com/Comments-on-OVAL-5-7-tp4784920p4933167.html

Date Added: 2010-08-02 18:17:56
As of this time there has been little support for adding in XML Encryption in version 5.8. For this reason we are going to defer this request to a later release.

Date Added: 2011-05-11 17:15:35
As of this time there has been little support for adding in XML Encryption in
version 5.10. For this reason we are going to defer this request to a later
release.

With draft 2 of version 5.7 the ability to support n-tuples was introduced. This will allow oval to represent system information for objects that have one or more fields. However, as the capability stands if one of the fields on a system object is yet another object with multiple fields oval cannot support this additional structured field. 

We need to consider whether we want to allow for arbitrarily complex object to be represent and queried through OVAL. Here is an example that we can represent with the changes made to 5.7 draft 2:

object - person
 * field - first name
 * field - last name
 * field - age

Here is an example of what we need to consider supporting that is not supported by the changes in 5.7 draft 2:

object - person
 * field - first name
 * field - last name
 * field - address
   * field - street
   * field - city
   * field - state
   * field - zip

In the example the address field has 4 additional fields that OVAL cannot represent as of version 5.7 draft 2. It remains up for discussion whether or not version 5.7 should support this sort of more complex stricture.

Date Added: 2010-03-10 13:49:05
http://n2.nabble.com/Records-of-Records-tp4618717p4618717.html

all file related objects that have a path entity need to clearly state that a trailing path separator is required when an equality operation is specified. In addition to the documentation fix, a Schematron rule can be added to ensure that when the operation is 'equals' the path entity value ends in a path separator.

Date Added: 2010-01-08 14:19:23
Since there are no restrictions on how a path can be represented, both c:/program files and c:/program files/ are valid.  This ambiguity may lead to equally valid content that is not interoperable with different interpreters.  For example, interpreter A could support paths that do not end it a file separator, interpreter B could support paths that end in a file separator, and interpreter C could support both representations.  As a result, if you were to write content for interpreter A and then run it on interpreter B it would not evaluate to the same results as interpreter A's representation of a path is not supported on interpreter B.  Therefore we need to clearly define how paths should be represented in the language so as to avoid this ambiguity.  This change will also apply to registry keys and metabase keys.

Date Added: 2010-04-21 12:25:12
Would the addition of a path datatype resolve this issue?

Date Added: 2010-08-17 16:14:58
PROBLEM:
Paths are currently treated as strings which leads to incorrect evaluations. This is made worse by the fact that content authors will naturally encode path strings inconsistently. Here are a few examples that demonstrate that paths cannot be thought of as simple strings:
1- /a/b/c == /a/b/c/
2- /a/c == /a/b/../c
3- /a == /b because /a is a symbolic link to /b
...

ISSUES:
1- Each OS has slightly different semantics for a path.
Defining our own path concept will result in a concept that does not align with all operating system notions of a path and will therefore not completely solve our path related issues.

2- Cannot use the native OS concept of a path.
Using the native OS concept of a path is not acceptable because paths need to be compared independent of the native OS. We currently allow a product to collect information on one system and then evaluate the information on another system. If the native OS concept of a path is used we will not be able to support this use case.

3- Regular expressions are widely used to search paths.
For a regular expression to work reliably there must be some standardization of the subject strings. If two different tools collect the same path and represent it differently as a string it is unlikely that most regular expressions will work properly all the time.


Due to the above issues, I think that correcting the handling of paths in OVAL simply does not fit within the bounds of a minor release. It is important to note that this issue was not reported by the community. This issues was discovered by the OVAL team while developing test content. We believe that under normal usage path strings in OVAL are used as inputs to native OS apis. These apis silently accept the varying formats of path string and will successfully collect the expected paths in most cases. This issue with paths is most troublesome when state assertions are made about paths because an observed path is compared to an expected path. This type of assertion is uncommon. Generally paths are used to collect properties about a file (permissions, size, hash, etc). State assertions are normally made about these properties, not the paths themselves.

>Love the idea of an apache config file test for the apache schema!  We
>will have to work on this for version 5.5 though.  My guess is this
>shouldn't be a  problem as we might have some thinking to do on this
>test.
>
>Regarding the proposed object, please note that entities in an object
>can not be optional.  The idea of the object is that these are the
>things that are needed to uniquely identify an object.  So optional
>items don't really fit this bill.  We are thinking about a choice
>structure though for Version 6 for those objects that might be 2
>different ways of uniquely identifying themselves.  For example, users
>can be id'd by name or SID.
>
>Is there a known way to represent the path to a certain block 
>in the file?  For example using slashes:  
>virtualserver/directory/directive.  If not, maybe we can 
>specify one for our object.  How about the following for an object:
>
>filepath
>filename
>block (represented via above)
>directive (this would be nilable)

This would work - it would need several capabilities:
- In addition to specifying VirtualServer, you would need to specify which VirtualServer block was of interest. This is because a single configuration file can have multiple VirtualServer blocks and it is the parameters of the open-tags of these blocks that differentiate them. The same would be true of all the other blocks (File, Directory, Location, etc.)
- The schema and interpreter could make no assumptions about what will be present in a path. The block types do have a proper ordering, but as long as the ordering is preserved, individual blocks can be present or absent from a path. For example:
	virtualserver/directory/file/
      virtualserver/file/
      file
      directory
      directory/file
All of these are legal hierarchical structures relative to the root of an Apache file. (But "file/virtualserver" would not be allowed.) As a corollary, the design would need to make clear whether the path "virtualserver/file" was of equal or greater precision than the path "file". In other words, does the path "file" mean every file block (that met the given parameter value) in the entire config file regardless of the presence of a parent block, or does it only match an appropriately parameterized file block that has no parent block. There are arguments in both directions.
- The schema and interpreter would need to decide what to do with FileMatch, DirectoryMatch, and LocationMatch blocks. These blocks are equivalent to File, Directory, and Location blocks (respectively) but use a regular expression pattern to specify the file/directory/URL rather than a static string.

In addition, I would suggest that a wildcard operator be valid in the path (so you could write checks like "all virtual servers must enable X").

I don't think any of these represents a technical challenge so, in general, I think this should work just fine. I don't know that this path structure is a common way to refer to the hierarchical structure of an Apache file, but it seems pretty simple and I don't think anyone would be confused by it and an interpreter shouldn't have much trouble following it.

Please let me know if you have any questions.

Charles

Date Added: 2011-06-14 15:47:50
This item has been deferred from version 5.10. There is no current community demand for this capability.

The sql_test documentation should be updated to include the conventions that have been put in place by some of the vendors that have started to use this test in the real world.  

This should be added to both the sql_test & the sql57_test.

Date Added: 2011-09-09 17:32:20
Reverting this fix for now until we can better fix the schema.

Allow for multiple occurrences of the protocol entity in the sol-def:smf_state and sol-sc:smf_item as it is possible for a service to have more than one protocol associated with it.

Please see the following oval-developer-list for more information.

http://making-security-measurable.1364806.n2.nabble.com/Question-about-protocol-and-server-arguements-entities-of-smf-state-and-smf-item-tp6065265p6065265.html

n/a

Please see the following oval-developer-list post for additional information.

http://making-security-measurable.1364806.n2.nabble.com/Question-about-the-intended-behavior-of-Windows-User-and-Group-objects-td6717805.html#a6721806

n/a

Do we need to include additional version information entities in Win-def:file_test? There are other version information properties that can be collected as documented in http://msdn.microsoft.com/en-us/library/ms647464(v=VS.85).aspx which include LegalCopyRight, LegalTrademarks, PrivateBuild, SpecialBuild, and others.

n/a

A new hive in Windows 7, HKEY_CURRENT_USER_LOCAL_SETTINGS, is not accounted for in win-def:Entity(Object|State)RegistryHiveType or win-sc:EntityItemRegistryHiveType. Should it be? 

See http://msdn.microsoft.com/en-us/library/ms724836(v=VS.85).aspx, as well as the community content on the same page, which talks about the role of  HKEY_CURRENT_USER_LOCAL_SETTINGS when using roaming profiles within a domain.

n/a

Based on some discussion over the oval-developer-list, it appears that we may need to clarify the documentation of the exec_shield entity.

http://making-security-measurable.1364806.n2.nabble.com/How-to-detecting-execshield-status-for-a-process-RHEL-tp7068301p7068301.html

n/a

We should discuss if we need a test to check for Windows license data.  Please see the following oval-developer-list post for additional information.

http://making-security-measurable.1364806.n2.nabble.com/Accessing-Windows-license-data-tp6769688p6769688.html

n/a

We need to remove the restriction on the key entity, in the win-def:registry_object, that says the name entity must be nilled when the key entity is nilled.  It is possible that hives can contain values (i.e. key is nilled) and because of this restriction, we cannot collect these values at this time.  We should also look at all other instances of this restriction in other objects and make sure that it makes sense.

n/a

While implementing support for the recurse behavior we wondered if OVAL needs a way to collect the target of a symlink. 

Date Added: 2012-03-23 12:12:02
Here are some other suggestions to consider that were posted to oval-developer-list post at the above link.

>I believe that we would all benefit from improved clarity in this part of the >specification in the 5.11 revision.  Probably the best way to do that is to >improve the FileBehaviors specification, having separate attributes governing >whether or not the path or filepath must be canonical or can permit link >traversal, vs. attributes governing recursion.  We should also consider adding >an optional file_item entity that specifies the destination path of a link
>(provided the file is a link).

Date Added: 2012-03-13 19:59:40
Here is another oval-developer-list post on handling symlinks.

http://making-security-measurable.1364806.n2.nabble.com/Question-about-link-traversal-behavior-for-unix-file-object-tp7332883p7332883.html

Date Added: 2011-09-11 18:11:11
The following oval-developer-list post contains related information on this topic.

http://making-security-measurable.1364806.n2.nabble.com/UNIX-Symlink-Capabilities-UNCLASSIFIED-td6158009.html

Date Added: 2012-01-05 18:14:59
Here are some things to do with symlinks:

When the item *is* a symlink (i.e. the last path component is a symlink):

- Collect the immediate target
- Collect the ultimate target (a symlink can point to another symlink which points to...)
- Collect the ultimate and all intermediate targets
- "Absolutize" the immediate or any intermediate targets of the symlink, by resolving that target against the parent symlink's directory

When item is a path to some file which may or may not be a symlink, but which *contains* a symlink as a path component (this is a generalization of the above idea):

- A variant of the above: canonicalize any path to another path which contains no symlinks (or . or ..).  This is also applicable to paths without symlinks (its canonical form will be itself).

Note that these are representational issues regarding paths, not about searching.  Pruning a search when a symlink to a directory is encountered is still a valid thing to do.  But when any file (of any type: link, device, directory, etc) is identified as an item match in any object whatsoever, the path to the file may contain symlinks, and the above representational issues apply.

Here is another one, which is not merely representational:

- Pretend the link *is* the ultimate target, and assign item entities accordingly.

This allows definitions to be totally independent of symlinking.  This could be important, because it might be burdensome under some circumstances, if a definition broke every time a file was replaced with a symlink to somewhere else.  I think one purpose of symlinks is to provide that sort of "illusionary" capability in a filesystem.

This could affect any other entities of the item in question, but for it to make any sense, the path must remain the same (. and .. could still be removed).  Otherwise the illusion is broken.


Date Added: 2012-01-05 18:42:17
Well on second thought, maybe the first 5 bullets would not be merely representational.  Because if you are not preserving the "illusion" as described at the bottom, then in "following" the link to its target, you are switching files.  For example, a link could point to a link owned by someone else.  If you were collecting ownership info, then that will have to change.  But if some of these transformations were implemented as a function (say) that just operates on paths, then all you're doing is monkeying with the path.

I think it depends on how the ideas would integrate into the language.  E.g. during collection you could replace a link with its target, or collect the target in addition to the original link, or if these ideas were implemented in oval functions then those variations on collection wouldn't apply.  Maybe I shouldn't have used the word "Collect" in my bullets above, since I don't know how those ideas would be realized in the language.

The extended_name entity is missing from the linux-def:rpmverifypackage_state. The extended_name entity is present in the linux-sc:rpmverifyfile_item which means the extended_name entity can still be used to map between the linux-def:rpmverifypackage_test and the linux-def:rpmverifyfile_test and linux-def:rpminfo_test.  However, it will not be possible to map between the linux-def:rpminfo_test or linux-def:rpmverifyfile_test and the linux-def:rpmverifypackage_test.  

Date Added: 2012-01-17 16:11:12
This is a duplicate of tracker #32678 which was addressed in Version 5.10.1 Draft 1.  Please see the following link for additional information.

https://developer.mitre.org/gf/project/oval/tracker/?action=TrackerItemEdit&tracker_item_id=32678&start=0

We need to deprecate the digest_check_passed and signature_check_passed entities in the linux-def:rpmverifypackage_test.  They cannot be collected as implemented and there is not a need for them.

n/a

In linux-def:rpminfo_state and rpminfo_item, the example given for identifying the version number is incorrect. 

Under the version property, the documentation states that "in the case of an apache rpm named httpd-2.0.40-21.11.4.i686.rpm, this value would be 21.11.4."

The value for the version should be 2.0.40 and the value for the release should be 21.11.4. 

See http://www.rpm.org/max-rpm/ch-rpm-file-format.html for an explanation:

"While RPM will run just as well if a package file has been renamed, when the packages are created during RPM's build process, they follow a specific naming convention. The convention is:

name-version-release.architecture.rpm 

where:

name is a name describing the packaged software.

version is the version of the packaged software.

release is the number of times this version of the software has been packaged.

architecture is a shorthand name describing the type of computer hardware the packaged software is meant to run on. It may also be the string src, or nosrc. Both of these strings indicate the file is an RPM source package. The nosrc string means that the file contains only package building files, while the src string means the file contains the necessary package building files and the software's source code."

Note that version and release can follow a decimal format but cannot contain any dashes.

n/a

We should look into CPE as a way to specify the engine entity in the sql-based tests.  Right now, the engine entity is just an enumeration of values that will need to be added to over time.  Using CPE to specify the engine would give us the flexibility to expand as new engines come out while at the same time maintaining our ability to validate the value of the entity. 

n/a

We need to clarify the documentation in the sql-based tests.  Some areas for improvement are:

*Include a recommendation that tools use read-only database connections to prevent changes from being made to the database.

*Any query that does not change the state of the database is allowed as long as it satisfies the requirements of the test (e.g. sql_object can only collect a single field).

n/a

We should see if it is possible to query MAP in the TNC architecture. Since MAP is a database, maybe the ind-def:sql57_test can be used to retreive this information or if a new test is needed.

n/a