no_files_unowned_by_group rule issue

Kordell, Luke T luke.t.kordell at lmco.com
Mon Jul 7 14:57:58 UTC 2014


Rodney, 

     Thank you for the info, I'll have to look into this myself. For me it's reports files that are owned by root and misses all the actual unowned files, so as far as I can tell it's completely broken. I would be interested to know what results others are getting. 

Luke Kordell 
________________________________________
From: scap-security-guide-bounces at lists.fedorahosted.org [scap-security-guide-bounces at lists.fedorahosted.org] on behalf of Mercer, Rodney [rmercer at harris.com]
Sent: Friday, July 04, 2014 11:11 AM
To: SCAP Security Guide
Subject: EXTERNAL: RE: no_files_unowned_by_group rule issue

Luke,
Yes, the no_files_unowned_by_group has been broken since it's inception.
I took a stab at fixing it a while back, but have not been able to get back to it.
https://lists.fedorahosted.org/pipermail/scap-security-guide/2014-May/005408.html

Also, I have seen that Rui Pedro Bernardino worked on it back on june 2, but I have not seen that his worked has been pushed.
https://www.mail-archive.com/scap-security-guide@lists.fedorahosted.org/msg05180.html

Regards,
Rodney.
________________________________________
From: scap-security-guide-bounces at lists.fedorahosted.org [scap-security-guide-bounces at lists.fedorahosted.org] on behalf of Kordell, Luke T [luke.t.kordell at lmco.com]
Sent: Wednesday, July 02, 2014 5:47 PM
To: scap-security-guide at lists.fedorahosted.org
Subject: no_files_unowned_by_group rule issue

Hello,

     I have been having an issue with the no_files_unowned_by_group rule. I am running scans on both a local system and a remote vm and both systems are failing. The OVAL output for the local system suggests that five root-owned files are causing the failure. In actuality these files are root:root.  When I run a find / -xdev -nogroup -print I receive a slew of files that really do not have group ownership. Initially I wrote this off as a simple oval-output error, however my vm also fails the check and has no group-unowned files. The oval output for that failed-rule indicates that a single root-owned file (/.autofsk) is responsible for the failure. Is there a known-issue with this rule?

Failed files on Local System

//console.txt
//.Xauthority
//.autofsk
//rootk
//ansys_inc

Failed Files on VM

//.autofsk

Luke K
--
SCAP Security Guide mailing list
scap-security-guide at lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
https://github.com/OpenSCAP/scap-security-guide/
--
SCAP Security Guide mailing list
scap-security-guide at lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
https://github.com/OpenSCAP/scap-security-guide/


More information about the scap-security-guide mailing list