scap-security-guide February 2014

scap-security-guide@lists.fedorahosted.org

32 participants
66 discussions

SSG 0.1-14-14 - no_uidzero_except_root
by ssg fthfth 14 Feb '14

14 Feb '14

For Verify Only Root Has UID 0 - (CCE-26971-2), with either the stig-rhel6-server or the usgcb-rhel6-server profiles selected from the SCAP stream, when run with SCC 3.1.1.1, may produce a false-negative when running SCC 3.1.1.1 on a RHEL6V1R2 non-complaint machine. $ /usr/bin/id -u root && /usr/bin/id -u root2 0 0 $/usr/bin/awk -F: '($3 == "0") {print}' /etc/passwd root:...:0:0:root:/root:/bin/bash root2:...:0:0::/home/root2:/bin/bash The regex matches root vice uid 0:^[^r][^o][^o][^t].*:0 See the following report output: Verify Only Root Has UID 0 ID: no_uidzero_except_root Result: Pass Identities: CCE-26971-2 Description: If any account other than root has a UID of 0, this misconfiguration should be investigated and the accounts other than root should be removed or have their UID changed. Fix Text: Severity: medium Weight: Reference: AC-6 IA-2(1) 366 Definitions: ID: oval:ssg:def:273 Result: true Title: UID 0 Belongs Only To Root Description: Only the root account should be assigned a user id of 0. Class: compliance Tests: true (All item-state comparisons must be true.) true (tests for reg exp ^[^r][^o][^o][^t].*:0 in /etc/passwd file) Tests: Test ID: oval:ssg:tst:274 Result: true Title: tests for reg exp ^[^r][^o][^o][^t].*:0 in /etc/passwd file Check Existence: No collected items may exist. Check: Result is based on check existence only. State Operator: All item-state comparisons must be true. Object ID: oval:ssg:obj:1384 Object Requirements: path must be equal to '/etc' filename must be equal to 'passwd' pattern must match the pattern '^(?!root:)[^:]*:[^:]:0' instance must be equal to '1'

1 0

SSG 0.1-14-14 - no_netrc_files
by ssg fthfth 14 Feb '14

14 Feb '14

For Verify No netrc Files Exist - (CCE-27225-2), with the usgcb-rhel6-server profile selected from the SCAP stream, when run with SCC 3.1.1.1, may produce a false-negative when running SCC 3.1.1.1 on a RHEL6V1R2 non-complaint machine. $ /usr/bin/sudo /bin/find / -xdev -name .netrc /root/.netrc See the following report output: Verify No netrc Files Exist ID: no_netrc_files Result: Pass Identities: CCE-27225-2 Description: The .netrc files contain login information used to auto-login into FTP servers and reside in the user's home directory. These files may contain unencrypted passwords to remote FTP servers making them susceptible to access by unauthorized users and should not be used. Any .netrc files should be removed. Fix Text: Severity: medium Weight: Reference: IA-5(h) 196 Definitions: ID: oval:ssg:def:1142 Result: true Title: Verify No netrc Files Exist Description: The .netrc files contain login information used to auto-login into FTP servers and reside in the user's home directory. Any .netrc files should be removed. Class: compliance Tests: true (All item-state comparisons must be true.) true (look for .netrc in /home) (negated) Tests: Test ID: oval:ssg:tst:1143 Result: false Title: look for .netrc in /home Check Existence: One or more collected items must exist. Check: Result is based on check existence only. State Operator: All item-state comparisons must be true. Object ID: oval:ssg:obj:2117 Object Requirements: behavior requirements: recurse_direction = down max_depth = 1 recurse = directories path must be equal to '/home' filename must match the pattern '^\.netrc$' Additional Information: Collected items did not meet the check existence requirement.

1 0

SSG 0.1-14-14 - world_writable_files_system_ownership
by ssg fthfth 14 Feb '14

14 Feb '14

For Ensure All World-Writable Directories Are Owned by a System Account - (CCE-26642-9), with either the stig-rhel6-server or the usgcb-rhel6-server profiles selected from the SCAP stream, when run with SCC 3.1.1.1, may produce a false-negative when running SCC 3.1.1.1 on a RHEL6V1R2 non-complaint machine. The non-complaint system contains world-writable directories not owned by a system account: /bin/ls -dn /root/ drwxrwxrwx. 28 500 500 4096 Feb 7 09:46 /root/ /bin/ls -dl /root/ && /bin/grep ^user: /etc/group /etc/passwd drwxrwxrwx. 28 user user 4096 Jan 8 13:07 /root/ /etc/group:user:x:500: /etc/passwd:user::500:500:user:/home/user:/bin/bash See the following report output: Ensure All World-Writable Directories Are Owned by a System Account ID: world_writable_files_system_ownership Result: Pass Identities: CCE-26642-9 Description: All directories in local partitions which are world-writable should be owned by root or another system account. If any world-writable directories are not owned by a system account, this should be investigated. Following this, the files should be deleted or assigned to an appropriate group. Fix Text: Severity: low Weight: Reference: AC-6 Definitions: ID: oval:ssg:def:521 Result: true Title: Find world writable directories not owned by a system account Description: All world writable directories should be owned by a system user. Class: compliance Tests: true (All item-state comparisons must be true.) (negated) false (check for local directories that are world writable and have uid greater than or equal to 500) Tests: Test ID: oval:ssg:tst:522 Result: false Title: check for local directories that are world writable and have uid greater than or equal to 500 Check Existence: One or more collected items must exist. Check: All collected items must match the given state(s). State Operator: All item-state comparisons must be true. Object ID: oval:ssg:obj:1587 Object Requirements: behavior requirements: recurse_direction = down recurse = directories recurse_file_system = local path must be equal to '/' filter must be equal to 'oval:ssg:ste:1588' State ID: oval:ssg:ste:1588 State Requirements: user_id must be greater than or equal to '500' owrite must be equal to 'true' Additional Information: Collected items did not meet the check existence requirement.

1 0

SSG 0.1-14-14 - world_writeable_files
by ssg fthfth 14 Feb '14

14 Feb '14

For Ensure No World-Writable Files Exist - (CCE-26910-0), with either the stig-rhel6-server or the usgcb-rhel6-server profiles selected from the SCAP stream, when run with SCC 3.1.1.1, may produce a false-negative when running SCC 3.1.1.1 on a RHEL6V1R2 non-complaint machine. The non-complaint system contains world-writable files: $ /usr/bin/sudo /usr/bin/stat -c '%a' /etc/audit/audit.rules 777 See the following report output: Ensure No World-Writable Files Exist ID: world_writeable_files Result: Pass Identities: CCE-26910-0 Description: It is generally a good idea to remove global (other) write access to a file when it is discovered. However, check with documentation for specific applications before making changes. Also, monitor for recurring world-writable files, as these may be symptoms of a misconfigured application or user account. Fix Text: Severity: medium Weight: Reference: AC-6 Definitions: ID: oval:ssg:def:446 Result: true Title: Find Unauthorized World-Writable Files Description: The world-write permission should be disabled for all files. Class: compliance Tests: true (All item-state comparisons must be true.) true (world writable files) Tests: Test ID: oval:ssg:tst:447 Result: true Title: world writable files Check Existence: No collected items may exist. Check: Result is based on check existence only. State Operator: All item-state comparisons must be true. Object ID: oval:ssg:obj:1524 Object Requirements: behavior requirements: recurse_direction = down recurse = directories recurse_file_system = local path must be equal to '/' filename must match the pattern '^.*$' filter must be equal to 'oval:ssg:ste:2230'

1 0

SSG 0.1-14-14 - sticky_world_writable_dirs
by ssg fthfth 14 Feb '14

14 Feb '14

For Verify that All World-Writable Directories Have Sticky Bits Set - (CCE-26840-9), with either the stig-rhel6-server or the usgcb-rhel6-server profiles selected from the SCAP stream, when run with SCC 3.1.1.1, may produce a false-negative when running SCC 3.1.1.1 on a RHEL6V1R2 non-complaint machine. ls -ldh /root/ /root/.ssh/ drwxrwxrwx. 28 user user 4.0K Feb 7 09:46 /root/ drwxrwxrwt. 2 nobody wheel 4.0K Jul 24 2013 /root/.ssh See the following report output: Verify that All World-Writable Directories Have Sticky Bits Set ID: sticky_world_writable_dirs Result: Pass Identities: CCE-26840-9 Description: When the so-called 'sticky bit' is set on a directory, only the owner of a given file may remove that file from the directory. Without the sticky bit, any user with write access to a directory may remove any file in the directory. Setting the sticky bit prevents users from removing each other's files. In cases where there is no reason for a directory to be world-writable, a better solution is to remove that permission rather than to set the sticky bit. However, if a directory is used by a particular application, consult that application's documentation instead of blindly changing modes. To set the sticky bit on a world-writable directory DIR, run the following command: # chmod +t DIR Fix Text: Severity: low Weight: Reference: AC-6 Definitions: ID: oval:ssg:def:169 Result: true Title: Verify that All World-Writable Directories Have Sticky Bits Set Description: The sticky bit should be set for all world-writable directories. Class: compliance Tests: true (All item-state comparisons must be true.) true (all local world-writable directories have sticky bit set) (negated) Tests: Test ID: oval:ssg:tst:170 Result: false Title: all local world-writable directories have sticky bit set Check Existence: All N15

1 0

System UIDs/GIDs in RHEL7 (UNCLASSIFIED)
by Shaw, Ray V CTR USARMY RDECOM ARL (US) 10 Feb '14

10 Feb '14

Classification: UNCLASSIFIED Caveats: NONE https://lists.fedoraproject.org/pipermail/devel/2011-May/151663.html Will UID_MIN and GID_MIN default to 1000 in RHEL7 as well? I have not had (and do not have, sadly) time to check out the RHEL7 beta, but a quick search of several of the documentation pages didn't mention this. I would imagine so, given things like: https://bugzilla.redhat.com/show_bug.cgi?id=907312 If so, should we expect the STIG for RHEL7 to reflect this, counting everything 1000 and below as a "system" account/group for relevant rules? Just trying to get a head start on potentially necessary UID/GID changes. Thanks, -- Ray Shaw (Contractor, STG) Army Research Laboratory CIO, Unix Support Classification: UNCLASSIFIED Caveats: NONE

5 6

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

scap-security-guide February 2014