search

plus3it / spel

STIG-Partitioned Enterprise Linux (spel)
Other
91 stars 61 forks source link

Permission denied errors for operations in /etc/ as of 2023.06.1 spel-minimal-rhel-7-hvm #614

Closed brandonrace closed 1 year ago

brandonrace commented 1 year ago

Expected behavior

shred /etc/gshadow- (as root) succeeds and gives no error shred /etc/shadow- (as root) succeeds and gives no error echo "Test" | sudo tee -a /etc/test-release succeeds and gives no error

Actual behavior

shred /etc/gshadow- failed to open for writing: Permission denied shred /etc/shadow- failed to open for writing: Permission denied echo "Test" | sudo tee -a /etc/test-release Permission denied

Steps to reproduce behavior

Run shred /etc/gshadow- (as root) Run shred /etc/shadow- (as root) Run echo "Test" | sudo tee -a /etc/test-release

Context/Specifications

We've been using your spel-minimal-rhel-7-hvm for a while. Going from 2023.05.2 to 2023.06.1, suddenly we are getting permission denied errors for operations in the /etc/ directory. These are just some specific example commands of errors that we are getting in our builds now that were working on the 05.2 version of the image, but started giving permission denied errors on the 06.1 version. I already compared the file permissions between versions and they didn't change. I'm not sure what could've changed on the Plus 3 It image because even the Changelog is only really showing package updates.

Suggestions for fix

I don't have any idea what even changed so I don't know how it would get fixed.

lorengordon commented 1 year ago

@brandonrace You're right, that was an oversight in the changelog. When you sudo from the default user, try sudo -r unconfined_r. I've tagged @ferricoxide as he has more info on the change. We'll need to update the changelog also.

ferricoxide commented 1 year ago

Per the updated STIG-guidance, all users must be confined. See V-204444 (RHEL-07-020020):

All administrators must be mapped to the , "staff_u", or an appropriately tailored confined SELinux user as defined by the organization.

As such, the provisioning-user, as created by cloud-init, has been confined to the staff_u since f9603ae was merged.

Per V-250314 (RHEL-07-020023), EL7 AMIs generated since 3f3a17d was merged should also have an appropriate sudoers configuration to obviate the need for explicitly-requesting an SELinux confined-role and confined type.

Note: staff_u with the STIG-prescribed sudoers confinement-mappings does still limit access to a number of "sensitive" files (the shadow files being two such files). You may be able to work around that by specifying -r unconfined_r -t unconfined_t (specifying only one or the other may result in an error) with your sudo command. However, we haven't actually tested to verify.

brandonrace commented 1 year ago

@lorengordon @ferricoxide

Thanks for the quick responses. Yes, this looks like this is exactly what is causing these errors now. I thought I had looked through the commits but must have missed this.

I understand that this is a STIG finding but is there a reason that this was added in? I was under the impression that these images were partitioned, but didn't do any additional hardening, and I don't think that this is related to partitioning. We prefer it this way as hardening before we complete our build process would cause us to have to rework some stuff. https://github.com/plus3it/spel#why-spel

lorengordon commented 1 year ago

To be fair, the commits are in the project that spel wraps around, Amigen7, so they're easy to miss.

Yes, we also prefer the image to be as thin as possible, but it certainly has evolved to do a little more than just the partitioning. This project handles things STIG-related that are "hard" to do with run-time automation. Partitioning is one, there's also SELinux and FIPS enforcement. This particular change is related to SELinux.

It may be possible to restore the unconfined setting, using #cloud-config to override the default settings. Something like:

#cloud-config

system_info:
  default_user:
    name: maintuser
    sudo: ["ALL=(root) NOPASSWD:ALL"]
    selinux_user: unconfined_u
ferricoxide commented 1 year ago

Yes, we also prefer the image to be as thin as possible, but it certainly has evolved to do a little more than just the partitioning. This project handles things STIG-related that are "hard" to do with run-time automation. Partitioning is one, there's also SELinux and FIPS enforcement. This particular change is related to SELinux.

In particular, because the scanners will flag the /etc/sudoers.d/90-cloud-init-users file created by cloud-init as being non-compliant when it lacks the TYPE=sysadm_t ROLE=sysadm_r, it was necessary to bake the SEL-related confinement and SEL-transition information into the AMI.

Note that the:

    sudo: ["ALL=(root) NOPASSWD:ALL"]

Offered by @lorengordon will probably result in a subsequent scan-failure (since the resultant /etc/sudoers.d/90-cloud-init-users file will lack the required SEL-transition tokens).

ferricoxide commented 1 year ago

Submitted PR #615 to update the project README to capture some of the elements discussed in this thread. Merging of the referenced-PR will close this issue.

brandonrace commented 1 year ago

@lorengordon @ferricoxide I've tried overwriting the sudo and selinux_user parameters back to what it was before and the errors are all still occurring, is there more that I would have to do other sed those two lines in /etc/cloud/cloud.cfg and restart cloud-init?

ferricoxide commented 1 year ago

I've tried overwriting the sudo and selinux_user parameters back to what it was before and the errors are all still occurring, is there more that I would have to do other sed those two lines in /etc/cloud/cloud.cfg and restart cloud-init?

Don't modify the /etc/cloud/cloud.cfg file: that won't do anything for you, at all. You need to apply the suggestions @loren made as part of your EC2's (initial) userData payload.

ferricoxide commented 1 year ago

Note: