Configuration testing vs Forensic testing

Jan Lieskovsky jlieskov at redhat.com
Fri Oct 31 16:51:04 UTC 2014


----- Original Message -----
> From: "Steve Grubb" <sgrubb at redhat.com>
> To: scap-security-guide at lists.fedorahosted.org
> Sent: Friday, October 31, 2014 3:55:29 PM
> Subject: Re: Configuration testing vs Forensic testing
> 
> On Friday, October 31, 2014 10:47:37 AM Shawn Wells wrote:
> > On 10/31/14, 10:31 AM, Steve Grubb wrote:
> > > I think there is a problem in the SSG content. I think that the current
> > > content is intended to check the system configuration. This would be done
> > > by examining the files on disk to warn about changes or thing that are
> > > misconfigured. There is also another category of testing that is
> > > forensics which checks the ephemeral / current values being enforced.
> > > Both are necessary and useful, but they should not be mixed.
> 
> <snip>
> 
> > I've opened tickets to track mount vs fstab, sysctl, and service vs
> > chkconfig:
> 
> Thanks!
> 
> > As/if you identify additional sections which need better separation,
> > please bring them to our attention!
> 
> Well, in a very brief look, the selinux label check in /dev is wrong, it
> should be:
> 
> find /dev -context *:device_t:* \( -type c -o -type b \)

Just out-of-curiosity this doesn't seem to be working properly (or
I am missing something obvious) [*]. E.g. sample output from RHEL-6 system:

[root at localhost ~]# cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 6.6 (Santiago)
[root at localhost ~]# ls -Z /dev/null
crw-rw-rw-. root root system_u:object_r:null_device_t:s0 /dev/null
[root at localhost ~]# chcon -t samba_share_t /dev/null
[root at localhost ~]# ls -Z /dev/null
crw-rw-rw-. root root system_u:object_r:samba_share_t:s0 /dev/null
[root at localhost ~]# find /dev -context *:device_t:* \( -type c -o -type b \)
[root at localhost ~]# find /dev -context *:device_t:* \( -type c -o -type b \) | wc -l
0

Shouldn't it be changed to e.g.:

  find /dev ! -context *\:*device_t\:* \( -type c -o -type b \)

to get the list of devices that are not of :*_device_t: target?

Wondering, because while trying the changed form, getting (/dev/zero
has been changed before this cut&paste output yet):

[root at localhost ~]# find /dev ! -context *\:*device_t\:* \( -type c -o -type b \) 
/dev/mapper/control
/dev/btrfs-control
/dev/pts/3
/dev/pts/2
/dev/pts/1
/dev/pts/0
/dev/pts/ptmx
/dev/ptmx
/dev/tty
/dev/snapshot
/dev/zero
/dev/null

[root at localhost ~]# ls -Z /dev/mapper/control 
crw-rw----. root root system_u:object_r:lvm_control_t:s0 /dev/mapper/control

And related with that (since looks there might be properly labeled devices
out of *_device_t target) wondering why not to check for 'unlabeled_t' directly?

E.g. perform something like:?

  find /dev -context *\:unlabeled_t\:* \( -type c -o -type b \)

Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team

[*] Maybe above command quote has been provided just as an example that it should be
    replaced with 'find ...' command instead of 'ls -Z | grep' commands couple,
    but there's pull request quoting it directly:
      https://github.com/OpenSCAP/scap-security-guide/pull/324/files

> 
> I think the guide should get a thorough review.
> 
>  
> > > This really needs to be addressed before anyone else uses SSG as the
> > > basis
> > > of their own recommendations. Again, forensic checking is useful and I
> > > would say content should be specifically designed with that in mind. But
> > > it is not what should be in a baseline.
> > 
> > That's a bit strong of language. SSG represents a catalog of controls,
> > from which agencies make selections for formal baselines that we turn
> > into profiles. Often (e.g. with the STIG) the agency wishes to include
> > capabilities for static/persistent configuration (e.g. sysctl.conf)
> > *and* ephemeral system state (sysctl -a).
> 
> In retrospect, I agree. I am concerned that people not with a strong Linux
> background don't grok the difference or perhaps learn the wrong thing.
> 
> -Steve
> --
> 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