Wunnerful... The /var/log/gdm issue is because the spec file has /var/log/gdm as a directory with 755 owned by root:root, but it looks like the executable is 'adjusting' this to be 770 (plus sticky, so 1770) with root:gdm.  Ignoring the sticky bit, 770 is more permissive than 755 (group write).  Stickybit I would submit is more secure than not, and perhaps SGID, but not SUID.  Thoughts?

-Rob


From: Robert Sanders
Sent: Monday, July 08, 2013 4:15 PM
To: scap-security-guide@lists.fedorahosted.org
Subject: Questions about rpm verification

Greeting everyone,
  Just had some questions related to the rpm verification items in the RHEL6 STIG.

1) How are people handling 3rd party software that isn't installed from a yum repo? 

2) On my RHEL6.4 VM I ran an 'rpm -Va' right after I installed the system, and received the following output:
S.5....T.  c /etc/maven/maven2-depmap.xml
..5....T.    /usr/share/ibus-table/tables/compose.db
..5....T.    /usr/share/ibus-table/tables/latex.db
SM5....T.  c /etc/sysconfig/rhn/up2date
.M....G..    /var/log/gdm
.M.......    /var/run/gdm
missing     /var/run/gdm/greeter
..5....T.  c /usr/lib/security/classpath.security
..5....T.  c /etc/inittab
S.5....T.    /usr/share/texmf/web2c/updmap.cfg
....L....  c /etc/pam.d/fingerprint-auth
....L....  c /etc/pam.d/password-auth
....L....  c /etc/pam.d/smartcard-auth
....L....  c /etc/pam.d/system-auth
S.5....T.  c /etc/rsyslog.conf

So this shows there are 6 'issues' to be dealt with since we can ignore the config issues (c).  Most of these are non-issues so far as I can see, due to files being rebuilt/tweaked during install or known transient files, and could be avoided if the owning rpms labeled the files as configuration files perhaps. 

-Rob