On 25/01/2022 14:21, Rob Crittenden wrote:
lejeczek via FreeIPA-users wrote:
> On 19/01/2022 16:34, Rob Crittenden wrote:
>> lejeczek via FreeIPA-users wrote:
>>> Hi guys.
>>>
>>> Has anybody seen, experienced that/similar? - this is a second master
>>> from which I uninstalled IPA successfully, cleanly and immediately after
>>> reboot system does not login users(not even tty console)
>>>
>>> Something to do with SELinux/fcontext - I had to def-policy-relabeled
>>> whole '/etc'
>> I've never seen a report of this, and our automated testing does a lot
>> of install/re-install but generally lacks a reboot.
>>
>> Can you provide the AVCs for the failures?
>>
>> rob
>>
> Immediately after 'unistall', before reboot, issues arise:
>
> -> $ journalctl -lf -o cat -u sshd
> PAM _pam_load_conf_file: unable to open config for password-auth
> PAM _pam_load_conf_file: unable to open config for postlogin
> fatal: Access denied for user root by PAM account configuration [preauth]
> PAM _pam_load_conf_file: unable to open config for password-auth
> PAM _pam_load_conf_file: unable to open config for postlogin
> PAM _pam_load_conf_file: unable to open config for password-auth
> PAM _pam_load_conf_file: unable to open config for password-auth
> PAM _pam_load_conf_file: unable to open config for password-auth
> PAM _pam_load_conf_file: unable to open config for postlogin
> fatal: Access denied for user root by PAM account configuration [preauth]
> PAM _pam_load_conf_file: unable to open config for password-auth
> PAM _pam_load_conf_file: unable to open config for postlogin
> PAM _pam_load_conf_file: unable to open config for password-auth
> PAM _pam_load_conf_file: unable to open config for password-auth
> PAM _pam_load_conf_file: unable to open config for password-auth
> PAM _pam_load_conf_file: unable to open config for postlogin
> fatal: Access denied for user root by PAM account configuration [preauth]
>
> 'journal' full of denials:
>
> If you believe that sshd should be allowed read access on the
> password-auth file by default.
> Then you should report this as a bug.
> You can generate a local policy module to allow this access.
> Do
> allow this access for now by executing:
> # ausearch -c 'sshd' --raw | audit2allow -M my-sshd
> # semodule -X 300 -i my-sshd.pp
>
>
> AnalyzeThread.run(): Set alarm timeout to 10
> AnalyzeThread.run(): Cancel pending alarm
> AVC Message for setroubleshoot, dropping message
> AVC Message for setroubleshoot, dropping message
> AVC Message for setroubleshoot, dropping message
> ....
>
> ....
>
> SELinux is preventing /usr/sbin/sshd from read access on the file
> password-auth. For complete SELinux messages run: sealert -l
> 4aaa291e-a99a-439a-97e1-c810df760e9d
> SELinux is preventing /usr/sbin/sshd from read access on the file
> password-auth.
>
> ***** Plugin catchall_labels (83.8 confidence) suggests
> *******************
>
> If you want to allow sshd to have read access on the password-auth file
> Then you need to change the label on password-auth
> Do
> # semanage fcontext -a -t FILE_TYPE 'password-auth'
> where FILE_TYPE is one of the following: NetworkManager_etc_rw_t,
> NetworkManager_etc_t, NetworkManager_tmp_t, abrt_etc_t,
> abrt_helper_exec_t, abrt_tmp_t, abrt_upload_watch_tmp_t,
> abrt_var_cache_t, abrt_var_run_t,......
>
> ...
>
> If you believe that sshd should be allowed read access on the
> nsswitch.conf file by default.
> Then you should report this as a bug.
> You can generate a local policy module to allow this access.
> Do
> allow this access for now by executing:
> # ausearch -c 'sshd' --raw | audit2allow -M my-sshd
> # semodule -X 300 -i my-sshd.pp
>
>
> Additional Information:
> Source Context system_u:system_r:sshd_t:s0-s0:c0.c1023
> Target Context system_u:object_r:var_lib_t:s0
> Target Objects nsswitch.conf [ file ]
> Source sshd
> Source Path /usr/sbin/sshd
> Port <Unknown>
> Host sucker.private.ccn
> Source RPM Packages openssh-server-8.0p1-12.el8.x86_64
> Target RPM Packages
> SELinux Policy RPM selinux-policy-targeted-3.14.3-86.el8.noarch
> Local Policy RPM selinux-policy-targeted-3.14.3-86.el8.noarch
> Selinux Enabled True
> Policy Type targeted
> Enforcing Mode Enforcing
> Host Name sucker.private.ccn
> Platform Linux sucker.private.ccn
> 4.18.0-358.el8.x86_64 #1 SMP Mon Jan 10
> 13:11:20
> UTC 2022 x86_64 x86_64
> Alert Count 425
> First Seen 2022-01-25 11:11:34 GMT
> Last Seen 2022-01-25 11:15:47 GMT
> Local ID 4aaa291e-a99a-439a-97e1-c810df760e9d
>
> Raw Audit Messages
> type=AVC msg=audit(1643109347.32:6982): avc: denied { read } for
> pid=28594 comm="sshd" name="nsswitch.conf" dev="vda1"
ino=13336622
> scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023
> tcontext=system_u:object_r:var_lib_t:s0 tclass=file permissive=0
>
>
> type=SYSCALL msg=audit(1643109347.32:6982): arch=x86_64 syscall=openat
> success=no exit=EACCES a0=ffffff9c a1=7f93cdee1041 a2=80000 a3=0 items=0
> ppid=27678 pid=28594 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0
> egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=sshd
> exe=/usr/sbin/sshd subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null)
>
> Hash: sshd,sshd_t,var_lib_t,file,read
>
> I'm not trying '.autorelabel' tough I doubt I will fix the
'uninstall'
> issue permanently.
So at least in this case it has to do with the restore of
/etc/nsswitch.conf. Looks like it is retaining the backed-up context.
Can you post the other raw AVCs? Those appear to be related to the
authselect configuration, also potentially not being restored properly.
What distribution is this?
I think problem 'got' fixed permanently by '.autorelabel' - immediate
reboot after 'uninstall' and now subsequent IPA deployment+uninstall do
not result in this problem.
Centos Stream 8