Re: [Open-scap] RHEL 7 GRUB2 boot password
"superusers should be root, admin or administrator" Are you sure it shouldn't be "superusers should NOT be root, admin or administrator" ? I changed mine from "root" to "grub.root", made sure the full hash was in /etc/grub.d/01_users, re-ran grub2-mkconfig and then the oscap scan passed. I can say for certain that the superuser should not be "root" What else shouldn't it be ? Dan White | d_e_wh...@icloud.com “Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.” (Bill Waterson: Calvin & Hobbes) On Jan 23, 2018, at 10:10 AM, Watson Yuuma Sato wrote: On 23/01/18 13:29, Dan White wrote: Scanning some RHEL 7 VM's with the latest/greatest, I am getting a finding against the Boot Loader Password. I set it according to this RHEL 7 System Administrator's Guide page and this Red Hat Solutions page, but the test fails. Details from the report: - Rule ID: xccdf_org.ssgproject.content_rule_bootloader_password This rule specifically checks if '/etc/grub2/grub.cfg' has superusers and password_pbkdf2 configured. superusers should be root, admin or aministrator, and password key derivation function used should be 'grub.pbkdf2.sha512'. Make sure you have these configured, I couldn't find details about superuser and derivation function in pointed guides. Result: fail Time: 2018-01-22T14:52:15 Severity: high Identifiers and References: Identifiers: CCE-27309-4 References: IA-2(1), IA-5(e), AC-3, 213, SRG-OS-80-GPOS-00048, RHEL-07-010480, 1.5.3, 3.4.5 Description : The grub2 boot loader should have a superuser account and password protection enabled to protect boot-time settings. To do so, select a superuser account and password and add them into the /etc/grub.d/01_users configuration file. Since plaintext passwords are a security risk, generate a hash for the pasword by running the following command: $ grub2-mkpasswd-pbkdf2 When prompted, enter the password that was selected and insert the returned password hash into the /etc/grub.d/01_users configuration file immediately after the superuser account. (Use the output from grub2-mkpasswd-pbkdf2 as the value of password-hash): password_pbkdf2 superusers-account password-hash NOTE: It is recommended not to use common administrator account names like root, admin, or administrator for the grub2 superuser account. To meet FISMA Moderate, the bootloader superuser account and password MUST differ from the root account and password. Once the superuser account and password have been added, update the grub.cfg file by running: grub2-mkconfig -o /boot/grub2/grub.cfg NOTE: Do NOT manually add the superuser account and password to the grub.cfg file as the grub2-mkconfig command overwrites this file. Rationale Password protection on the boot loader configuration ensures users with physical access cannot trivially alter important bootloader settings. These include which kernel to use, and whether to enter single-user mode. For more information on how to configure the grub2 superuser account and password, please refer to https://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/sec-GRUB_2_Password_Protection.html - The link from the.Rationale returns a "404", and there is no mention in the current RHEL 7 System Administrator's Guide about tinkering with the /etc/grub.d/01_users configuration file other than to say it was necessary in versions prior to RHEL 7.2 Does the check need to be updated or do I need to do something other than stated in the Red Hat Documentation ? And y'all have a typo :) that I highlighted in red on the third line of the description. Dan White | d_e_wh...@icloud.com “Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.” (Bill Waterson: Calvin & Hobbes) ___ Open-scap-list mailing list Open-scap-list@redhat.com https://www.redhat.com/mailman/listinfo/open-scap-list -- Watson Sato Security Technologies | Red Hat, Inc___ Open-scap-list mailing list Open-scap-list@redhat.com https://www.redhat.com/mailman/listinfo/open-scap-list
Re: [Open-scap] Open SCAP on Ubuntu
Hi, Unfortunately, scap-workbench was introduced in Ubuntu 17.04, so it is not available in 16.04. In ubuntu 16.04 you can use still command-line tool oscap, which is found in package libopenscap8. But there is old OpenSCAP 1.2.8. I don't expect Ubuntu people will update packages in LTS release. Jan Černý Security Technologies | Red Hat, Inc. - Original Message - > From: "Geoffry Roberts" > To: Open-scap-list@redhat.com > Sent: Wednesday, January 24, 2018 4:04:34 PM > Subject: [Open-scap] Open SCAP on Ubuntu > > All, > > Can anyone give me the status of OpenSCAP on Ubuntu? Is it healthy? > > > > I am using Ubuntu because I can't get Fedora 27 Workstation to install on my > vbox, an issue I'll be posting to the Fedora forum. > I am just getting started with OpenSCAP. According to the users manual I > should be able to install on Ubuntu 16.04 thus: > > > # apt-get install scap-workbench > > But I am getting no package found. > > Thanks > > ___ > Open-scap-list mailing list > Open-scap-list@redhat.com > https://www.redhat.com/mailman/listinfo/open-scap-list ___ Open-scap-list mailing list Open-scap-list@redhat.com https://www.redhat.com/mailman/listinfo/open-scap-list
Re: [Open-scap] Open SCAP on Ubuntu
On 01/24/2018 03:04 PM, Geoffry Roberts wrote: All, Can anyone give me the status of OpenSCAP on Ubuntu? Is it healthy? I am using Ubuntu because I can't get Fedora 27 Workstation to install on my vbox, an issue I'll be posting to the Fedora forum. I am just getting started with OpenSCAP. According to the users manual I should be able to install on Ubuntu 16.04 thus: # apt-get install scap-workbench On Ubuntu 16.04 the scap-workbench package is not present (in the default repositories). On Ubuntu 17.10, it is present and is version 1.1.5-1. It has libopenscap8 as a dependency. Regards, Gary ___ Open-scap-list mailing list Open-scap-list@redhat.com https://www.redhat.com/mailman/listinfo/open-scap-list
[Open-scap] Open SCAP on Ubuntu
All, Can anyone give me the status of OpenSCAP on Ubuntu? Is it healthy? I am using Ubuntu because I can't get Fedora 27 Workstation to install on my vbox, an issue I'll be posting to the Fedora forum. I am just getting started with OpenSCAP. According to the users manual I should be able to install on Ubuntu 16.04 thus: # apt-get install scap-workbench But I am getting no package found. Thanks ___ Open-scap-list mailing list Open-scap-list@redhat.com https://www.redhat.com/mailman/listinfo/open-scap-list
Re: [Open-scap] RHEL 7 GRUB2 boot password
Escalating it !
https://access.redhat.com/support/cases/#/case/02019325
Dan White | d_e_wh...@icloud.com
“Sometimes I think the surest sign that intelligent life exists elsewhere in the
universe is that none of it has tried to contact us.” (Bill Waterson: Calvin &
Hobbes)
On Jan 23, 2018, at 02:56 PM, Dan White wrote:
Something is very wrong here
[root@jump-linux7 ~]# cat /etc/grub.d/01_users # ORIGINAL
#!/bin/sh -e
cat << EOF
if [ -f \${prefix}/user.cfg ]; then
source \${prefix}/user.cfg
if [ -n "\${GRUB2_PASSWORD}" ]; then
set superusers="root"
export superusers
password_pbkdf2 root \${GRUB2_PASSWORD}
fi
fi
EOF
Then I have the output of "grub2-setpassword" :
[root@jump-linux7 ~]# cat /boot/grub2/user.cfg
GRUB2_PASSWORD=grub.pbkdf2.sha512.1.yadda-yadda-yadda
So, I copy the hash into /etc/grub.d/01_users :
[root@jump-linux7 ~]# cat /etc/grub.d/01_users
#!/bin/sh -e
cat << EOF
if [ -f \${prefix}/user.cfg ]; then
source \${prefix}/user.cfg
if [ -n "\${GRUB2_PASSWORD}" ]; then
set superusers="root"
export superusers
password_pbkdf2 root grub.pbkdf2.sha512.1.yadda-yadda-yadda
fi
fi
EOF
And then run
grub2-mkconfig -o /boot/grub2/grub.cfg
Checking "/boot/grub2/grub.cfg", I find
[root@jump-linux7 ~]# less /boot/grub2/grub.cfg
...
### BEGIN /etc/grub.d/00_tuned ###
set tuned_params=""
set tuned_initrd=""
### END /etc/grub.d/00_tuned ###
### BEGIN /etc/grub.d/01_users ###
if [ -f ${prefix}/user.cfg ]; then
source ${prefix}/user.cfg
if [ -n "${GRUB2_PASSWORD}" ]; then
set superusers="root"
export superusers
password_pbkdf2 root grub.pbkdf2.sha512.1.yadda-yadda-yadda
fi
fi
### END /etc/grub.d/01_users ###
...
But :
Rule ID: xccdf_org.ssgproject.content_rule_bootloader_password
Result: fail
Identifiers: CCE-27309-4
What the heck ?!
Dan White | d_e_wh...@icloud.com
“Sometimes I think the surest sign that intelligent life exists elsewhere in the
universe is that none of it has tried to contact us.” (Bill Waterson: Calvin &
Hobbes)
On Jan 23, 2018, at 02:27 PM, Dan White wrote:
Running "grub2-mkconfig -o /boot/grub2/grub.cfg" without making any other
changes made no difference
Guess I need to tinker with the /etc/grub.d/01_users configuration file.
Dan White | d_e_wh...@icloud.com
“Sometimes I think the surest sign that intelligent life exists elsewhere in the
universe is that none of it has tried to contact us.” (Bill Waterson: Calvin &
Hobbes)
On Jan 23, 2018, at 11:16 AM, Dan White wrote:
That helps me trouble shoot.
Thanks.
I will keep y’all informed.
I think I will open a support ticket with Red Hat to attack this from the
opposite direction.
"Sometimes I think the surest sign that intelligent life exists elsewhere in the
universe is that none of it has tried to contact us."
Bill Waterson (Calvin & Hobbes)
On Jan 23, 2018, at 10:10 AM, Watson Yuuma Sato wrote:
On 23/01/18 13:29, Dan White wrote:
Scanning some RHEL 7 VM's with the latest/greatest, I am getting a finding
against the Boot Loader Password.
I set it according to this RHEL 7 System Administrator's Guide page and this
Red Hat Solutions page, but the test fails.
Details from the report:
-
Rule ID: xccdf_org.ssgproject.content_rule_bootloader_password
This rule specifically checks if '/etc/grub2/grub.cfg' has superusers and
password_pbkdf2 configured.
superusers should be root, admin or aministrator, and password key derivation
function used should be 'grub.pbkdf2.sha512'.
Make sure you have these configured, I couldn't find details about superuser
and derivation function in pointed guides.
Result: fail
Time: 2018-01-22T14:52:15
Severity: high
Identifiers and References:
Identifiers: CCE-27309-4
References: IA-2(1), IA-5(e), AC-3, 213, SRG-OS-80-GPOS-00048,
RHEL-07-010480, 1.5.3, 3.4.5
Description :
The grub2 boot loader should have a superuser account and password protection
enabled to protect boot-time settings.
To do so, select a superuser account and password and add them into the
/etc/grub.d/01_users configuration file.
Since plaintext passwords are a security risk, generate a hash for the pasword
by running the following command:
$ grub2-mkpasswd-pbkdf2
When prompted, enter the password that was selected and insert the returned
password hash into the /etc/grub.d/01_users configuration file immediately
after the superuser account. (Use the output from grub2-mkpasswd-pbkdf2 as the
value of password-hash):
password_pbkdf2 superusers-account password-hash
NOTE: It is recommended not to use common administrator account names like
root, admin, or administrator for the grub2 superuser account.
To meet FISMA Moderat
Re: [Open-scap] RHEL 6 - rsyslog vs rsyslog7
In RHEL 6, yes In RHEL 7, they are already on rsyslog 8 Can the check look for either ? Dan White | d_e_wh...@icloud.com “Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.” (Bill Waterson: Calvin & Hobbes) On Jan 24, 2018, at 06:13 AM, Watson Yuuma Sato wrote: On 23/01/18 13:42, Dan White wrote: Another head-scratcher: RHEL 6 scan brings up findings saying rsyslog is not installed or configured. We are using the rsyslog7 package for compatibility with things like Splunk and LogStash and such. Is there a workaround or should I create a bug/issue about this ? Can rsyslog and rsylog7 be used interchangeably, and configured the same way by other rsyslog related rules? If so, RHEL6 can have own definition for package_rsyslog_installed checking for rsyslog or rsyslog7. In the mean time, the workaround is to edit the content to check for rsyslog7 instead of rsyslog. Look for the snippet below and change it to rsyslog7. rsyslog Dan White | d_e_wh...@icloud.com “Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.” (Bill Waterson: Calvin & Hobbes) ___ Open-scap-list mailing list Open-scap-list@redhat.com https://www.redhat.com/mailman/listinfo/open-scap-list -- Watson Sato Security Technologies | Red Hat, Inc___ Open-scap-list mailing list Open-scap-list@redhat.com https://www.redhat.com/mailman/listinfo/open-scap-list
Re: [Open-scap] RHEL 6 - rsyslog vs rsyslog7
On 23/01/18 13:42, Dan White wrote: Another head-scratcher: RHEL 6 scan brings up findings saying rsyslog is not installed or configured. We are using the rsyslog7 package for compatibility with things like Splunk and LogStash and such. Is there a workaround or should I create a bug/issue about this ? Can rsyslog and rsylog7 be used interchangeably, and configured the same way by other rsyslog related rules? If so, RHEL6 can have own definition for package_rsyslog_installed checking for rsyslog or rsyslog7. In the mean time, the workaround is to edit the content to check for rsyslog7 instead of rsyslog. Look for the snippet below and change it to rsyslog7. id="oval:ssg-obj_package_rsyslog_installed:obj:1" version="1"> rsyslog Dan White | d_e_wh...@icloud.com “Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.” (Bill Waterson: Calvin & Hobbes) ___ Open-scap-list mailing list Open-scap-list@redhat.com https://www.redhat.com/mailman/listinfo/open-scap-list -- Watson Sato Security Technologies | Red Hat, Inc ___ Open-scap-list mailing list Open-scap-list@redhat.com https://www.redhat.com/mailman/listinfo/open-scap-list
Re: [Open-scap] RHEL 7 GRUB2 boot password
On 23/01/18 20:56, Dan White wrote:
Something is very wrong here
[root@jump-linux7 ~]# cat /etc/grub.d/01_users # ORIGINAL
#!/bin/sh -e
cat << EOF
if [ -f \${prefix}/user.cfg ]; then
source \${prefix}/user.cfg
if [ -n "\${GRUB2_PASSWORD}" ]; then
set superusers="root"
export superusers
password_pbkdf2 root \${GRUB2_PASSWORD}
fi
fi
EOF
Then I have the output of "grub2-setpassword" :
[root@jump-linux7 ~]# cat /boot/grub2/user.cfg
GRUB2_PASSWORD=grub.pbkdf2.sha512.1.yadda-yadda-yadda
So, I copy the hash into /etc/grub.d/01_users :
[root@jump-linux7 ~]# cat /etc/grub.d/01_users
#!/bin/sh -e
cat << EOF
if [ -f \${prefix}/user.cfg ]; then
source \${prefix}/user.cfg
if [ -n "\${GRUB2_PASSWORD}" ]; then
set superusers="root"
export superusers
password_pbkdf2 root grub.pbkdf2.sha512.1.yadda-yadda-yadda
fi
fi
EOF
And then run
grub2-mkconfig -o /boot/grub2/grub.cfg
Checking "/boot/grub2/grub.cfg", I find
[root@jump-linux7 ~]# less /boot/grub2/grub.cfg
...
### BEGIN /etc/grub.d/00_tuned ###
set tuned_params=""
set tuned_initrd=""
### END /etc/grub.d/00_tuned ###
### BEGIN /etc/grub.d/01_users ###
if [ -f ${prefix}/user.cfg ]; then
source ${prefix}/user.cfg
if [ -n "${GRUB2_PASSWORD}" ]; then
set superusers="root"
export superusers
password_pbkdf2 root grub.pbkdf2.sha512.1.yadda-yadda-yadda
fi
fi
### END /etc/grub.d/01_users ###
...
But :
*Rule ID: xccdf_org.ssgproject.content_rule_bootloader_password*
*Result: fail*
*Identifiers: CCE-27309-4*
What the heck ?!
Indeed, the configuration file seems to be ok.
Can you run the evaluation with option --oval-results and check
"ssg-rhel7-oval.xml.result.xml" for results of
"rule_bootloader_password" and determine what is resulting in fail?
Or, if possible, attach snippet or file so we can take a look.
This way we can identify what definition or object is causing the fail.
--
Watson Sato
Security Technologies | Red Hat, Inc
___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list
