SSG 0.1-14-14 - no_uidzero_except_root
by ssg fthfth
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'
10 years, 2 months
SSG 0.1-14-14 - no_netrc_files
by ssg fthfth
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.
10 years, 2 months
SSG 0.1-14-14 - world_writable_files_system_ownership
by ssg fthfth
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.
10 years, 2 months
SSG 0.1-14-14 - world_writeable_files
by ssg fthfth
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'
10 years, 2 months
SSG 0.1-14-14 - sticky_world_writable_dirs
by ssg fthfth
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
10 years, 2 months
System UIDs/GIDs in RHEL7 (UNCLASSIFIED)
by Shaw, Ray V CTR USARMY RDECOM ARL (US)
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
10 years, 2 months