when is dual ARCH required in audit.rules?
by Robert Jacobson
I've recently been trying to reconcile the audit.rules on my systems vs.
the scap-security-guide, and I'm confused about the ARCH rules.
When is it required to check both 32- and 64-bit architectures?
e.g. the guide says both 32- and 64-bit rules are required to check for
unauthorized access attempts:
# Unauthorized Access attempts (audit_rules_unsuccessful_file_modification)
-a always,exit -F arch=b32 -S creat -S open -S openat -S
open_by_handle_at -S truncate -S ftruncate -F exit=-EACCES -F auid>=500
-F auid!=4294967295 -k access
-a always,exit -F arch=b32 -S creat -S open -S openat -S
open_by_handle_at -S truncate -S ftruncate -F exit=-EPERM -F auid>=500
-F auid!=4294967295 -k access
-a always,exit -F arch=b64 -S creat -S open -S openat -S
open_by_handle_at -S truncate -S ftruncate -F exit=-EACCES -F auid>=500
-F auid!=4294967295 -k access
-a always,exit -F arch=b64 -S creat -S open -S openat -S
open_by_handle_at -S truncate -S ftruncate -F exit=-EPERM -F auid>=500
-F auid!=4294967295 -k access
But for modifying the network environment, only the 64-bit rule is required:
# Network changes ( audit_rules_networkconfig_modification )
-a always,exit -F arch=b64 -S sethostname -S setdomainname -k
audit_rules_networkconfig_modification
I don't understand why the 32-bit check is required for open() calls but
not sethostname() calls?
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Robert Jacobson Robert.C.Jacobson(a)nasa.gov
Lead System Admin Solar Dynamics Observatory (SDO)
Bldg 14, E222 (301) 286-1591
8 years, 4 months
[PATCH 1/1] Update LUKS Disk encryption URL
by Steve Grubb
The link to the advice on how to setup a LUKS encrypted partition points to
the wrong place. This patch corrects the link so that clicking the link takes
you to the text.
Signed-off-by: sgrubb <sgrubb(a)redhat.com>
---
RHEL/6/input/system/software/disk_partitioning.xml | 2 +-
shared/references/disa-stig-rhel6-v1r5-xccdf-manual.xml | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/RHEL/6/input/system/software/disk_partitioning.xml b/RHEL/6/input/system/software/disk_partitioning.xml
index 521003e..677b446 100644
--- a/RHEL/6/input/system/software/disk_partitioning.xml
+++ b/RHEL/6/input/system/software/disk_partitioning.xml
@@ -148,7 +148,7 @@ installer to pause and interactively ask for the passphrase during installation.
<br /><br />
Detailed information on encrypting partitions using LUKS can be found on
the Red Hat Documentation web site:<br />
-https://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/sect-Security_Guide-LUKS_Disk_Encryption.html
+https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/chap-Security_Guide-Encryption.html#sect-Security_Guide-LUKS_Disk_Encryption
</description>
<ocil clause="encryption must be used and is not employed">
Determine if encryption must be used to protect data on the system.
diff --git a/shared/references/disa-stig-rhel6-v1r5-xccdf-manual.xml b/shared/references/disa-stig-rhel6-v1r5-xccdf-manual.xml
index aeba70b..c9d362b 100644
--- a/shared/references/disa-stig-rhel6-v1r5-xccdf-manual.xml
+++ b/shared/references/disa-stig-rhel6-v1r5-xccdf-manual.xml
@@ -9698,7 +9698,7 @@ part / --fstype=ext3 --size=100 --onpart=hda1 --encrypted --passphrase=[PASSPHRA
Any [PASSPHRASE] is stored in the Kickstart in plaintext, and the Kickstart must then be protected accordingly. Omitting the "--passphrase=" option from the partition definition will cause the installer to pause and interactively ask for the passphrase during installation.
Detailed information on encrypting partitions using LUKS can be found on the Red Had Documentation web site:
-https://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/sect-Security_Guide-LUKS_Disk_Encryption.html</fixtext>
+https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/chap-Security_Guide-Encryption.html#sect-Security_Guide-LUKS_Disk_Encryption</fixtext>
<fix id="F-43609r1_fix"/>
<check system="C-46220r1_chk">
<check-content-ref name="M" href="DPMS_XCCDF_Benchmark_RHEL_6_STIG.xml"/>
@@ -9764,7 +9764,7 @@ part / --fstype=ext3 --size=100 --onpart=hda1 --encrypted --passphrase=[PASSPHRA
Any [PASSPHRASE] is stored in the Kickstart in plaintext, and the Kickstart must then be protected accordingly. Omitting the "--passphrase=" option from the partition definition will cause the installer to pause and interactively ask for the passphrase during installation.
Detailed information on encrypting partitions using LUKS can be found on the Red Had Documentation web site:
-https://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/sect-Security_Guide-LUKS_Disk_Encryption.html</fixtext>
+https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/chap-Security_Guide-Encryption.html#sect-Security_Guide-LUKS_Disk_Encryption</fixtext>
<fix id="F-43610r1_fix"/>
<check system="C-46221r1_chk">
<check-content-ref name="M" href="DPMS_XCCDF_Benchmark_RHEL_6_STIG.xml"/>
@@ -9799,7 +9799,7 @@ part / --fstype=ext3 --size=100 --onpart=hda1 --encrypted --passphrase=[PASSPHRA
Any [PASSPHRASE] is stored in the Kickstart in plaintext, and the Kickstart must then be protected accordingly. Omitting the "--passphrase=" option from the partition definition will cause the installer to pause and interactively ask for the passphrase during installation.
Detailed information on encrypting partitions using LUKS can be found on the Red Had Documentation web site:
-https://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/sect-Security_Guide-LUKS_Disk_Encryption.html</fixtext>
+https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/chap-Security_Guide-Encryption.html#sect-Security_Guide-LUKS_Disk_Encryption</fixtext>
<fix id="F-43611r1_fix"/>
<check system="C-46222r1_chk">
<check-content-ref name="M" href="DPMS_XCCDF_Benchmark_RHEL_6_STIG.xml"/>
--
2.4.3
8 years, 5 months
[PATCH 1/1] Wrong SE Linux type used
by Steve Grubb
During a recent review, it was found that the text written did not use the
correct selinux type. This means it will not find the system problem that
the text was describing.
Signed-off-by: sgrubb <sgrubb(a)redhat.com>
---
Fedora/input/system/selinux.xml | 9 ++++-----
RHEL/6/input/checks/selinux_all_devicefiles_labeled.xml | 10 +++++-----
RHEL/6/input/system/selinux.xml | 7 +++----
RHEL/7/input/system/selinux.xml | 5 ++---
shared/references/disa-stig-rhel6-v1r5-xccdf-manual.xml | 6 +++---
5 files changed, 17 insertions(+), 20 deletions(-)
diff --git a/Fedora/input/system/selinux.xml b/Fedora/input/system/selinux.xml
index f0e234b..f837dba 100644
--- a/Fedora/input/system/selinux.xml
+++ b/Fedora/input/system/selinux.xml
@@ -167,17 +167,16 @@ or allow privileges that the daemon does not require.
</Rule>
<Rule id="selinux_all_devicefiles_labeled">
-<title>Ensure No Device Files are Unlabeled by SELinux</title>
+<title>Ensure No Device Files are Unknown to SELinux</title>
<description>Device files, which are used for communication with important
system resources, should be labeled with proper SELinux types. If any device
-files carry the SELinux type <tt>unlabeled_t</tt>, investigate the cause and
-correct the file's context.
+files carry the SELinux type <tt>device_t</tt>, report the bug so that policy can be corrected. Supply information about what the device is and what programs use it.
</description>
-<ocil clause="there is output">To check for unlabeled device files, run the following command:
+<ocil clause="there is output">To check for unknown device files, run the following command:
<pre>$sudo find /dev -context *:device_t:* \( -type c -o -type b \) -printf "%p %Z\n"</pre>
It should produce no output in a well-configured system.</ocil>
<rationale>
-If a device file carries the SELinux type <tt>unlabeled_t</tt>, then SELinux
+If a device file carries the SELinux type <tt>device_t</tt>, then SELinux
cannot properly restrict access to the device file.
</rationale>
<!--oval id="selinux_all_devicefiles_labeled" /-->
diff --git a/RHEL/6/input/checks/selinux_all_devicefiles_labeled.xml b/RHEL/6/input/checks/selinux_all_devicefiles_labeled.xml
index 3e99347..094225f 100644
--- a/RHEL/6/input/checks/selinux_all_devicefiles_labeled.xml
+++ b/RHEL/6/input/checks/selinux_all_devicefiles_labeled.xml
@@ -5,23 +5,23 @@
<affected family="unix">
<platform>Red Hat Enterprise Linux 6</platform>
</affected>
- <description>All device files in /dev should be assigned an SELinux security context other than 'unlabeled_t'.</description>
+ <description>All device files in /dev should be assigned an SELinux security context other than 'device_t'.</description>
</metadata>
<criteria>
- <criterion comment="unlabeled_t in /dev" test_ref="test_selinux_all_devicefiles_labeled" />
+ <criterion comment="device_t in /dev" test_ref="test_selinux_all_devicefiles_labeled" />
</criteria>
</definition>
- <linux:selinuxsecuritycontext_test check="none satisfy" check_existence="any_exist" comment="unlabeled_t in /dev" id="test_selinux_all_devicefiles_labeled" version="2">
+ <linux:selinuxsecuritycontext_test check="none satisfy" check_existence="any_exist" comment="device_t in /dev" id="test_selinux_all_devicefiles_labeled" version="2">
<linux:object object_ref="object_selinux_all_devicefiles_labeled" />
<linux:state state_ref="state_selinux_all_devicefiles_labeled" />
</linux:selinuxsecuritycontext_test>
- <linux:selinuxsecuritycontext_object comment="unlabeled_t in /dev" id="object_selinux_all_devicefiles_labeled" version="1">
+ <linux:selinuxsecuritycontext_object comment="device_t in /dev" id="object_selinux_all_devicefiles_labeled" version="1">
<linux:behaviors recurse_direction="down" />
<linux:path>/dev</linux:path>
<linux:filename operation="pattern match">^.*$</linux:filename>
<filter action="include">state_selinux_all_devicefiles_labeled</filter>
</linux:selinuxsecuritycontext_object>
<linux:selinuxsecuritycontext_state comment="do it" id="state_selinux_all_devicefiles_labeled" version="1">
- <linux:type datatype="string" operation="equals">unlabeled_t</linux:type>
+ <linux:type datatype="string" operation="equals">device_t</linux:type>
</linux:selinuxsecuritycontext_state>
</def-group>
diff --git a/RHEL/6/input/system/selinux.xml b/RHEL/6/input/system/selinux.xml
index 5118427..e54f6ef 100644
--- a/RHEL/6/input/system/selinux.xml
+++ b/RHEL/6/input/system/selinux.xml
@@ -191,17 +191,16 @@ or allow privileges that the daemon does not require.
</Rule>
<Rule id="selinux_all_devicefiles_labeled">
-<title>Ensure No Device Files are Unlabeled by SELinux</title>
+<title>Ensure No Device Files are Unknown to SELinux</title>
<description>Device files, which are used for communication with important
system resources, should be labeled with proper SELinux types. If any device
-files carry the SELinux type <tt>unlabeled_t</tt>, investigate the cause and
-correct the file's context.
+files carry the SELinux type <tt>device_t</tt>, report the bug so that policy can be corrected. Supply information about what the device is and what programs use it.
</description>
<ocil clause="there is output">To check for unlabeled device files, run the following command:
<pre>$ sudo find /dev -context *:device_t:* \( -type c -o -type b \) -printf "%p %Z\n"</pre>
It should produce no output in a well-configured system.</ocil>
<rationale>
-If a device file carries the SELinux type <tt>unlabeled_t</tt>, then SELinux
+If a device file carries the SELinux type <tt>device_t</tt>, then SELinux
cannot properly restrict access to the device file.
</rationale>
<ident cce="26774-0" stig="RHEL-06-000025" />
diff --git a/RHEL/7/input/system/selinux.xml b/RHEL/7/input/system/selinux.xml
index 98d5b83..ed3896a 100644
--- a/RHEL/7/input/system/selinux.xml
+++ b/RHEL/7/input/system/selinux.xml
@@ -177,14 +177,13 @@ or allow privileges that the daemon does not require.
<title>Ensure No Device Files are Unlabeled by SELinux</title>
<description>Device files, which are used for communication with important
system resources, should be labeled with proper SELinux types. If any device
-files carry the SELinux type <tt>unlabeled_t</tt>, investigate the cause and
-correct the file's context.
+files carry the SELinux type <tt>device_t</tt>, report the bug so that policy can be corrected. Supply information about what the device is and what programs use it.
</description>
<ocil clause="there is output">To check for unlabeled device files, run the following command:
<pre>$sudo find /dev -context *:device_t:* \( -type c -o -type b \) -printf "%p %Z\n"</pre>
It should produce no output in a well-configured system.</ocil>
<rationale>
-If a device file carries the SELinux type <tt>unlabeled_t</tt>, then SELinux
+If a device file carries the SELinux type <tt>device_t</tt>, then SELinux
cannot properly restrict access to the device file.
</rationale>
<ident cce="27326-8" />
diff --git a/shared/references/disa-stig-rhel6-v1r5-xccdf-manual.xml b/shared/references/disa-stig-rhel6-v1r5-xccdf-manual.xml
index aeba70b..24feac9 100644
--- a/shared/references/disa-stig-rhel6-v1r5-xccdf-manual.xml
+++ b/shared/references/disa-stig-rhel6-v1r5-xccdf-manual.xml
@@ -11306,7 +11306,7 @@ If it does not, this is a finding. </check-content>
<Rule id="SV-65589r1_rule" severity="low" weight="10.0">
<version>RHEL-06-000025</version>
<title>All device files must be monitored by the system Linux Security Module.</title>
- <description><VulnDiscussion>If a device file carries the SELinux type "unlabeled_t", then SELinux cannot properly restrict access to the device file. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls></description>
+ <description><VulnDiscussion>If a device file carries the SELinux type "device_t", then SELinux cannot properly restrict access to the device file. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls></description>
<reference>
<dc:title>DPMS Target Red Hat 6</dc:title>
<dc:publisher>DISA FSO</dc:publisher>
@@ -11315,13 +11315,13 @@ If it does not, this is a finding. </check-content>
<dc:identifier>2367</dc:identifier>
</reference>
<ident system="http://iase.disa.mil/cci">CCI-000366</ident>
- <fixtext fixref="F-56179r1_fix">Device files, which are used for communication with important system resources, should be labeled with proper SELinux types. If any device files carry the SELinux type "unlabeled_t", investigate the cause and correct the file's context. </fixtext>
+ <fixtext fixref="F-56179r1_fix">Device files, which are used for communication with important system resources, should be labeled with proper SELinux types. If any device files carry the SELinux type "device_t", report the bug so that policy can be corrected. Supply information about what the device is and what programs use it. </fixtext>
<fix id="F-56179r1_fix"/>
<check system="C-53719r1_chk">
<check-content-ref name="M" href="DPMS_XCCDF_Benchmark_RHEL_6_STIG.xml"/>
<check-content>To check for unlabeled device files, run the following command:
-# ls -RZ /dev | grep unlabeled_t
+# ls -RZ /dev | grep device_t
It should produce no output in a well-configured system.
--
2.4.3
8 years, 5 months
SCAP Security Guide 0.1.26 is now available for download
by Jan Lieskovsky
Hello folks,
we are pleased to announce the latest 0.1.26 version of the SCAP
Security Guide project is now available for download.
Highlights include:
* New OS Protection Profile for Red Hat Enterprise Linux 7 Server,
* PCI-DSS profile implementation (all OVALs, remediations, and official ID mappings)
for Red Hat Enterprise Linux 7 Server finished,
* Remediation scripts now support multi_platform tags
(replacement for former use of symbolic links),
* The version of SCAP Security Guide is now included in
the RHEL/5, RHEL/6, RHEL/7, Chromium, Fedora, JRE, RHEVM3, Webmin, and Firefox benchmarks,
* Numerous XCCDF, OVAL, and remediation scripts enhancements and bug fixes
For a more detailed list of XCCDF / OVAL / remediations / infrastructure changes
(bug fixes and enhancements) please check the 0.1.26 release notes page:
[1] https://github.com/OpenSCAP/scap-security-guide/releases/tag/v0.1.26
For a convenience provided are also Zip archives of the both versions of the new release.
Be sure to check them out:
* https://github.com/OpenSCAP/scap-security-guide/releases/download/v0.1.26...
contains collection of DataStream formatted benchmarks for most recent OVAL-5.11 language version, while
* https://github.com/OpenSCAP/scap-security-guide/releases/download/v0.1.26...
contains collection of DataStream formatted benchmarks produced for OVAL-5.10 language version.
Should you experience an issue with any of these, please report here or at:
[2] https://github.com/OpenSCAP/scap-security-guide/issues/new
Many thanks to all of the contributors who have made this new release possible!
Happy hardening, Jan
--
Jan iankko Lieskovsky (on behalf of the SCAP Security Guide upstream team)
8 years, 5 months
Re: [Open-scap] Contribution to OpenSCAP with Jenkins - blogpost
by Jan Lieskovsky
Hello Zbynek,
----- Original Message -----
> From: "Zbynek Moravec" <zmoravec(a)redhat.com>
> To: open-scap-list(a)redhat.com
> Sent: Tuesday, October 20, 2015 11:12:25 AM
> Subject: [Open-scap] Contribution to OpenSCAP with Jenkins - blogpost
>
> Hello,
>
> I have written short blog post which should gives you some basic information
> about
> testing of pull requests to OpenSCAP/SSG with Jenkins.
>
> https://blog-zbynek.rhcloud.com/2015/10/12/contribution-to-openscap-with-...
>
> Feedback is welcome.
Very nice!, adding SSG mailing list to the CC too (for wider audience).
Thank you && Regards, Jan
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team
>
> Zbyněk Moravec
> Security Technologies | Red Hat, Inc.
>
> _______________________________________________
> Open-scap-list mailing list
> Open-scap-list(a)redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list
8 years, 5 months
Insight into release timing of RHEL7 STIG as "official" -- any help needed on the Project?
by Jeffrey Hawkins
Anyone have any insight on when the RHEL7 STIG is going to be ready for prime time to be picked up by DISA? I work for a company the delivers RHEL based Products that use the STIG as part of the Security Standards /Benchmark to follow, and right now we are middle of development cycle of migrating our Products from RHEL6 to RHEL7. We are leveraging existing RHEL6 STIG, and the early RHEL7 drafts where it make sense within our own Hardening Framework (developed and carried forward from pre-RHEL4 days). We would like to avoid what we faced with RHEL6 with chasing the Draft verses RHEL5 STIG, and speculating what would be in the final . So, thought I would raise a query of the Benchmark rollout...
Are there areas where help is needed as I/we would be more than happy to help the Project?
Thanks,
Jeff
8 years, 5 months
SCAP Evaluation of Virtual Machines
by Martin Preisler
I have written a script called `oscap-vm` that allows users to
evaluate virtual machines and their images. It does not require
oscap to be installed inside the virtual machine so it performs
the so called "agent-less" SCAP evaluation. The script will be
part of the next OpenSCAP 1.2.7 release.
When evaluating it mounts the virtual machine storage in read-only
mode and then performs offline oscap evaluation on it. I made
the CLI syntax similar to oscap-ssh and oscap-docker so it should
feel very familiar.
It is possible to scan virtual machines that are powered off but
you can also scan virtual machines while they are running with
no risk of data loss!
Examples:
$ wget http://www.redhat.com/security/data/oval/Red_Hat_Enterprise_Linux_7.xml
$ oscap-vm domain rhel7.2 oval eval Red_Hat_Enterprise_Linux_7.xml
$ oscap-vm domain rhel7.2 xccdf eval --profile \
xccdf_org.ssgproject.content_profile_stig-rhel7-server-upstream \
/usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml
$ oscap-vm image /var/lib/libvirt/images/rhel7.2.qcow2 xccdf eval --profile \
xccdf_org.ssgproject.content_profile_stig-rhel7-server-upstream \
/usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml
Read more:
http://martin.preisler.me/2015/10/evaluate-virtual-machines-for-scap-comp...
https://github.com/OpenSCAP/openscap/pull/175
https://github.com/OpenSCAP/openscap/blob/maint-1.2/utils/oscap-vm.8
--
Martin Preisler
Security Technologies | Red Hat, Inc.
8 years, 5 months
Memory allocation errors on RHEL6
by Chuck Atkins
I just did a fresh install of RHEL6, with minimal desktop configuration,
applied all updates, and installed scap-security-guide, openscap, and
scap-workbench from the system repos. First I created a tailoring file
with SCAP Workbench to adjust the STIG server profile for desktop usage
(allow X, remove various server packages, etc.). The scan worked fine but
when generating the results and report, I get a bunch of memory allocation
errors. When I tried to evaluate from the command line instead, using the
tailoring file from scap-workbench, I get:
[root@rhel6-stig-vm ~]# oscap xccdf eval \
--tailoring-file ssg-rhel6-kw-desktop-xccdf.xml \
--profile xccdf_kitware.com_profile_stig-rhel6-server-upstream_desktop \
--report ssg-report.html --results ssg-results.xml \
--check-engine-results --oval-results \
/usr/share/xml/scap/ssg/content/ssg-rhel6-ds.xml
...
all benchmark rules process
...
XPath error : Memory allocation failed : growing nodeset hit limit
growing nodeset hit limit
^
runtime error: file /usr/share/openscap/xsl/xccdf-report-oval-details.xsl
line 39 element key
Failed to evaluate the 'match' expression.
(error repeated 4 times)
The RPMs installed as reported by yum are:
openscap-utils.x86_64 1.2.4-1.el6_6sat
@rhel-6-workstation-satellite-tools-6.1-rpms
scap-security-guide.noarch 0.1.21-3.el6
@rhel-6-workstation-rpms
[root@rhel6-stig-vm ~]#
Interestingly, I don't seem to get these memory errors when I run against
the xccdf directly and not the combined datastream, but then I can't use
the tailoring file I created. Any ideas on the memory errors?
- Chuck
8 years, 5 months