Bug 673384
Summary: | SELinux is preventing /usr/sbin/sendmail.sendmail from 'read' accesses on the directory /home/dummy. | |||
---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Eric Blake <eblake> | |
Component: | sendmail | Assignee: | Jaroslav Škarvada <jskarvad> | |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | |
Severity: | medium | Docs Contact: | ||
Priority: | medium | |||
Version: | rawhide | CC: | dan.mashal, dwalsh, eblake, jskarvad, macleod2486, metherid, mgrepl, mlichvar, nicolas.mailhot, reis.lucia, shivasrinath.reddy | |
Target Milestone: | --- | Keywords: | Reopened | |
Target Release: | --- | |||
Hardware: | i386 | |||
OS: | Linux | |||
Whiteboard: | setroubleshoot_trace_hash:e1d2259087e0993cdbdc2edbeed2514d5d37187593777ec8858ec2a7cfe187cf | |||
Fixed In Version: | Doc Type: | Bug Fix | ||
Doc Text: | Story Points: | --- | ||
Clone Of: | ||||
: | 919801 919802 (view as bug list) | Environment: | ||
Last Closed: | 2013-03-19 05:12:20 UTC | Type: | --- | |
Regression: | --- | Mount Type: | --- | |
Documentation: | --- | CRM: | ||
Verified Versions: | Category: | --- | ||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
Cloudforms Team: | --- | Target Upstream Version: | ||
Embargoed: | ||||
Bug Depends On: | ||||
Bug Blocks: | 919801, 919802 |
Description
Eric Blake
2011-01-27 23:16:37 UTC
Looks like something what we want to dontaudit. How did you get this? (In reply to comment #1) > Looks like something what we want to dontaudit. > > How did you get this? I first noticed it after incrementally upgrading to the latest rawhide; although I'm not sure if I could reliably reproduce it. If it helps, I now have: sendmail-8.14.4-19.fc15.i686 installed on 2011-01-15; the previous version was 8.14.4-17.fc15.i686. Any reason sendmail would be listing the contents of /home/dummy? Reproducible on F18 with: selinux-policy-3.11.1-43.fc18.noarch sendmail-8.14.5-15.fc18.x86_64 (In reply to comment #3) > Any reason sendmail would be listing the contents of /home/dummy? Same question, moving to sendmail developers. Hmm, strange. I cannot reproduce, nor find it in the code. Wouldn't be possible, there is such include in your aliases? I have not reproduced this issue in ages - perhaps Martin can give more details since he has a more recent experience with the message. Is it a bug or a policy problem? Package: (null) Architecture: x86_64 OS Release: Fedora release 19 (Rawhide) (In reply to comment #7) > Is it a bug or a policy problem? > > Package: (null) > Architecture: x86_64 > OS Release: Fedora release 19 (Rawhide) Do you have reproducer? Otherwise I am going to close this. It maybe caused by custom aliases. drat, I don't know why sealert decided to duplicate this, my avc is type=SYSCALL msg=audit(1354556349.393:17052): arch=c000003e syscall=59 success=yes exit=0 a0=9f9a90 a1=9f8f00 a2=9f7e50 a3=0 items=0 ppid=9247 pid=9248 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=2 tty=pts0 comm="newaliases" exe="/usr/sbin/sendmail.postfix" subj=unconfined_u:system_r:system_mail_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1354556349.393:17052): avc: denied { read } for pid=9248 comm="newaliases" path="/home/nim" dev="dm-1" ino=12 scontext=unconfined_u:system_r:system_mail_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_dir_t:s0 tclass=dir type=AVC msg=audit(1354556349.393:17052): avc: denied { read } for pid=9248 comm="newaliases" path="/home/nim" dev="dm-1" ino=12 scontext=unconfined_u:system_r:system_mail_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_dir_t:s0 tclass=dir so obviously a postfix not sendmail avc (occurred just after a yum update, but the only mail-related thing in the yum transaction was a dovecot upgrade) Could you provide output of: # postconf alias_database And content of the file from its output? (e.g. /etc/aliases) Are you able to reproduce by running: # newaliases ? I retried on my systems but I wasn't able to reproduce. ime->Thu Dec 6 06:29:29 2012 type=PATH msg=audit(1354793369.935:5376): item=1 name=(null) inode=1843751 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ld_so_t:s0 type=PATH msg=audit(1354793369.935:5376): item=0 name="/usr/bin/newaliases" inode=1851334 dev=fd:00 mode=0102755 ouid=0 ogid=51 rdev=00:00 obj=system_u:object_r:sendmail_exec_t:s0 type=CWD msg=audit(1354793369.935:5376): cwd="/" type=EXECVE msg=audit(1354793369.935:5376): argc=1 a0="/usr/bin/newaliases" type=SYSCALL msg=audit(1354793369.935:5376): arch=c000003e syscall=59 success=yes exit=0 a0=2698590 a1=2697ae0 a2=2697050 a3=7fff83572040 items=2 ppid=4272 pid=4273 auid=3267 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=51 sgid=51 fsgid=51 ses=3 tty=pts0 comm="newaliases" exe="/usr/sbin/sendmail.sendmail" subj=staff_u:system_r:system_mail_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1354793369.935:5376): avc: denied { read } for pid=4273 comm="newaliases" path="/home/dwalsh" dev="dm-2" ino=131073 scontext=staff_u:system_r:system_mail_t:s0-s0:c0.c1023 tcontext=staff_u:object_r:user_home_dir_t:s0 tclass=dir I got this on my F18 box. Both of these are leaks. Where a process has a open read descriptor on the homedir. Fixed in selinux-policy-3.11.1-61.fc18.noarch Added dontaudit. (In reply to comment #14) > Both of these are leaks. Where a process has a open read descriptor on the > homedir. Thanks for the info and workaround in the policy. I will dig into this in my spare time. Is there any reproducer? Just running newaliases? I wasn't able to reproduce. No I believe this is caused by newalias being run either by the system or as part of a yum transaction. Upgrade from clean installed F18 to F19 Rawhide. Package: (null) Architecture: x86_64 OS Release: Fedora release 19 (Rawhide) Description of problem: yum update on rawhide Additional info: hashmarkername: setroubleshoot kernel: 3.9.0-0.rc0.git14.1.fc19.x86_64 type: libreport This is where this happens: Updating : setup-2.8.66-1.fc19.noarch 57/422 warning: /etc/shadow created as /etc/shadow.rpmnew I see there is a new selinux policy. I will try again with it. Seems to work OK now. Will re-open if needed. *** Bug 928978 has been marked as a duplicate of this bug. *** |