hardening-script-el6 icon indicating copy to clipboard operation
hardening-script-el6 copied to clipboard

Scripts are stripped of executable permission

Open lmeinecke opened this issue 10 years ago • 9 comments

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 avatar Oct 07 '14 21:10 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.

lmeinecke avatar Oct 07 '14 22:10 lmeinecke

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.

fcaviggia avatar Oct 08 '14 11:10 fcaviggia

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

lmeinecke avatar Oct 08 '14 15:10 lmeinecke

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

necrolyte2 avatar Oct 08 '14 16:10 necrolyte2

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.

fcaviggia avatar Oct 08 '14 21:10 fcaviggia

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 https://github.com/RedHatGov/stig-fix-el6/issues/19#issuecomment-58433434 .

necrolyte2 avatar Oct 08 '14 21:10 necrolyte2

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.

fcaviggia avatar Oct 09 '14 11:10 fcaviggia

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.

necrolyte2 avatar Oct 09 '14 11:10 necrolyte2

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.

fcaviggia avatar Oct 09 '14 15:10 fcaviggia