Bug 237744

Summary: SELinux denial of apcupsd apccontrol
Product: [Fedora] Fedora Reporter: Anthony Messina <amessina>
Component: apcupsdAssignee: Orion Poplawski <orion>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 6CC: dwalsh, fedora.jrg01, goodyca48, number.cruncher, triage
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: bzcl34nup
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-05-06 19:32:06 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:
Attachments:
Description Flags
AVC messages from apcupsd on power failure
none
AVC messages from apcupsd, 2.6.4-17
none
AVC messages from apcupsd, 2.6.4-17, Enforcing none

Description Anthony Messina 2007-04-25 06:23:10 UTC
Description of problem:
The executable files under /etc/apcupsd are labeled with type etc_t.  When the
apcupsd daemon tries to execute one of them it receives a denial similar to the
following and when enforcing, the process is denied.

Version-Release number of selected component (if applicable):
selinux-policy-2.4.6-57.fc6

How reproducible:
Every time.

Steps to Reproduce:
1. Simulate a power failure or wait for a self test of a ups
  
Actual results:
avc: denied { execute } for comm="apcupsd" dev=sda2 egid=0 euid=0
exe="/usr/sbin/apcupsd" exit=-13 fsgid=0 fsuid=0 gid=0 items=0 name="apccontrol"
pid=29626 scontext=system_u:system_r:apcupsd_t:s0 sgid=0
subj=system_u:system_r:apcupsd_t:s0 suid=0 tclass=file
tcontext=system_u:object_r:etc_t:s0 tty=(none) uid=0

Expected results:
No denial in log; no denial of daemon.

The files should be allowed to be executed.

Additional info:
This system is running in enforcing mode.

Comment 1 Daniel Walsh 2007-04-25 13:33:08 UTC
Why are these files in the /etc directory?  Are these exes configuration files?

We can change the policy so the file context is bin_t and you can do this with
the chcon command, to make this work

chcon -t bin_t /etc/apcupsd/apccontrol

But it would be better if these were in a bin directory or /usr/lib.

Comment 2 Anthony Messina 2007-04-25 15:58:23 UTC
As an end user, I can't answer why they are located in /etc/apcupsd, but they
always have been with the redhat/fedora version of apcupsd.

Comment 3 Orion Poplawski 2007-04-25 16:22:09 UTC
Dan -

Here are the files:

-rwxr-xr-x  root root system_u:object_r:etc_t          apccontrol
-rw-r--r--  root root system_u:object_r:etc_t          apcupsd.conf
-rwxr-xr-x  root root system_u:object_r:etc_t          changeme
-rwxr-xr-x  root root system_u:object_r:etc_t          commfailure
-rwxr-xr-x  root root system_u:object_r:etc_t          commok
-rw-r--r--  root root system_u:object_r:etc_t          hosts.conf
-rwxr-xr-x  root root system_u:object_r:etc_t          masterconnect
-rwxr-xr-x  root root system_u:object_r:etc_t          mastertimeout
-rw-r--r--  root root system_u:object_r:etc_t          multimon.conf
-rwxr-xr-x  root root system_u:object_r:etc_t          offbattery
-rwxr-xr-x  root root system_u:object_r:etc_t          onbattery

The executables are shell scripts.   The idea is that these files can be customized to perform different 
actions than the default if desired.  Conceivably one could even create entirely new scripts that are 
called by apccontrol.


Comment 4 Daniel Walsh 2007-04-25 16:23:54 UTC
How about we create a new directory /etc/apcupsd/scripts and place the scripts
there.  This would make it easier to maintain the context on these and if a user
did add a new script it would be labeled correctly.

Comment 5 Daniel Walsh 2007-05-03 14:02:50 UTC
I have changed the context to work in selinux-policy-2.4.6-68 for fc6, but this
should be fixed in rawhide.

Comment 6 Orion Poplawski 2007-05-03 14:54:54 UTC
Thanks.  I'm working on a patch to move the scripts to /etc/apcupsd/scripts but
it's going to take some work.  I'm already doing a non-standard install making a
/etc/apcupsd directory.


Comment 7 Anthony Messina 2007-06-09 02:47:05 UTC
This issue has resurfaced in Fedora 7 with selinux-policy-targeted-2.6.4-13.fc7



Comment 8 Daniel Walsh 2007-06-11 13:57:23 UTC
Fixed in selinux-policy-2.6.4-14

Comment 9 Simon 2007-06-13 08:08:09 UTC
I still get problems, apcupsd_t denied execute for bin_t:

type=AVC msg=audit(1181721618.281:702): avc:  denied  { execute } for  pid=13185
comm="apcupsd" name="apccontrol" dev=dm-0 ino=1870258
scontext=root:system_r:apcupsd_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file
type=SYSCALL msg=audit(1181721618.281:702): arch=40000003 syscall=11 success=no
exit=-13 a0=bfe8f1c0 a1=bfe8f1a8 a2=bfe8f484 a3=9fa6018 items=0 ppid=12669
pid=13185 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
tty=(none) comm="apcupsd" exe="/usr/sbin/apcupsd"
subj=root:system_r:apcupsd_t:s0 key=(null)

apcupsd-3.14.1-1.fc7, selinux-policy-2.6.4-14.fc7

Comment 10 Daniel Walsh 2007-06-13 13:55:09 UTC
If you put the machine in permissive mode do you see any other avc messages?

Comment 11 Simon 2007-06-13 14:00:46 UTC
um, yes! :

type=AVC msg=audit(1181743138.318:336): avc:  denied  { execute } for  pid=13107
comm="apcupsd" name="apccontrol" dev=dm-0 ino=1870258
scontext=system_u:system_r:apcupsd_t:s0 tcontext=system_u:object_r:bin_t:s0
tclass=file
type=AVC msg=audit(1181743138.318:336): avc:  denied  { execute_no_trans } for 
pid=13107 comm="apcupsd" name="apccontrol" dev=dm-0 ino=1870258
scontext=system_u:system_r:apcupsd_t:s0 tcontext=system_u:object_r:bin_t:s0
tclass=file
type=AVC msg=audit(1181743138.318:336): avc:  denied  { read } for  pid=13107
comm="apcupsd" name="apccontrol" dev=dm-0 ino=1870258
scontext=system_u:system_r:apcupsd_t:s0 tcontext=system_u:object_r:bin_t:s0
tclass=file
type=AVC msg=audit(1181743138.318:336): avc:  denied  { search } for  pid=13107
comm="apcupsd" name="bin" dev=dm-0 ino=1671169
scontext=system_u:system_r:apcupsd_t:s0 tcontext=system_u:object_r:bin_t:s0
tclass=dir
type=AVC msg=audit(1181743138.318:336): avc:  denied  { read } for  pid=13107
comm="apcupsd" name="sh" dev=dm-0 ino=1672781
scontext=system_u:system_r:apcupsd_t:s0 tcontext=system_u:object_r:bin_t:s0
tclass=lnk_file
type=AVC msg=audit(1181743138.318:336): avc:  denied  { execute } for  pid=13107
comm="apcupsd" name="bash" dev=dm-0 ino=1674993
scontext=system_u:system_r:apcupsd_t:s0
tcontext=system_u:object_r:shell_exec_t:s0 tclass=file
type=AVC msg=audit(1181743138.318:336): avc:  denied  { read } for  pid=13107
comm="apcupsd" name="bash" dev=dm-0 ino=1674993
scontext=system_u:system_r:apcupsd_t:s0
tcontext=system_u:object_r:shell_exec_t:s0 tclass=file
type=SYSCALL msg=audit(1181743138.318:336): arch=40000003 syscall=11 success=yes
exit=0 a0=bff1b3c0 a1=bff1b3a8 a2=bff1b684 a3=84ca018 items=0 ppid=1955
pid=13107 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 tty=(none) comm="apccontrol" exe="/bin/bash"
subj=system_u:system_r:apcupsd_t:s0 key=(null)
type=AVC_PATH msg=audit(1181743138.318:336):  path="/bin/bash"
type=AVC_PATH msg=audit(1181743138.318:336):  path="/etc/apcupsd/apccontrol"
type=AVC_PATH msg=audit(1181743138.318:336):  path="/etc/apcupsd/apccontrol"
type=AVC msg=audit(1181743138.318:337): avc:  denied  { read } for  pid=13107
comm="apccontrol" name="meminfo" dev=proc ino=-268435454
scontext=system_u:system_r:apcupsd_t:s0 tcontext=system_u:object_r:proc_t:s0
tclass=file
type=SYSCALL msg=audit(1181743138.318:337): arch=40000003 syscall=5 success=yes
exit=5 a0=4997b4a2 a1=0 a2=1b6 a3=854aa60 items=0 ppid=1955 pid=13107
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
tty=(none) comm="apccontrol" exe="/bin/bash" subj=system_u:system_r:apcupsd_t:s0
key=(null)
type=AVC msg=audit(1181743138.318:338): avc:  denied  { getattr } for  pid=13107
comm="apccontrol" name="meminfo" dev=proc ino=-268435454
scontext=system_u:system_r:apcupsd_t:s0 tcontext=system_u:object_r:proc_t:s0
tclass=file
type=SYSCALL msg=audit(1181743138.318:338): arch=40000003 syscall=197
success=yes exit=0 a0=5 a1=bff2a0ec a2=499a5ff4 a3=854aa60 items=0 ppid=1955
pid=13107 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 tty=(none) comm="apccontrol" exe="/bin/bash"
subj=system_u:system_r:apcupsd_t:s0 key=(null)
type=AVC_PATH msg=audit(1181743138.318:338):  path="/proc/meminfo"
type=AVC msg=audit(1181743138.318:339): avc:  denied  { ioctl } for  pid=13107
comm="apccontrol" name="apccontrol" dev=dm-0 ino=1870258
scontext=system_u:system_r:apcupsd_t:s0 tcontext=system_u:object_r:bin_t:s0
tclass=file
type=SYSCALL msg=audit(1181743138.318:339): arch=40000003 syscall=54 success=no
exit=-25 a0=5 a1=5401 a2=bff2c188 a3=bff2c1c8 items=0 ppid=1955 pid=13107
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
tty=(none) comm="apccontrol" exe="/bin/bash" subj=system_u:system_r:apcupsd_t:s0
key=(null)
type=AVC_PATH msg=audit(1181743138.318:339):  path="/etc/apcupsd/apccontrol"
type=AVC msg=audit(1181743138.318:340): avc:  denied  { getattr } for  pid=13107
comm="apccontrol" name="apccontrol" dev=dm-0 ino=1870258
scontext=system_u:system_r:apcupsd_t:s0 tcontext=system_u:object_r:bin_t:s0
tclass=file
type=SYSCALL msg=audit(1181743138.318:340): arch=40000003 syscall=197
success=yes exit=0 a0=ff a1=bff2c26c a2=499a5ff4 a3=1 items=0 ppid=1955
pid=13107 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 tty=(none) comm="apccontrol" exe="/bin/bash"
subj=system_u:system_r:apcupsd_t:s0 key=(null)
type=AVC_PATH msg=audit(1181743138.318:340):  path="/etc/apcupsd/apccontrol"
type=AVC msg=audit(1181743138.318:341): avc:  denied  { read write } for 
pid=13110 comm="wall" name="utmp" dev=dm-2 ino=8060933
scontext=system_u:system_r:apcupsd_t:s0
tcontext=system_u:object_r:initrc_var_run_t:s0 tclass=file
type=SYSCALL msg=audit(1181743138.318:341): arch=40000003 syscall=5 success=yes
exit=5 a0=4997c08b a1=8002 a2=0 a3=4997c091 items=0 ppid=13109 pid=13110
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=5 sgid=5 fsgid=5
tty=(none) comm="wall" exe="/usr/bin/wall" subj=system_u:system_r:apcupsd_t:s0
key=(null)
type=AVC msg=audit(1181743138.318:342): avc:  denied  { lock } for  pid=13110
comm="wall" name="utmp" dev=dm-2 ino=8060933
scontext=system_u:system_r:apcupsd_t:s0
tcontext=system_u:object_r:initrc_var_run_t:s0 tclass=file
type=SYSCALL msg=audit(1181743138.318:342): arch=40000003 syscall=221
success=yes exit=0 a0=5 a1=7 a2=bfc8f790 a3=0 items=0 ppid=13109 pid=13110
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=5 sgid=5 fsgid=5
tty=(none) comm="wall" exe="/usr/bin/wall" subj=system_u:system_r:apcupsd_t:s0
key=(null)
type=AVC_PATH msg=audit(1181743138.318:342):  path="/var/run/utmp"

Comment 12 Daniel Walsh 2007-06-14 12:57:42 UTC
Fixed in selinux-policy-2.6.4-15

Comment 13 Simon 2007-06-14 15:02:53 UTC
Still not working for me. Problems running /usr/bin/wall.
Here's the 2.6.4-15 output (permissive):

type=AVC msg=audit(1181833188.410:165): avc:  denied  { read write } for 
pid=3673 comm="wall" name="utmp" dev=dm-2 ino=8060933
scontext=system_u:system_r:apcupsd_t:s0
tcontext=system_u:object_r:initrc_var_run_t:s0 tclass=file
type=SYSCALL msg=audit(1181833188.410:165): arch=40000003 syscall=5 success=yes
exit=5 a0=4997c08b a1=8002 a2=0 a3=4997c091 items=0 ppid=3672 pid=3673
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=5 sgid=5 fsgid=5
tty=(none) comm="wall" exe="/usr/bin/wall" subj=system_u:system_r:apcupsd_t:s0
key=(null)

Comment 14 Daniel Walsh 2007-06-14 15:50:42 UTC
These messages are dontaudited in enforcing mode,   We don't care about them in
permissive mode.  Does the app work in enforcing mode without generating avc
messages?

Comment 15 Simon 2007-06-15 08:28:54 UTC
Created attachment 157072 [details]
AVC messages from apcupsd on power failure

No, it's far more verbose when enforcing, but still boils down to executing
commands such as "wall" or "mail". Are there going to be any problems running
/sbin/shutdown (when battery spent)? Ultimately that's all I really care about:
a clean shutdown.

See attached.

Comment 16 Daniel Walsh 2007-06-15 12:45:49 UTC
Ok added rules to allow mail, wall and shutdown.

selinux-policy-2.6.4-16

Comment 17 Simon 2007-06-18 08:41:42 UTC
Where can I get 2.6.4-16 from to test? I've been using
http://koji.fedoraproject.org/koji/packageinfo?packageID=32 before.

Comment 18 Simon 2007-06-19 11:43:57 UTC
Created attachment 157362 [details]
AVC messages from apcupsd, 2.6.4-17

wall is now working, but apcupsd still generates a lot of noise and mail
problems with 2.6.4-17.

Comment 19 Daniel Walsh 2007-06-19 13:30:27 UTC
Ok was that log from permissive mode?  IE I want to know that you captured all
of the avc messages.  

This should be fixed in 2.6.4-18

Comment 20 Simon 2007-06-19 13:46:09 UTC
Created attachment 157364 [details]
AVC messages from apcupsd, 2.6.4-17, Enforcing

Last log was permissive; here's enforcing...

Comment 21 Bug Zapper 2008-04-04 07:06:09 UTC
Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.

If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.
http://fedoraproject.org/wiki/LifeCycle/EOL

If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
the change.

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we are following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers

Comment 22 Bug Zapper 2008-05-06 19:32:05 UTC
This bug is open for a Fedora version that is no longer maintained and
will not be fixed by Fedora. Therefore we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen thus bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.