Description of problem: Samba AD DC generates following error when bound to an interface. Binding hosts fails. type=AVC msg=audit(1572902737.830:35476): avc: denied { create } for pid=34316 comm="testparm" name="34316" scontext=staff_u:sysadm_r:sysadm_t:s0:c0.c1023 tcontext=staff_u:object_r:samba_var_t:s0 tclass=sock_file permissive=1 type=SYSCALL msg=audit(1572902737.830:35476): arch=c000003e syscall=49 success=yes exit=0 a0=6 a1=7ffde2439a30 a2=6e a3=7ffde2439714 items=2 ppid=34314 pid=34316 auid=5000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=6 comm="testparm" exe="/usr/bin/testparm" subj=staff_u:sysadm_r:sysadm_t:s0:c0.c1023 key=(null) type=CWD msg=audit(1572902737.830:35476): cwd="/home/dc1" type=PATH msg=audit(1572902737.830:35476): item=0 name="/var/lib/samba/private/msg.sock/" inode=786922 dev=fd:02 mode=040700 ouid=0 ogid=0 rdev=00:00 obj=staff_u:object_r:samba_var_t:s0 nametype=PARENT cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0 type=PATH msg=audit(1572902737.830:35476): item=1 name="/var/lib/samba/private/msg.sock/34316" inode=787060 dev=fd:02 mode=0140750 ouid=0 ogid=0 rdev=00:00 obj=staff_u:object_r:samba_var_t:s0 nametype=CREATE cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0 Version-Release number of selected component (if applicable): Current Fedora 31 Stable with Testing Branch of Samba package How reproducible: Steps to Reproduce: # Install/configure basic samba ad dc sudo dnf -yq install samba samba-dc # https://bugzilla.redhat.com/show_bug.cgi?id=1757071#c25 sudo dnf -yq update samba --enablerepo updates-testing sudo setsebool -P domain_can_mmap_files 1 sudo rm /etc/samba/smb.conf sudo samba-tool domain provision --use-rfc2307 --site=SITENAME --option="interfaces=lo ens192" --option="bind interfaces only=yes" #default everything else sudo cp -a /var/lib/samba/private/krb5.conf /etc/ sudo systemctl start samba sudo testparm /etc/samba/smb.conf #no errors Actual results: 1. Selinux error 2. Binding host fails Expected results: Binding host succeeds (tested via `setenforce 0`) Additional info: Binding host also succeeded when `interfaces=lo ens192` and `bind interfaces only=yes` are removed from smb.conf
I cant reproduce the scenario. Do you have some functionality issues? Because it's weird that program, which checks for internal correctness of configuration files, wants to create a sock_file. Thanks, Richard.
I have several generic hardening configurations that I apply to the system before configuring specific services. I can provide all of that, but I believe the only relevant part is this: ``` # set our user context to staff sudo semanage login -a -s staff_u -rs0:c0.c1023 "$(whoami)" # set appropriate context on our home folder sudo restorecon -FR /home/$(whoami) # allow sudo to escalate us to sysadm echo "$(whoami) ALL=(ALL) TYPE=sysadm_t ROLE=sysadm_r ALL" | sudo tee /etc/sudoers.d/"$(whoami)" >/dev/null ``` I have found that sysadm does get in the way of some software installation/configuration (clamav for instance), but this is the only case I've run into where it causes issues with the ongoing functionality of a service (can't bind clients to AD). If you are still unable to recreate the issue, I will attempt it again. I believe the previous testing branch of samba has been merged now. As far as why testparm is creating a sock file, maybe it is testing the specified interface somehow? I have no idea, but clearly it is doing it based on the logs. I will ask in the samba mailing list.
I still can't reproduce that, but I will make a scratch build with fix and you can install it and check the result. When it will be ok, I will fix it in SELinux policy package.
You can install the scratch build from this link: https://copr-be.cloud.fedoraproject.org/results/rfilo/Selinux-policy-f31/fedora-31-x86_64/01118205-selinux-policy/ After installation, please rerun the scenario and check results.
Thanks, I am out of the office this week, but I will give it a shot when I'm back.
Ok, thanks.
The scratch build was ok? If no, can you give me more info about it?
Please see comment#7.
Hey, sorry I was put on a different project and then out for the holidays. I am back now. The issue with interface binding persists but appears to be unrelated to selinux. I don't see anything in the samba logs, but the client (macOS) has several errors including `error: SASL_BIND_IN_PROGRESS` and `57: Socket is not connected`. It may be quirk of macOS/AD interoperability (although, strange that it would work perfectly without interface binding enabled). I don't have a Windows client to test on to see if this is the case. I can explore further, but I understand if macOS binding to Samba DC is too much of an edge case.
Hi dD.d. If you put SELinux to permissive mode, by running: # setenforce 0 Are you able to reproduce the issue then? Thanks, Lukas. PS: Don't forget to move SELinux back to enforcing by: # setenforce 1
The Samba DC service is still not working for me when I configure interface binding. However, this is independent of SELinux (occurs whether or not enforcing). The SELinux items in the log that I described in the initial ticket are no longer present in updated Fedora 31. Since this ticket is categorized as SELinux policy, it should probably be closed (or recategorized?) since the policy conflicts are no longer present and are not causing the issue.
I see this was recategorized from selinux to Samba, so I will continue working on this. I will try to rebuild a test DC from scratch in current Fedora 31 to see if the issue persists since I had originally provisioned it using the testing branch per the earlier issue regarding encryption types. Will report back with results. Should have a chance to test sometime this week or next week latest.
This message is a reminder that Fedora 31 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '31'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 31 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 31 changed to end-of-life (EOL) status on 2020-11-24. Fedora 31 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.