jburns12 / inspec_profiles Goto Github PK

This control needs to be implemented. It will likely require the be_in matcher an a .yml file that lists services, etc/ allowed by the firewall.

Need to implement this control.

This control must be implemented to verify the mounting options for for removable media. Must develop a good way to determine if a file system is considered removable media in order to finish this control.

This control needs to be implemented to check against a list of authorized system accounts, apps, and user accounts. It will likely need to utilize the be_in matcher and compare against a .yml file.

see: https://www.centos.org/docs/rhel-rg-en-3/s1-tcpwrappers-access.html

Sections : 16.2.x

This control needs to be implemented such that executable search path statements may not include directories outside of their home directory. This may require some amount of parsing of a grep command.

An aide.conf resource will assist in the development of the following controls:
V-72063.rb
V-72069.rb
V-72071.rb
V-72073.rb

Currently it is difficult to parse the aide.conf file to develop the above controls. This resource will "aid" in streamlining the creation of these controls.

These controls need to be implemented once the aide resource is developed.

This control needs to be implemented.

Need to figure out why the execution of tests on the hardened RHEL7 machine is slow.

Command to pipe runtimes to jq:
inspec exec $CONTROLS/. -i $SSH_KEY -t ssh://[email protected]:2222 --sudo --sudo-options='-u postgres' --format=json-min | jq .

This control needs to be implemented to check package versions against a list of available package security updates from Red Hat at https://rhn.redhat.com/errata.

Need to finish implementing this control.

I was wondering, once we process all the lines and or rules we would have a data structure like:

rules => { [rule => settings], ... } 
or
rules => { {rule => settings }, ... }

Is the more natural check:

  describe aide_conf.rules do
    its('something') { should contain 'sha512' }
  end

Other thoughts, and I am just shooting off the hip here:

describe aide_conf.macro('ALL') do
    it { should include 'sha512' }
  end

describe aide_conf.macros do
    it { should include 'sha512' }
  end

describe aide_conf.groups do
    it { should include 'NORMAL' }
    it { should include 'DIR' }
    it { should include 'LSPP' }
  end

describe aide_conf.group('NORMAL') do
    its('something') { should match [R,rmd160,sha256]  }
  end

NORMAL = R+rmd160+sha256

# For directories, don't bother doing hashes
DIR = p+i+n+u+g+acl+selinux+xattrs

# Access control only
PERMS = p+i+u+g+acl+selinux

# Logfile are special, in that they often change
LOG = >

# Just do md5 and sha256 hashes
LSPP = R+sha256```

Also, is it natural to assume we should have something like: `macro_lines' and `selection_lines` and `groups` ? 

I would also guess having the ability to return an array or hash of the parts or elements of a MACRO would be useful:

i.e. NORMAL => [R+rmd160+sha256] or NORMAL=>[R,rmd160,sha256]

Also, I may want to say:

All selection_lines that have a macro or that are part of a group. etc. For example, can I get this list of directories as part of the group/macro 'NORMAL'? Don't know if that makes sense but just some thoughts.

/boot   NORMAL
/bin    NORMAL
/sbin   NORMAL
/lib    NORMAL
/lib64  NORMAL
/opt    NORMAL
/usr    NORMAL
/root   NORMAL
# These are too volatile
!/usr/src
!/usr/tmp

# Check only permissions, inode, user and group for /etc, but
# cover some important files closely.
/etc    PERMS
!/etc/mtab
# Ignore backup files
!/etc/.*~
/etc/exports  NORMAL
/etc/fstab    NORMAL
/etc/passwd   NORMAL
/etc/group    NORMAL
/etc/gshadow  NORMAL
/etc/shadow   NORMAL
/etc/security/opasswd   NORMAL

/etc/hosts.allow   NORMAL
/etc/hosts.deny    NORMAL

/etc/sudoers NORMAL
/etc/skel NORMAL

/etc/logrotate.d NORMAL

/etc/resolv.conf DATAONLY

/etc/nscd.conf NORMAL
/etc/securetty NORMAL

This control needs to be implemented to check against a list of authorized users. It will likely need to utilize the be_in matcher and compare against a .yml file.

This resource needs to be updated to match on specific flags per audit line.

The control needs to be implemented.

gnome has done a lot of changing to how they do things. One thing that was suggested is that for most of the GUI parts we try to use the gnome tools to both evaluate and discover where things are configured as it is very easy to do it many many ways and still have things setup correctly.

https://developer.gnome.org/GSettings/

You can display extra text on the login screen, such as who to contact for support, by setting the org.gnome.login-screen.banner-message-enable and org.gnome.login-screen.banner-message-text GSettings keys.

It looks like a lot of these settings are just xml files so - ug - the right way may be to parse the xml. Not sure. But the gsettings command may be the right way to 'interface' with it.

Also ensure that the ubuntu part of this is covered as well or at least on its way..