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
_______________________________________________
FreeIPA-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/[email protected]
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
