add a new Apache config file test

[djhaynes]

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

[djhaynes]

This item has been deferred from version 5.10. There is no current community
demand for this capability

[djhaynes]

This item has been deferred from version 5.10. There is no current community
demand for this capability.

[djhaynes]

This also aligns with #19.

[blakefrantz]

+1 for Apache HTTP Server and Apache Tomcat support in OVAL.