[Open-scap] Using authconfig rather than hand editing files

Wed May 30 20:54:11 UTC 2018

On 05/30/2018 06:44 PM, Dan White wrote:
> On May 30, 2018, at 08:03 AM, Pavel Březina <pbrezina at redhat.com> wrote:
>> On 05/29/2018 03:03 PM, Marek Haicman wrote:
>>> Pavel, can you help us with authconfig? :)
>>>
>>> On 05/29/2018 01:08 PM, Dan White wrote:
>>>> On May 29, 2018, at 05:26 AM, Marek Haicman <mhaicman at redhat.com> wrote:
>>>> On 05/27/2018 08:45 PM, Dan White wrote:
>>>>>>> On May 27, 2018, at 12:02 PM, Šimon Lukašík <slukasik at redhat.com
>>>>>>> <mailto:slukasik at redhat.com>> wrote:
>>>>>>>
>>>>>>> On 05/25/2018 11:06 PM, Dan White wrote:
>>>>>>>> I just messed up a baker’s dozen of RHEL 6 virtual machines by hand
>>>>>>>> editing /etc/pam.d files system-auth-ac and password-auth-ac
>>>>>>>> I was able to un-mess 8 of them with an authconfig command.
>>>>>>>> The other 5 are in various stages of recovery.  One had a snapshot
>>>>>>>> but the other 4 are Oracle servers that cannot be snapshot 
>>>>>>>> because of
>>>>>>>> shared storage.
>>>>>>>> Anyway, what I am looking for here is some brainstorming toward
>>>>>>>> implementing security settings with authconfig commands rather than
>>>>>>>> hand editing the files that utility can alter.
>>>>>>>> Thanks.
>>>>>>>
>>>>>>> I am not sure this is right forum for this. Nevertheless, I wouldn't
>>>>>>> be surprised this brainstorming ended before it even started as You
>>>>>>> didn't provide us particular peculiarities you are faced with and 
>>>>>>> thus
>>>>>>> left us with very general (and thus hard) task at hand.
>>>>>>>
>>>>>>> Kind regards,
>>>>>>> ~š.
>>>>>>
>>>>>> OK, let’s start with RHEL-07-010200 - Set PAM's Password Hashing
>>>>>> Algorithm - CCE-27104-9
>>>>>>
>>>>>> The Remediation shell script says:
>>>>>>
>>>>>> |AUTH_FILES[0]="/etc/pam.d/system-auth"
>>>>>> AUTH_FILES[1]="/etc/pam.d/password-auth" for pamFile in
>>>>>> "${AUTH_FILES[@]}" do if ! grep -q
>>>>>> "^password.*sufficient.*pam_unix.so.*sha512" $pamFile; then sed -i
>>>>>> --follow-symlinks "/^password.*sufficient.*pam_unix.so/ s/$/ sha512/"
>>>>>> $pamFile fi done|
>>>>>>
>>>>>>
>>>>>> But up at the top of both of those files it says : *"User changes will
>>>>>> be destroyed the next time authconfig is run”*
>>>>>>
>>>>>> Here are more:
>>>>>>
>>>>>> RHEL-07-010119 - Set Password Retry Prompts Permitted Per-Session -
>>>>>> CCE-27160-1
>>>>>> RHEL-07-010270 - Limit Password Reuse - CCE-26923-3
>>>>>> RHEL-07-010290 - Prevent Log In to Accounts With Empty Password -
>>>>>> CCE-27286-4
>>>>>> RHEL-07-010320 - Set Deny For Failed Password Attempts - CCE-27350-8
>>>>>> RHEL-07-010320 - Set Interval For Counting Failed Password Attempts -
>>>>>> CCE-27297-1
>>>>>> RHEL-07-010320 - Set Lockout Time For Failed Password Attempts -
>>>>>> CCE-26884-7
>>>>>> RHEL-07-010330 - Configure the root Account for Failed Password
>>>>>> Attempts
>>>>>> - CCE-80353-6
>>>>>>
>>>>>> Every one, in so many words, directs the hand editing of
>>>>>> /etc/pam.d/system-auth(-ac) and/or /etc/pam.d/password-auth(-ac)
>>>>>>
>>>>>> Hopefully, this provides sufficient "particular peculiarities"
>>>>>>
>>>>>> Back to my original question: How might one use the /authconfig/
>>>>>> command
>>>>>> to remediate each one of those ?
>>>>>>
>>>>>> How about it ?
>>>>>> I will be tinkering on my own as time allows and I will gladly share
>>>>>> anything I discover.
>>>>>
>>>>> Hello Dan,
>>>>> historically, we have tried to use authconfig for some of the
>>>>> remediations (smartcards), as it was kind of obvious choice, right?
>>>>> Well, it fired back a bit, because you cannot really combine authconfig
>>>>> and manual fixes. So after you made some of the more complex fixes by
>>>>> hand (fixes that authconfig was not able to deliver) and then tried to
>>>>> fix a triviality using authconfig tool, it would revert your manual
>>>>> change.
>>>>>
>>>>> One of the problems of old authconfig (got added in RHEL7.4 I think,
>>>>> RHEL6 is affected) is no support for `faillock`. So you cannot really
>>>>> fix this one. So we gave up, and reverted to fixing everything by old
>>>>> style sed-ing :(
>>>>>
>>>>> Regards,
>>>>> Marek
>>>>
>>>> I am still looking for suggestions.
>>>>
>>>> Here is an updated list of OpenSCAP references and the partial results
>>>> of my tinkering:
>>>>
>>>> Reference:
>>>> https://static.open-scap.org/ssg-guides/ssg-rhel6-guide-stig-rhel6-disa.html
>>>>
>>>>
>>>> RHEL-06-000000 - Set Password Retry Prompts Permitted Per-Session -
>>>> CCE-27123-9 - hand changes not overwritten by authconfig
>>>> RHEL-06-000030 - Prevent Log In to Accounts With Empty Password -
>>>> CCE-27038-9 - hand changes not overwritten by authconfig
>>>> RHEL-06-000056 - Set Password Strength Minimum Digit Characters -
>>>> CCE-26374-9 - hand changes not overwritten by authconfig
>>>> RHEL-06-000057 - Set Password Strength Minimum Uppercase Characters -
>>>> CCE-26601-5 - hand changes not overwritten by authconfig
>>>> RHEL-06-000058 - Set Password Strength Minimum Special Characters -
>>>> CCE-26409-3 - hand changes not overwritten by authconfig
>>>> RHEL-06-000059 - Set Password Strength Minimum Lowercase Characters -
>>>> CCE-26631-2 - hand changes not overwritten by authconfig
>>>> RHEL-06-000060 - Set Password Strength Minimum Different Characters -
>>>> CCE-26615-5 - hand changes not overwritten by authconfig
>>>> RHEL-06-000061 - Set Deny For Failed Password Attempts - CCE-26844-1
>>>> --- PROBLEM !!! authconfig wipes changes and cannot set them
>>>> RHEL-06-000062 - Set Password Hashing Algorithm in
>>>> /etc/pam.d/system-auth - CCE-26303-8 settable with authconfig
>>>> (--passalgo=sha512)
>>>> RHEL-06-000274 - Limit Password Reuse - CCE-26741-9 --- PROBLEM !!!
>>>> authconfig wipes changes and cannot set them
>>>> RHEL-06-000299 - Set Password to Maximum of Three Consecutive
>>>> Repeating Characters - CCE-27227-8 not yet tested
>>>> RHEL-06-000356 - Set Lockout Time For Failed Password Attempts -
>>>> CCE-27110-6 not yet tested
>>>> RHEL-06-000357 - Set Interval For Counting Failed Password Attempts -
>>>> CCE-27215-3 not yet tested
>>>>
>>>> Reference:
>>>> https://static.open-scap.org/ssg-guides/ssg-rhel7-guide-stig-rhel7-disa.html
>>>>
>>>>
>>>> RHEL-07-010200 - Set PAM's Password Hashing Algorithm - CCE-27104-9
>>>> settable with authconfig (--passalgo=sha512)
>>>> RHEL-07-010119 - Set Password Retry Prompts Permitted Per-Session -
>>>> CCE-27160-1 - hand changes not overwritten by authconfig
>>>> RHEL-07-010270 - Limit Password Reuse - CCE-26923-3 --- PROBLEM !!!
>>>> authconfig wipes changes and cannot set them
>>>> RHEL-07-010290 - Prevent Log In to Accounts With Empty Password -
>>>> CCE-27286-4 - hand changes not overwritten by authconfig
>>>> RHEL-07-010320 - Set Deny For Failed Password Attempts - CCE-27350-8
>>>> --- PROBLEM !!! authconfig wipes hand changes and cannot set all of
>>>> them (PARTIAL) --enablefaillock --faillockargs="deny=3
>>>> unlock_time=never fail_interval=900"
>>>> RHEL-07-010320 - Set Interval For Counting Failed Password Attempts -
>>>> CCE-27297-1 not yet tested
>>>> RHEL-07-010320 - Set Lockout Time For Failed Password Attempts -
>>>> CCE-26884-7 not yet tested
>>>> RHEL-07-010330 - Configure the root Account for Failed Password
>>>> Attempts - CCE-80353-6 not yet tested
>>>>
>>>> Would a BugZilla ticket get any traction ?  Who maintains authconfig ?
>>
>> BZ for what? I'm not sure what exactly do you want to achieve with
>> authconfig.
>>
>> Some of these changes can be done through authconfig, for example it can
>> configure pam_pwquality for password complexity. See authconfig --help
>> for all the options.
>>
>> Manual changes will be overwritten next time authconfig is called.
> 
> That is the whole point of the query.
> 
> This is for security hardening.
> Authconfig removes stuff that needs to stay in.
> I am suggesting updates for authconfig to provide the required settings 
> it currently removes.
> 

Maybe if you are not able to figure this out yourself, You would be 
better served contacting your software vendor.

Historically, this mailing list was devoted to solving concrete 
technical problems around compliance audit. What we really like are 
people who can divide their problems into subproblems, sit calmly and 
analyze cause-effect relation ship between those. That's intellectually 
appealing, sometimes even intriguing and keeps discussion on certain level.

Especially, I didn't like the point where you did asked about who 
maintains authconfig. It felt like you would like to blame some one, but 
that is not how this works. Authconfig has its own upstream, where 
various contributors share their code and allow others to eat fruits of 
their work. In various distributions other people may volunteer (or be 
employed to) tailor authconfig upstream to the specific needs of the 
distribution.

You need some one sitting on his butt and analyzing whether the problems 
you are seeing are caused by
  - design problem in authconfig upstream
  - problem of tailored authconfig in your distribution
  - bug in SSG
  - or inability to apply compliance profile to the setup you have in 
your organization
  - or any other cause really

Again, if you are not able to locate the problem for yourself, you may 
upside in delegating this work to someone else. If you happen to have a 
contract with your software vendor, it shouldn't be that hard to reach 
them out.

Kind regards,
~š.