Bug 247162 - SELinux prevents apcupsd from sending email alerts
SELinux prevents apcupsd from sending email alerts
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
7
All Linux
low Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Fedora Extras Quality Assurance
:
: 249993 357871 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-07-05 14:28 EDT by Anthony Messina
Modified: 2008-01-30 14:19 EST (History)
5 users (show)

See Also:
Fixed In Version: Current
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-01-30 14:19:01 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Anthony Messina 2007-07-05 14:28:17 EDT
Description of problem:
On Fedora 7, in enforcing mode, SELinux prevents the apcupsd daemon from sending
wall broadcasts or email alerts as follows:

Version-Release number of selected component (if applicable):
selinux-policy-targeted-2.6.4-23.fc7
apcupsd-3.14.1-2.fc7

How reproducible:
Every time.

Steps to Reproduce:
1. Execute a self test on the UPS
2. (In my case, it's telling me my batteries need changing)
3. See no wall broadcasts and email messages are blank
  
Actual results:
SELinux is preventing /bin/mail (apcupsd_t) "setgid" to  (apcupsd_t).
SELinux is preventing /usr/sbin/sendmail.postfix (system_mail_t) "read write" to
/tmp/RsnlVB7N (deleted) (apcupsd_t).
SELinux is preventing /usr/bin/wall (apcupsd_t) "dac_override" to  (apcupsd_t).

Expected results:
SELinux should allow this type of access so admins can find out whether or not
their batteries need replacing :) or get any other notifications.

Additional info:
avc: denied { setgid } for comm="mail" egid=0 euid=0 exe="/bin/mail" exit=0
fsgid=0 fsuid=0 gid=0 items=0 pid=14493 scontext=user_u:system_r:apcupsd_t:s0
sgid=0 subj=user_u:system_r:apcupsd_t:s0 suid=0 tclass=capability
tcontext=user_u:system_r:apcupsd_t:s0 tty=(none) uid=0

avc: denied { read, write } for comm="sendmail" dev=sockfs egid=0 euid=0
exe="/usr/sbin/sendmail.postfix" exit=0 fsgid=0 fsuid=0 gid=0 items=0
name="[309946]" path=2F746D702F52736E6C5642374E202864656C6574656429 pid=14495
scontext=user_u:system_r:system_mail_t:s0 sgid=0
subj=user_u:system_r:system_mail_t:s0 suid=0 tclass=tcp_socket
tcontext=user_u:system_r:apcupsd_t:s0 tty=(none) uid=0

avc: denied { dac_override } for comm="wall" egid=5 euid=0 exe="/usr/bin/wall"
exit=-13 fsgid=5 fsuid=0 gid=0 items=0 pid=14498
scontext=user_u:system_r:apcupsd_t:s0 sgid=5 subj=user_u:system_r:apcupsd_t:s0
suid=0 tclass=capability tcontext=user_u:system_r:apcupsd_t:s0 tty=(none) uid=0
Comment 1 Daniel Walsh 2007-07-06 10:44:01 EDT
Fixed in selinux-policy-2.6.4-27
Added dac_override and setgid to policy.

avc: denied { read, write } for comm="sendmail" dev=sockfs egid=0 euid=0
exe="/usr/sbin/sendmail.postfix" exit=0 fsgid=0 fsuid=0 gid=0 items=0
name="[309946]" path=2F746D702F52736E6C5642374E202864656C6574656429 pid=14495
scontext=user_u:system_r:system_mail_t:s0 sgid=0
subj=user_u:system_r:system_mail_t:s0 suid=0 tclass=tcp_socket
tcontext=user_u:system_r:apcupsd_t:s0 tty=(none) uid=0

is caused by a leaked file descriptor.  All open file descriptors should be
closed on exec of applications.

fcntl(fd, F_SETFD, F_CLOEXEC)
Comment 2 Orion Poplawski 2007-08-01 18:58:52 EDT
With selinux-policy-2.6.4-30.fc7 I get broadcast messages but mails with empty
bodies. 

Here's what I see:

type=AVC msg=audit(1186003168.817:2876): avc:  denied  { read } for  pid=4004
comm="apcaccess" name="resolv.conf" dev=dm-0 ino=120846
scontext=root:system_r:apcupsd_t:s0 tcontext=system_u:object_r:net_conf_t:s0
tclass=file
type=AVC msg=audit(1186003168.827:2877): avc:  denied  { create } for  pid=4004
comm="apcaccess" scontext=root:system_r:apcupsd_t:s0
tcontext=root:system_r:apcupsd_t:s0 tclass=udp_socket

^ resolver library?

type=AVC msg=audit(1186003177.143:3170): avc:  denied  { read } for  pid=4006
comm="sendmail" name="RsNzuY70" dev=tmpfs ino=17180
scontext=root:system_r:system_mail_t:s0 tcontext=root:object_r:apcupsd_tmp_t:s0
tclass=file

^ Maybe sendmail trying to read the message to be sent?

type=AVC msg=audit(1186003177.143:3170): avc:  denied  { read append } for 
pid=4006 comm="sendmail" name="apcupsd.events" dev=dm-3 ino=124974
scontext=root:system_r:system_mail_t:s0 tcontext=root:object_r:apcupsd_log_t:s0
tclass=file
type=AVC msg=audit(1186003177.143:3170): avc:  denied  { read write } for 
pid=4006 comm="sendmail" name="hiddev0" dev=tmpfs ino=3798
scontext=root:system_r:system_mail_t:s0
tcontext=system_u:object_r:usb_device_t:s0 tclass=chr_file
type=AVC msg=audit(1186003177.143:3170): avc:  denied  { read write } for 
pid=4006 comm="sendmail" name="" dev=sockfs ino=17042
scontext=root:system_r:system_mail_t:s0 tcontext=root:system_r:apcupsd_t:s0
tclass=tcp_socket

^ These look like open descriptors.  Should be fixed in apcupsd-3.14.1-3.
Comment 3 Fedora Update System 2007-08-02 22:39:49 EDT
apcupsd-3.14.1-3.fc7 has been pushed to the Fedora 7 testing repository.  If problems still persist, please make note of it in this bug report.
Comment 4 Orion Poplawski 2007-10-11 11:35:22 EDT
I still get blank emails because sendmail cannot read the tmp message file that
apcupsd writes out:

Oct  5 11:25:39 saga kernel: audit(1191605139.416:10): avc:  denied  { read }
for  pid=28312 comm="sendmail" name="RsejgQId" dev=tmpfs ino=1409259
scontext=system_u:system_r:system_mail_t:s0
tcontext=system_u:object_r:apcupsd_tmp_t:s0 tclass=file
Comment 5 Daniel Walsh 2007-10-18 09:28:54 EDT
Fixed in selinux-policy-2.6.4-49
Comment 6 Orion Poplawski 2007-10-19 10:19:11 EDT
*** Bug 249993 has been marked as a duplicate of this bug. ***
Comment 7 Orion Poplawski 2007-10-30 09:55:55 EDT
*** Bug 357871 has been marked as a duplicate of this bug. ***
Comment 8 Daniel Walsh 2008-01-30 14:19:01 EST
Bulk closing all bugs in Fedora updates in the modified state.  If you bug is
not fixed, please reopen.

Note You need to log in before you can comment on or make changes to this bug.