Re: [Open-scap] Stigviewer

[Dan White]

Are you referring to the DISA tool or the COTS/freeware tool ?

> On Apr 12, 2017, at 7:42 PM, Shawn Wells  wrote:
> 
> 
> 
>> On 4/12/17 7:08 PM, Matthew wrote:
>> Curious, what's the best way to use openscap, and be able to get
>> results for stigviewer?
> 
> IIRC, stigviewer can consume OVAL results. Something like:
> 
> oscap xccdf eval --profile stig --report human-readable.html --results
> stigviewer-readable.xml ssg-rhel7-ds.xml
> 
> ___
> 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

[Open-scap] Using authconfig rather than hand editing files

[Dan White]

I just messed up a baker’s dozen of RHEL 6 virtual machines by hand editing 
/etc/pam.d files system-auth-ac and password-auth-ac

I was able to un-mess 8 of them with an authconfig command.
The other 5 are in various stages of recovery.  One had a snapshot but the 
other 4 are Oracle servers that cannot be snapshot because of shared storage.

Anyway, what I am looking for here is some brainstorming toward implementing 
security settings with authconfig commands rather than hand editing the files 
that utility can alter.

Thanks.

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Using authconfig rather than hand editing files

[Dan White]

Šimon's suggestion was not posted to the list.

Long story short, he suggested I contact the software vendor - in this case Red 
Hat.



Again, thank you all for your thoughts.



On May 31, 2018, at 06:42 AM, Dan White  wrote:

Trimmed for readability


On May 31, 2018, at 04:01 AM, Pavel Březina  wrote:

On 05/30/2018 06:44 PM, Dan White wrote:

There are several pam stacks managed by authconfig:
- password-auth
- system-auth
- smartcard-auth
- fingerprint-auth
- postlogin

These files are just symlinks to $name-ac files that are written by
authconfig. If you need to do any changes that should persist, remove
the symlink and than edit the file without -ac suffix. Of course this
means that you stop using authconfig, but that is alright for most cases
as you need to configure it only once.


That is the whole point of the query.


This is for security hardening.
Authconfig removes stuff that needs to stay in.
I am suggesting updates for authconfig to provide the required settings
it currently removes.


Not using authconfig would make following many Red Hat documents difficult

Šimon made a suggestion I plan to follow.



Thanks for sharing your time and thoughts.


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

Re: [Open-scap] Using authconfig rather than hand editing files

[Dan White]

On May 29, 2018, at 05:26 AM, Marek Haicman  wrote:
On 05/27/2018 08:45 PM, Dan White wrote:

On May 27, 2018, at 12:02 PM, Šimon Lukašík mailto:sluka...@redhat.com>> wrote:


On 05/25/2018 11:06 PM, Dan White wrote:
I just messed up a baker’s dozen of RHEL 6 virtual machines by hand
editing /etc/pam.d files system-auth-ac and password-auth-ac
I was able to un-mess 8 of them with an authconfig command.
The other 5 are in various stages of recovery.  One had a snapshot
but the other 4 are Oracle servers that cannot be snapshot because of
shared storage.
Anyway, what I am looking for here is some brainstorming toward
implementing security settings with authconfig commands rather than
hand editing the files that utility can alter.
Thanks.


I am not sure this is right forum for this. Nevertheless, I wouldn't
be surprised this brainstorming ended before it even started as You
didn't provide us particular peculiarities you are faced with and thus
left us with very general (and thus hard) task at hand.


Kind regards,
~š.


OK, let’s start with RHEL-07-010200 - Set PAM's Password Hashing
Algorithm - CCE-27104-9


The Remediation shell script says:


|AUTH_FILES[0]="/etc/pam.d/system-auth"
AUTH_FILES[1]="/etc/pam.d/password-auth" for pamFile in
"${AUTH_FILES[@]}" do if ! grep -q
"^password.*sufficient.*pam_unix.so.*sha512" $pamFile; then sed -i
--follow-symlinks "/^password.*sufficient.*pam_unix.so/ s/$/ sha512/"
$pamFile fi done|




But up at the top of both of those files it says : *"User changes will
be destroyed the next time authconfig is run”*


Here are more:


RHEL-07-010119 - Set Password Retry Prompts Permitted Per-Session -
CCE-27160-1
RHEL-07-010270 - Limit Password Reuse - CCE-26923-3
RHEL-07-010290 - Prevent Log In to Accounts With Empty Password -
CCE-27286-4
RHEL-07-010320 - Set Deny For Failed Password Attempts - CCE-27350-8
RHEL-07-010320 - Set Interval For Counting Failed Password Attempts -
CCE-27297-1
RHEL-07-010320 - Set Lockout Time For Failed Password Attempts - CCE-26884-7
RHEL-07-010330 - Configure the root Account for Failed Password Attempts
- CCE-80353-6


Every one, in so many words, directs the hand editing of
/etc/pam.d/system-auth(-ac) and/or /etc/pam.d/password-auth(-ac)


Hopefully, this provides sufficient "particular peculiarities"


Back to my original question: How might one use the /authconfig/ command
to remediate each one of those ?


How about it ?
I will be tinkering on my own as time allows and I will gladly share
anything I discover.

Hello Dan,
historically, we have tried to use authconfig for some of the
remediations (smartcards), as it was kind of obvious choice, right?
Well, it fired back a bit, because you cannot really combine authconfig
and manual fixes. So after you made some of the more complex fixes by
hand (fixes that authconfig was not able to deliver) and then tried to
fix a triviality using authconfig tool, it would revert your manual change.

One of the problems of old authconfig (got added in RHEL7.4 I think,
RHEL6 is affected) is no support for `faillock`. So you cannot really
fix this one. So we gave up, and reverted to fixing everything by old
style sed-ing :(

Regards,
Marek



I am still looking for suggestions.



Here is an updated list of OpenSCAP references and the partial results of my 
tinkering:



Reference: 
https://static.open-scap.org/ssg-guides/ssg-rhel6-guide-stig-rhel6-disa.html

RHEL-06-00 - Set Password Retry Prompts Permitted Per-Session - CCE-27123-9 
- hand changes not overwritten by authconfig
RHEL-06-30 - Prevent Log In to Accounts With Empty Password - CCE-27038-9 - 
hand changes not overwritten by authconfig
RHEL-06-56 - Set Password Strength Minimum Digit Characters - CCE-26374-9 - 
hand changes not overwritten by authconfig
RHEL-06-57 - Set Password Strength Minimum Uppercase Characters - 
CCE-26601-5 - hand changes not overwritten by authconfig
RHEL-06-58 - Set Password Strength Minimum Special Characters - CCE-26409-3 
- hand changes not overwritten by authconfig
RHEL-06-59 - Set Password Strength Minimum Lowercase Characters - 
CCE-26631-2 - hand changes not overwritten by authconfig
RHEL-06-60 - Set Password Strength Minimum Different Characters - 
CCE-26615-5 - hand changes not overwritten by authconfig
RHEL-06-61 - Set Deny For Failed Password Attempts - CCE-26844-1 --- 
PROBLEM !!! authconfig wipes changes and cannot set them
RHEL-06-62 - Set Password Hashing Algorithm in /etc/pam.d/system-auth - 
CCE-26303-8 settable with authconfig (--passalgo=sha512)
RHEL-06-000274 - Limit Password Reuse - CCE-26741-9 --- PROBLEM !!! authconfig 
wipes changes and cannot set them
RHEL-06-000299 - Set Password to Maximum of Three Consecutive Repeating 
Characters - CCE-27227-8 not yet tested
RHEL-06-000356 - Set Lockout Time For Failed Password Attempts - CCE-27110-6 
not yet tested
RHEL-06-000357 - Set Interval For Cou

Re: [Open-scap] Using authconfig rather than hand editing files

[Dan White]

> On May 27, 2018, at 12:02 PM, Šimon Lukašík <sluka...@redhat.com> wrote:
> 
> On 05/25/2018 11:06 PM, Dan White wrote:
>> I just messed up a baker’s dozen of RHEL 6 virtual machines by hand editing 
>> /etc/pam.d files system-auth-ac and password-auth-ac
>> I was able to un-mess 8 of them with an authconfig command.
>> The other 5 are in various stages of recovery.  One had a snapshot but the 
>> other 4 are Oracle servers that cannot be snapshot because of shared storage.
>> Anyway, what I am looking for here is some brainstorming toward implementing 
>> security settings with authconfig commands rather than hand editing the 
>> files that utility can alter.
>> Thanks.
> 
> I am not sure this is right forum for this. Nevertheless, I wouldn't be 
> surprised this brainstorming ended before it even started as You didn't 
> provide us particular peculiarities you are faced with and thus left us with 
> very general (and thus hard) task at hand.
> 
> Kind regards,
> ~š.

OK, let’s start with RHEL-07-010200 - Set PAM's Password Hashing Algorithm - 
CCE-27104-9

The Remediation shell script says:
AUTH_FILES[0]="/etc/pam.d/system-auth"
AUTH_FILES[1]="/etc/pam.d/password-auth"

for pamFile in "${AUTH_FILES[@]}"
do
if ! grep -q "^password.*sufficient.*pam_unix.so.*sha512" $pamFile; then
sed -i --follow-symlinks "/^password.*sufficient.*pam_unix.so/ 
s/$/ sha512/" $pamFile
fi
done

But up at the top of both of those files it says : "User changes will be 
destroyed the next time authconfig is run”

Here are more:

RHEL-07-010119 - Set Password Retry Prompts Permitted Per-Session - CCE-27160-1
RHEL-07-010270 - Limit Password Reuse - CCE-26923-3
RHEL-07-010290 - Prevent Log In to Accounts With Empty Password - CCE-27286-4
RHEL-07-010320 - Set Deny For Failed Password Attempts - CCE-27350-8
RHEL-07-010320 - Set Interval For Counting Failed Password Attempts - 
CCE-27297-1
RHEL-07-010320 - Set Lockout Time For Failed Password Attempts - CCE-26884-7
RHEL-07-010330 - Configure the root Account for Failed Password Attempts - 
CCE-80353-6

Every one, in so many words, directs the hand editing of 
/etc/pam.d/system-auth(-ac) and/or /etc/pam.d/password-auth(-ac)

Hopefully, this provides sufficient "particular peculiarities"

Back to my original question: How might one use the authconfig command to 
remediate each one of those ?

How about it ?
I will be tinkering on my own as time allows and I will gladly share anything I 
discover.
___
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

[Open-scap] RHEL 7 GRUB2 boot password

[Dan White]

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



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

[Open-scap] RHEL 6 - rsyslog vs rsyslog7

[Dan White]

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 ?



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

Re: [Open-scap] RHEL 7 GRUB2 boot password

[Dan White]

"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 <ws...@redhat.com> 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] RHEL 7 GRUB2 boot password

[Dan White]

So then the description should be updated from

NOTE: It is recommended not to use common administrator account names like 
root, admin, or administrator for the grub2 superuser account.

to something like 

Do not use root, admin, or administrator for the grub2 superuser account.  The 
check will fail. 

Would you agree ?
Does an issue/bug need to be created for this to happen ?

"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 25, 2018, at 4:26 AM, Watson Yuuma Sato <ws...@redhat.com> wrote:
> 
>> On 24/01/18 21:05, Dan White wrote:
>> "superusers should be root, admin or administrator"
>> 
>> Are you sure it shouldn't be "superusers should NOT be root, admin or 
>> administrator" ?
> 
> You are correct, the superuser should not be root, admin nor 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 ?
> Current check only cares about the users mentioned above.
> -- 
> 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
___
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

[Dan White]

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 <d_e_wh...@icloud.com> 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 <ws...@redhat.com> 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
___
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

[Dan White]

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 <d_e_wh...@icloud.com> 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 <d_e_wh...@icloud.com> 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 <ws...@redhat.com> 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 hav

Re: [Open-scap] RHEL 6 - rsyslog vs rsyslog7

[Dan White]

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 <ws...@redhat.com> 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