Ubuntu 22.04 existing sudo being overridden when using --remediate in oscap

[huornlmj]

Description of problem:

After running:

$ sudo -E oscap xccdf eval --remediate --profile $profile --results $profile.xml --report $profile.html --oval-results $scap

where:

$ echo $scap
/home/user/downloads/scap-security-guide-0.1.68/ssg-ubuntu2204-ds-1.2.xml
$ echo $profile
xccdf_org.ssgproject.content_profile_cis_level2_server

My standard sudo-allowed user loses sudo permissions.

SCAP Security Guide Version:

0.1.68

Operating System Version:

Linux Ubuntu 22.04.2 LTS

Steps to Reproduce:

1. Have a standard user with sudo permissions
2. Apply the above profile remediation
3. Observe that the standard user has now lost sudo permissions
4. No break glass option now available, reinstall OS or boot OS from an alternative source to manually fix the sudoers file

[dodys]

hey @huornlmj did you get any logs or error messages? Did you see any difference if you just use cis_level1_server?

I will try to reproduce it here in a few minutes, but any information in the meantime will be helpful.

[huornlmj]

I did some investigation and I found that the line in the /etc/sudoers that was providing the sudo group with sudo permissions had been remarked out by the remediation by OpenSCAP. I booted the system with a gpated ISO and manually uncommented it and rebooted and my limited user got sudo permissions back. Is it worth noting that I had lreviously already added the NOPASSWD:ALL to the same line?

[dodys]

I did some investigation and I found that the line in the /etc/sudoers that was providing the sudo group with sudo permissions had been remarked out by the remediation by OpenSCAP. I booted the system with a gpated ISO and manually uncommented it and rebooted and my limited user got sudo permissions back. Is it worth noting that I had lreviously already added the NOPASSWD:ALL to the same line?

yes that's helpful, it could be that it is messing up because of some "unexpected" configuration. I will be testing it and proposing a change. Thanks again!

[dodys]

@huornlmj by "Observe that the standard user has now lost sudo permissions" what do you mean? is it asking for sudo password?

[dodys]

reproduced it here, it seems that the remediation for sudo_require_authentication is commenting the whole %sudo... line. Do note that this rule will remove the NOPASSWD that you are manually including, even though I will try to fix the remediation to only remove the parameter instead of commenting the whole line, still that will affect your setup.

[dodys]

@huornlmj for now we are discussing if we should do something instead during the remediation, but the CIS benchmark specifically mentions: Remove any line with occurrences of NOPASSWD tags in the file. My recommendation in the meantime is that you use scap-workbench and customize the profile to not include sudo_require_authentication if your requirements are to have the NOPASSWD set for the sudo group.

[marcusburghardt]

This is a valid case, indeed. Regardless of the CIS mention, IMO the relevant rules should care about the line options only, as even mentioned in the rule descriptions. By commenting the entire line where the option is present seems to me more than the necessary to remediate and can also cause disruptions, as described in this issue.

It seems reasonable to me to update the macros used in these rules to remove the undesired options but honor the other configuration parameters in the line.

[dodys]

This is a valid case, indeed. Regardless of the CIS mention, IMO the relevant rules should care about the line options only, as even mentioned in the rule descriptions. By commenting the entire line where the option is present seems to me more than the necessary to remediate and can also cause disruptions, as described in this issue.

It seems reasonable to me to update the macros used in these rules to remove the undesired options but honor the other configuration parameters in the line.

Thanks @marcusburghardt, but I believe that just removing the parameters will create some incorrect configuration lines for example if I had a line like: Defaults:ubuntu !authenticate if I just remove the !authenticate that will create a syntax issue, that's why I suggested maybe just replacing the parameter.

[marcusburghardt]

This is a valid case, indeed. Regardless of the CIS mention, IMO the relevant rules should care about the line options only, as even mentioned in the rule descriptions. By commenting the entire line where the option is present seems to me more than the necessary to remediate and can also cause disruptions, as described in this issue. It seems reasonable to me to update the macros used in these rules to remove the undesired options but honor the other configuration parameters in the line.

Thanks @marcusburghardt, but I believe that just removing the parameters will create some incorrect configuration lines for example if I had a line like: Defaults:ubuntu !authenticate if I just remove the !authenticate that will create a syntax issue, that's why I suggested maybe just replacing the parameter.

Hi @dodys , this is also a great and valid example. Now it is much more clear for me the reason of just replacing the parameter by its opposite representation. I agree with you.