Description of problem: After running samba 3.28 on RHEL 5.2 for over a year without error I finally downloaded the 5.3 updates. Samba was updated from 3.28 to 3.33. After the update AVC denials began populating /var/log/audit/audit.log: Version-Release number of selected component (if applicable): # smbd -V Version 3.0.33-3.7.el5 How reproducible: This is consistent with my test image (based on 5.2/samba 3.28) which I have performed 3 times now. Steps to Reproduce: 1. Install a copy of 5.2 (fully patched) with 2. Samba 3.28 and the attached smb.conf file below. 3. run: yum -y update (patch only to the 5.3 packages) 3. reboot Actual results: (this is just the highlight reel) # cat /var/log/audit/audit.log | grep denied Winbind cannot access secrets.tdb type=AVC msg=audit(1239225692.311:1318): avc: denied { write } for pid=7339 comm="winbindd" name="secrets.tdb" dev=dm-0 ino=950343 scontext=root:system_r:winbind_t:s0 tcontext=root:object_r:samba_etc_t:s0 tclass=file This breaks samba if used in conjunction with ldap and all nt groups are stored in the ldap database. SMBD cannont communicate with Winbind via the named pipe: type=AVC msg=audit(1239302885.488:26017): avc: denied { connectto } for pid=25591 comm="smbd" path="/var/run/winbindd/pipe" scontext=root:system_r:smbd_t:s0 tcontext=root:system_r:initrc_t:s0 tclass=unix_stream_socket This one speaks for it's self. Expected results: Samba should have performed the same after the update, as it did before: without any AVC denials. Additional info: I'm still somewhat green with the rpm packaging concepts but it seems that restorcon should have been included in the install scripts within the samba rpms. If there's anything I can do to perform root-cause analysis please let me know. Also, this is my first bug submission. If there are unfilled blanks above please route this, internally, the correct way. I'm not sure what your processes are. Thanks T
Dan is this something we can/should address within the spec file, or is it something you need to change in the policy ? (I think we already have a bug open for secrets.tdb, but can't find it right now)
(In reply to comment #1) > Dan is this something we can/should address within the spec file, or is it > something you need to change in the policy ? > (I think we already have a bug open for secrets.tdb, but can't find it right > now) I ran a fairly exhaustive search myself for all keywords, secrets.tdb being one of them, and I didn't find anything that seemed to speak to this problem. On the other points, yes, I can adjust the policy as a work-around but, again, if it can be fixed at the top level by including a restorecon statement in the scripting, resident within the distributed rpm, then it should diminish unnecessary hassles. As I have never had a problem with this I've really never had to dig into it. My root-cause breakdown is weak, I know that. I'm leaving the most appropriate solution to those who can speak intelligently on the subject.
Something is causing secrets.tdb to be mislabeled. If the post install of the samb script is recreating this file then it should run restorecon on it to make sure it is labeled correctly. SMBD cannont communicate with Winbind via the named pipe: type=AVC msg=audit(1239302885.488:26017): avc: denied { connectto } for pid=25591 comm="smbd" path="/var/run/winbindd/pipe" scontext=root:system_r:smbd_t:s0 tcontext=root:system_r:initrc_t:s0 tclass=unix_stream_socket This one speaks for it's self. This indicates that smbd is trying to communicate with a process running as initrc_t, winbind? Which indicates something was started incorrectly or some executable is not labeled correctly? Or this is caused by the way the testing is run. initrc_t means that something is running in the same context as the init script.
Here are some resolution notes: Find which processes are running as initrc_t: # ps auxZ | grep initrc_t system_u:system_r:initrc_t root 2427 0.0 0.0 65292 276 ? Ss Apr08 0:00 rpc.rquotad system_u:system_r:initrc_t zimbra 3353 0.0 0.1 43160 9880 ? S Apr08 0:03 /usr/bin/perl /tmp/.swatch_script.3245 root:system_r:unconfined_t:SystemLow-SystemHigh root 4194 0.0 0.0 61172 736 pts/0 R+ 15:47 0:00 grep initrc_t root:system_r:initrc_t root 4965 0.0 0.0 109644 1888 ? Ss Apr08 0:00 winbindd root:system_r:initrc_t root 4966 0.0 0.0 109644 1880 ? S Apr08 0:00 winbindd *Both winbind processes are running under the user Type 'initrc_t'. **Also, rpc.rquotad is incorrect as well***** *This is only good while booting the system. *This should be changed. --- Locate the winbind startup script: # locate winbindd ... /etc/rc.d/init.d/winbind ... --- # ls -lZ /etc/rc.d/init.d/winbind -rwxr-xr-x root root system_u:object_r:initrc_exec_t /etc/rc.d/init.d/winbind --- Restore the correct context back to the startup script and the binary: # restorecon -R -v /etc/rc.d/init.d/winbind # restorecon -v /usr/sbin/winbindd --- Restart the winbind service: # service winbind restart --- Verify that the changes are correct. It would be difficult to wait for another AVC denial to NOT be dropped in audit.log so: # ps auxZ | grep initrc_t system_u:system_r:initrc_t root 2427 0.0 0.0 65292 276 ? Ss Apr08 0:00 rpc.rquotad system_u:system_r:initrc_t zimbra 3353 0.0 0.1 43160 9880 ? S Apr08 0:03 /usr/bin/perl /tmp/.swatch_script.3245 system_u:system_r:initrc_t zimbra 3379 0.0 0.1 45924 6320 ? S Apr08 0:08 /usr/bin/perl /opt/zimbra/libexec/zmlogger root:system_r:unconfined_t:SystemLow-SystemHigh root 20590 0.0 0.0 61172 736 pts/0 R+ 16:21 0:00 grep initrc_t Winbind is no longer running as user Type initrc_t. --- Verify winbind is running in it's proper domain. # ps auxZ | grep winbind root:system_r:unconfined_t:SystemLow-SystemHigh root 4734 0.0 0.2 26496 16332 ? Ss Apr08 0:00 restorecond /var/run/winbindd/pipe root:system_r:winbind_t root 18316 0.0 0.0 109396 1908 ? Ss 16:16 0:00 winbindd root:system_r:winbind_t root 18317 0.0 0.0 109648 2052 ? S 16:16 0:00 winbindd root:system_r:unconfined_t:SystemLow-SystemHigh root 20987 0.0 0.0 61172 740 pts/0 R+ 16:22 0:00 grep winbind The proper user Type context has been restored back to the winbind service. === I'm not sure if these notes belong here so let me know how you would like these in the future if this not the right place for them. In an effort to triangulate the problem I have burned down the test server to begin the process again. I have additional notes from that. Please let me know where to put them. T
rpc.quotad should have a policy. Fixed in selinux-policy-2.4.6-225.rhel5 I don't know why winbind was labeled incorrectly.
But after the install of samba, you need to make sure the secrets.tdb file is correctly labeled.
right you are: # ls -lZ /etc/samba/secrets.tdb -rw------- root root root:object_r:samba_secrets_t /etc/samba/secrets.tdb === This is as far as I've gotten on my own. If there is a clear path to verifying what the package IS that is boogering up the system after the 'blind' update, feel free to suggest. BTW: at this point I still have yet to do the update to 5.3.
We believe it is addressed in the latest SELinux policy version. Please reopen if you can reproduce it.