plus3it / ash-linux-formula Goto Github PK

Need to determine method for locating improperly configured NFS mounts

Need to come up with a way to determine if reliance on outside component can be satisfied or at least determined

Verify client-signing in autofs-style CIFS mounts. Not directly-specified in STIG. No relevant functions in current Saltstack module-list - probably requires fully custom code/helper-scripts to effect [do in second or third iteration of packaging SLSes]

Need to sort out a (preferably efficient) method for managing a dynamic list of log files

Handler currently forces "max_log_file" value to STIG-recommended ("6"). Handler should:

• Detect if absent. If so, determine appropriate value based on space available in /var/log/audit and set (use "6" if /var/log/audit is small). May not be doable as STIGs don't recommend a formula for determination.
• Detect if value is set. If so, only override if existing setting is less than STIG-recommended value

Need to determine method for locating improperly configured NFS mounts

Need to find a (reliable) way to dynamically determine appropriate max disk space for audit logs

Need to find a way to strip world-write permissions from dynamic file list

Need to find a (preferably efficient) way to handle the relative permissions-stripping for a non-fixed, recursive file-list

Config max audit space warning (suggest: borrow from pam_cracklib technique)

Using the following code-segment to determine whether to update /etc/fstab (and to apply update if condition returns true):

`
# Update fstab (if necessary)
{% if salt'file.search' %}
notify_V38652-{{ mountPoint }}-remount:
cmd.run:

• name: 'printf "\t* Updating /etc/fstab as necessary\n"'

fstab_V38652-{{ mountPoint }}:
module.run:

• name: 'mount.set_fstab'
• m_name: '{{ mountPoint }}'
• device: '{{ remountDev }}'
• fstype: '{{ fsType }}'
• opts: '{{ optString }}'
  {% endif %}
  `

However, {% if %} statement fails to properly evaluate to "True"

Handler assumes that pam_cracklib is in place. While generally valid on EL6, not 100% safe assumption as starting-point: need to add logic for adding cracklib and associated token-setting.

Current handler for V-38652 only works when the NFS mount point doesn't have another filesystem mounted over or into it (i.e., /mount/ will work only if there is no /mount//)

Need to add fstab functionality ...possibly via iterative-matching of mount.fstab function [needed in initial roll]

Need to add mtab functionality ...most likely via iterative-matching of mount.mounted function [needed in initial roll]

Need to come up with a (preferably efficient) way to handle the permissions-subtraction requirements of this STIG V-ID

Seems similar to #47

      ID: file_V38583-hardlink
Function: module.run
    Name: file.link
  Result: False
 Comment: Module function file.link threw an exception. Exception: Could not create '/boot/grub.conf'
 Started: 22:00:46.043873
Duration: 0.881 ms
 Changes:   

While not expressly required by the STIGs, should probably iterate all the IPs/interfaces and ensure they have boot-time configuration files.

Use 'service.enable' instead of 'service.running' and use 'module.run' to 'watch' the pkg and execute 'service.start'.

Actual AIDE configuration likely out of scope. Set as advisory-only handler for initial rollout; explore config basics for subsequent updates

Description:
Due to run-time processing-precedence of Jinja-based code, the /etc/pam.d/system-auth-ac file can end up with redundant edits applied. If the named-handlers are all run as part of higher-level include - such as:

include:
- STIGbyID.cat2.V38501
- STIGbyID.cat2.V38573
- STIGbyID.cat2.V38592

Symptoms:
The edits contained within will be multiply-applied, creating a faillock-config that looks like:

# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        required      pam_faillock.so preauth silent audit deny=3 unlock_time=900
auth        required      pam_faillock.so preauth silent audit deny=3 unlock_time=900
auth        required      pam_faillock.so preauth silent audit deny=3 unlock_time=900
auth        sufficient    pam_unix.so try_first_pass
auth        [default=die] pam_faillock.so authfail deny=3 unlock_time=900 fail_interval=900
auth        required      pam_faillock.so authsucc deny=3 unlock_time=900 fail_interval=900
auth        [default=die] pam_faillock.so authfail deny=3 unlock_time=900 fail_interval=900
auth        required      pam_faillock.so authsucc deny=3 unlock_time=900 fail_interval=900
auth        [default=die] pam_faillock.so authfail deny=3 unlock_time=900 fail_interval=900
auth        required      pam_faillock.so authsucc deny=3 unlock_time=900 fail_interval=900

The desired end-state should be:

# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        required      pam_faillock.so preauth silent audit deny=3 unlock_time=900
auth        sufficient    pam_unix.so try_first_pass
auth        [default=die] pam_faillock.so authfail deny=3 unlock_time=900 fail_interval=900
auth        required      pam_faillock.so authsucc deny=3 unlock_time=900 fail_interval=900

Work-Around
Iterative, individual invocation of handlers will avoid the redundant edits.

Script currently works fine when a logging-target's definition starts with a unique facility name (e.g., "kern"). However, if the first-defined facility-name isn't unique (specifically encountered error with "*" facility), handler will only set ownership on the last-defined logging-target that matches the facility.

Note: Handling of "*" facility is currently disabled. When the above-noted issue is fixed, add

'*',

To the facilityList list-variable.

The /etc/profile shipped in the setup RPM has a starting umask definition-block that looks like:

if [ $UID -gt 199 ] && [ "`id -gn`" = "`id -un`" ]; then
    umask 002
else
    umask 022
fi

This handler doesn't deal with this structure very well. Currently, falls back and clobbers the above - replacing with "077". Might be better to either have the handler nuke this entire block or append a umask 077 to the file (not tidy but should override all prior umask defines).

Need to apply method for configuring pam_faillock similar to those used for pam_cracklib

Need to sort out a (preferably efficient) method for managing a dynamic list of log files

Need to find a (preferably efficient) method for scanning for, reporting on and nuking .netrc files anywhere on the system

STIG-ID V-38702 only specifically examines and specifies fixes for vsftpd; however, other ftpds are available in the standard Enterprise Linux repos. Probably want to extend where other ftpds are available and support equivalents to the STIG-mandated logging settings.

Handler assumes that pam_cracklib is in place. While generally valid on EL6, not 100% safe assumption as starting-point: need to add logic for adding cracklib and associated token-setting.

Need to figure out a way to do permissions checking/setting on a dynamic file list extracted from syslog service's configuration file(s)

Having trouble following the logic in the sls, need to study it more.

          ID: file_V38581-hardlink
    Function: module.run
        Name: file.link
      Result: False
     Comment: Module function file.link threw an exception. Exception: Could not create '/boot/grub.conf'
     Started: 22:00:46.027891
    Duration: 0.881 ms
     Changes:   

STIG specifies a fix for an indeterminate list. The following only addresses the Linux default scratch directories /tmp and /var/tmp. Prior STIGS require looking for other objects with overly-generous permissions and resetting them. Will explore appropriate resetting permissions against an indeterminite directory-list in future iterations of this SLS.

Current rpm update method individually updates all packages listed as requiring an update via:

{% set updatePairs = salt'pkg.list_upgrades' %}

{% for pkgName in updatePairs %}
remediate_V38481-{{ pkgName }}:
pkg:

• name: {{ pkgName }}
• latest
  {% endfor %}

If system is kept well-patched, the number of updates is low, handler functions as expected. However, in a large update delta (e.g., as happens at a new ELx point-release) the number of items seems to exceed Salt's capacity causing the Salt-run to crash.

This is why we verify out file counts against our STIG counts...

Currently sourcing a shell script (STIGbyID/cat2/files/V38465-helper.sh) to do the heavy-lifting. More style-conformant to recode as a python module.

Due to issues in mount.mounted/mount.set_fstab (detailed in mainline salt Issue ID #17198) this handler will butcher the /etc/fstab file if there is more than one file of type 'tmpfs'.

Test systems are currently using tmpfs for both /tmp and /dev/shm: latter is required; former is best-practices for EL6 and higher.

Upstream fix to the Salt modules for mount.mounted/mount.set_fstab should fix this issue. Closure should only require verification. Per comment on original Salt Issue ID this will be in the 2015 code-trees but won't be back-ported into the 2014.7.x code-trees

Script currently works fine when a logging-target's definition starts with a unique first-facility name (e.g., "kern"). However, if the first-defined facility-name isn't unique (specifically encountered error with "*" facility), handler will only set ownership on the last-defined logging-target that matches the facility.

Note: Handling of "*" facility is currently disabled. When the above-noted issue is fixed, add

'*',

To the facilityList list-variable.

Need to apply method for configuring pam_faillock similar to those used for pam_cracklib

Handler assumes that pam_cracklib is in place. While generally valid on EL6, not 100% safe assumption as starting-point: need to add logic for adding cracklib and associated token-setting.

Can't disable DHCP in AWS. Need to either set this as an advisory-only handler or put logic in to determine whether it's safe to summarily disable DHCP (probably phase 1 for advisory-only; phase 2+ for conditional)

Currently sourcing a shell script (STIGbyID/cat2/files/V38469-helper.sh) to do the heavy-lifting. More style-conformant to recode as a python module.

This is why we verify out file counts against our STIG counts...

Tried setting a flag in the for-loop and checking for its presence in a state-ending if, but logic wasn't working (would display the "all good" protected output regardless of defined-state).

Need to find a way to run the "all good" test just once.

Finish up support for additional FTP daemons

Handler assumes that pam_cracklib is in place. While generally valid on EL6, not 100% safe assumption as starting-point: need to add logic for adding cracklib and associated token-setting.

Placed logic inside SLS file to check for existence of system-auth-ac file:

{% if not salt['file.file_exists'](checkFile) %}
cmd_V38497-linkSysauth:
  cmd.run:
  - name: '/usr/sbin/authconfig --update'
{% endif %}

If interpreted in order listed in SLS file, all is good. However, salt-call seems like it's doing out-of-order execution, rendering the above essentially useless. Need to force Salt to do the Right Thing.

Handler assumes that pam_cracklib is in place. While generally valid on EL6, not 100% safe assumption as starting-point: need to add logic for adding cracklib and associated token-setting.

Script currently works fine when a logging-target's definition starts with a unique facility name (e.g., "kern"). However, if the first-defined facility-name isn't unique (specifically encountered error with "*" facility), handler will only set ownership on the last-defined logging-target that matches the facility.

Note: Handling of "*" facility is currently disabled. When the above-noted issue is fixed, add

'*',

To the facilityList list-variable.

Handler assumes that pam_cracklib is in place. While generally valid on EL6, not 100% safe assumption as starting-point: need to add logic for adding cracklib and associated token-setting.

Handler for STIG-ID V-38655 only notifies about some cases - doesn't actually address anything. Will require a major rewrite to perform remidiative actions.

Due to issues in mount.mounted/mount.set_fstab (detailed in mainline salt Issue ID #17198) this handler will butcher the /etc/fstab file if there is more than one file of type 'tmpfs'.

Test systems are currently using tmpfs for both /tmp and /dev/shm: latter is required; former is best-practices for EL6 and higher.

Upstream fix to the Salt modules for mount.mounted/mount.set_fstab should fix this issue. Closure should only require verification. Per comment on original Salt Issue ID this will be in the 2015 code-trees but won't be back-ported into the 2014.7.x code-trees

This is why we verify out file counts against our STIG counts...