Strange Permissions Issue (rhel 8 disa stig)

Latest response

After applying rhel 8 disa stig draft in remediation:

oscap xccdf eval --remediate --profile xccdf_org.ssgproject.content_profile_stig /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml

to a newly built rhel 8 system and then rebooting, I am experiencing a strange "access denied" issue when attempting to modify certain types of files inside my /home/[user]/ directory

For instance, if I create a file in my home directory test.py and put

#!/usr/bin/env python3

in the file and save it, it can have all the right permissions, but if I try to open it or copy it (within the same home directory) I will get an "access denied" permissions error. (If I do the same before running stig and rebooting, I can manipulate the same file just fine).

If I then run:

file test.py

It says it is an executable, regular file, no read permissions. Even though it has 644. I can change the permissions to 777 and it's owned by my user and my user's group and then I try to open or copy it (to the same home directory) I still get the same permissions error message. If I elevate to root via sudo or su, I can manipulate the file again without error.

On the other hand, if I create another file: test.sh in /home/[user]/ directory and put the following in it:

#!/bin/bash

set -e

echo "testing"

I can open it, write to it, move it copy it, etc... No errors.

Additionally, if I just create a file: test.py and put something non-python related in it:

"testing"

or whatever, I can open it, copy it write to it, etc.

I checked the file test.py and home directory with ls -Z, getfattr, getfacl and I can't find anything wrong.

I also checked and tried changing some of the /home partition's mount options such as nodev, nosuid but it didn't make any difference.

/home is mounted (via lvm) on its own local, non-network partition, permanently in fstab, as rw

I have also tried setting selinux to permissive and turning selinux off completely and it didn't make a difference.

I did notice, when I started doing ll -a on python3 that it consists of a hefty symlink chain which seems unnecessary, but am unsure if that has anything to do with my issue.

At first, one of the thoughts I had was that the file(s) I was trying to manipulate had crlf endings instead of lf, but then when I created that test file, on-system, that kind of dispelled that theory.

Does anyone have any ideas?

p.s. I should also mention that I have tested the same scenarios several times on different hardware, and virtual machines running rhel 8.

bm

Responses