Red Hat Bugzilla – Bug 858739
SELinux is preventing /usr/sbin/smbd from 'getattr' accesses on the file /usr/sbin/ssmtp.
Last modified: 2012-10-02 06:06:28 EDT
libreport version: 2.0.10 executable: /usr/bin/python2.7 hashmarkername: setroubleshoot kernel: 3.4.9-2.fc16.x86_64 time: Wed 19 Sep 2012 10:39:14 AM EDT description: :SELinux is preventing /usr/sbin/smbd from 'getattr' accesses on the file /usr/sbin/ssmtp. : :***** Plugin samba_share (98.5 confidence) suggests ************************ : :If you want to allow smbd to have getattr access on the ssmtp file :Then you need to change the label on '/usr/sbin/ssmtp' :Do :# semanage fcontext -a -t samba_share_t '/usr/sbin/ssmtp' :# restorecon -v '/usr/sbin/ssmtp' : :***** Plugin catchall (2.42 confidence) suggests *************************** : :If you believe that smbd should be allowed getattr access on the ssmtp 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: :# grep smbd /var/log/audit/audit.log | audit2allow -M mypol :# semodule -i mypol.pp : :Additional Information: :Source Context system_u:system_r:smbd_t:s0 :Target Context system_u:object_r:sendmail_exec_t:s0 :Target Objects /usr/sbin/ssmtp [ file ] :Source smbd :Source Path /usr/sbin/smbd :Port <Unknown> :Host (removed) :Source RPM Packages samba-3.6.6-88.fc16.x86_64 :Target RPM Packages ssmtp-2.61-16.fc15.x86_64 :Policy RPM selinux-policy-3.10.0-91.fc16.noarch :Selinux Enabled True :Policy Type targeted :Enforcing Mode Enforcing :Host Name (removed) :Platform Linux (removed) 3.4.9-2.fc16.x86_64 #1 SMP Thu Aug 23 : 17:51:29 UTC 2012 x86_64 x86_64 :Alert Count 2 :First Seen Wed 19 Sep 2012 10:36:10 AM EDT :Last Seen Wed 19 Sep 2012 10:36:10 AM EDT :Local ID cacdcf5d-6db1-4036-a9cd-d6747236a0d6 : :Raw Audit Messages :type=AVC msg=audit(1348065370.650:5616): avc: denied { getattr } for pid=17328 comm="smbd" path="/usr/sbin/ssmtp" dev="dm-0" ino=9624 scontext=system_u:system_r:smbd_t:s0 tcontext=system_u:object_r:sendmail_exec_t:s0 tclass=file : : :type=SYSCALL msg=audit(1348065370.650:5616): arch=x86_64 syscall=stat success=no exit=EACCES a0=7f03a579b880 a1=7fff94aa9420 a2=7fff94aa9420 a3=74 items=0 ppid=1625 pid=17328 auid=4294967295 uid=0 gid=0 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=4294967295 comm=smbd exe=/usr/sbin/smbd subj=system_u:system_r:smbd_t:s0 key=(null) : :Hash: smbd,smbd_t,sendmail_exec_t,file,getattr : :audit2allow : :#============= smbd_t ============== :#!!!! This avc can be allowed using one of the these booleans: :# samba_export_all_ro, samba_export_all_rw : :allow smbd_t sendmail_exec_t:file getattr; : :audit2allow -R : :#============= smbd_t ============== :#!!!! This avc can be allowed using one of the these booleans: :# samba_export_all_ro, samba_export_all_rw : :allow smbd_t sendmail_exec_t:file getattr; :
What are you exactly doing? Are you sharing this files using samba or smbd wants to execute ssmtp?
No, as far as I can tell, there should be no reason at all for samba to need access to /usr/sbin/smbd. Here is my smb.conf file: http://pastebin.com/6m1UHdcm As you can see, /usr/sbin is not shared. Note also, that pretty much at the same time, I got two other alerts: Bug 858738 Bug 858740 None of these directories are shared by samba and I can see no reason for it to access them, except that it might be a bug in smbd.
(In reply to comment #2) > No, as far as I can tell, there should be no reason at all for samba to need > access to /usr/sbin/smbd. That should of course be /usr/sbin/ssmtp.
Does SAMBA use /usr/sbin/ssmtp?
No, it doesn't.
Could you reopen if this happens again. Thank you.
I got this again today, along with the other two reported above (pretty much exactly the same -- smbd access to /usr/bin/wodim, /usr/sbin/ssmtp, and then /usr/share/man. I think it happens when I plug in my android phone to my USB port and have VMWare running (VMWare is running a Windows virtual machine that uses samba to connect to the host). I have no idea why plugging in a USB device would cause the virtual machine to somehow get smbd to do these accesses however. Seems very strange to me.
This sounds more like a virus or trojan. Without useful logfiles and network captures we can't do anything.
Raman, you can dontaudit them # grep smbd /var/log/audit/audit.log | audit2allow -D -M mypol # semodule -i mypol.pp