Add OVAL for Antivirus check

- Add OVAL for Antivirus check
- Enable for RHEL 6 & 7 and Fedora 20
Add OVAL for NFS insecure lock checks

- Add OVAL for NFS insecure lock checks
- Enable for RHEL 6 & 7 and Fedora
[Enhancement] Update Antivirus checks

- Enable for Fedora
- Add XCCDF for Fedora
- Update RHEL 7 XCCDF for antivirus
Merge remote branch 'origin/master' into add_Antivirus_oval
Merge remote branch 'origin/master' into add_NFS_insecure_oval
[Enhancement] Add NFS checks for Fedora

- Enable for Fedora
Update install_antivirus.xml

Fix typo.
Merged master fixed conflict
Remove extra NFS package check

- Remove extra NFS package check criteria in NFS insecure OVAL check.
Remove Fedora NFS package OVAL
[bugfix] [shared/transforms/cpe_generate.py] Fix bug when generating cpe-oval file:

When searching for cpe_variables to be included into final cpe-oval file don't
traverse whole ovaltree for 'var_ref's, but just tree under the 'tests' leaf.
Since otherwise this leads to incorrect non cpe_variables inclusion of local_variables
into final cpe-oval file, leading to datastream build failure.

See e.g: https://lists.fedorahosted.org/pipermail/scap-security-guide/2014-August/006025.html
for further details.
[bugfix] [RHEL/6/input/checks/templates] Provide create_umask_checks.py template
for generating (super-compliance) OVAL umask implementation.

The current OVAL umask checks (e.g. accounts_umask_etc_profile.xml) aren't
super-compliant as they PASS only when system configured (e.g. /etc/profile)
umask exactly matches the requirement.

To be super-compliant the umask OVAL check should PASS also in cases when
system in question is configured to have more strict umask in particular file.
For example, taking /etc/profile as example, the requirement umask to be '002',
then also umasks of the form e.g. '007' or '022' should PASS this requirement
(since 002 in binary form is subset of 007 or 022 in binary form).

The new check is implemented as follows - we first create octal representation
of the value retrieved from the particular config file, then create octal
representation of required value provided in external OVAL variable. At the
end compare the binary representations of these two octal representations via
the 'bitwise and' OVAL operator.

Example:

  Requirement:   002 => 0*64 + 0*8 + 2*1 = 2
  Config value:  007 => 0*64 + 0*8 + 7*1 = 7

Then perform bitwise AND on binary representations of the two:

  R  (in binary):       000 000 010
  CV (in binary):       000 000 111
  ---------------------------------
  bitwise AND           000 000 010

Since bitwise AND result is the same as requirement (in binary) the result
PASSED & corresponding umask is allowed. Computational example of umask
that wouldn't pass this check is left as exercise for the reader.
[bugfix] [RHEL/6, RHEL/7] accounts_umask_etc_profile OVAL check - start using the new OVAL umask template

Testing report:

Checked & confirmed on both of RHEL6 & RHEL7 the proposed change works as expected (=>
moved to shared & equipped with test_attestations). More existing umask checks to be
rewritten to use the new template as soon as they have been tested & confirmed for work.
Update install_antivirus.xml

Use McAfee Linuxshield only to match STIG profile.
Merge pull request #38 from redhatrises/add_NFS_insecure_oval

Add NFS insecure OVAL check
Merge pull request #30 from redhatrises/add_Antivirus_oval

Add OVAL for antivirus check
Merge pull request #52 from iankko/umask_supercompliance

[bugfix] Rewrite existing OVAL umask accounts_umask_etc_profile.xml check to be super-compliant