Scripts are stripped of executable permission

[lmeinecke]

I noticed a while back that my custom scripts after applying the stig-fix lost their +x permission. While it was inconvenient it wasn't to big a deal. Today I ran one of my scripts to join RHEL6 to AD and noticed that /usr/sbin/authconfig which is linked to /usr/share/authconfig.py was saying permission denied and this is because it wasn't executable.

What directories do the stig-fix scripts remove executable permissions? What I thought was contained to home directories is not.

Thanks in advanced for all your support on this project!

[lmeinecke]

So my script stopped working because /etc/krb5.conf now has an encryption requirement of aes256-cts. I need to figure out if AD supports that.

In the process of troubleshooting authentication failure I noticed a typo in that file I suspect is from stig-fix:
default_tgs_enctypes = aes256-cts

is missing the first letter "d". Might take a look at the script that inserts that and see what is going on.

[fcaviggia]

Good catch there - I updated the 'config/krb5.conf' configuration file. Thanks for being a second set of eyes.

As to your earlier point, I call the scripts via apply.sh using 'sh cat/gen00.sh' I'm not sure they needed to be executable by themselves.

[lmeinecke]

Is it intended behavior for stig-fix to remove executable permissions from /usr/share/authconfig.py ?

[necrolyte2]

This is set in the gen000460.sh on line 41 to prevent accidental overwritting any of the authconfig files that were configured during apply.

https://github.com/RedHatGov/stig-fix-el6/blob/master/cat2/gen000460.sh#L41

[fcaviggia]

Hmm. My script drops everything in system-auth-local and password-auth-local and than links them to password-auth and system-auth - this removes authconfig's ability to change things. I think I should populate the -ac files with what is the default in config - just inc ase someone goes back to that.

[necrolyte2]

Doesn't the DISA stig have something explicitly saying to make those
symlinks though? Not sure you should change it. Let the user undo the links
if they have to.
On Oct 8, 2014 5:48 PM, "Frank Caviggia" [email protected] wrote:

Hmm. My script drops everything in system-auth-local and
password-auth-local and than links them to password-auth and system-auth -
this removes authconfig's ability to change things. I think I should
populate the -ac files with what is the default in config - just inc ase
someone goes back to that.

—
Reply to this email directly or view it on GitHub
#19 (comment)
.

[fcaviggia]

By linking -auth-local to the equivalent /etc/pam.d/-auth - it helps ensure that an errant system administrator doesn't change the policy with authconifg (that's generally what maintains the symlinks) or mucking around manually in the configuration that you are distributing across systems - I actually use RHN Satellite to maintain configurations at an enterprise level for the enclaves I maintain.

[necrolyte2]

Right. I was confirming that your scripts are doing what the DISA Stig instructs you to do. So to deviate from that would probably not be the best practice.

If a user wants to configure their PAM config files differently than what apply.sh does, they can customize themselves.

[fcaviggia]

That's why I'm pointing to the config/*-auth-local files - the defaults there are secured - they are there for people to add in things like Kerberos. winbind, or other types of authentication.