Bug 237744 - SELinux denial of apcupsd apccontrol
SELinux denial of apcupsd apccontrol
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: apcupsd (Show other bugs)
6
All Linux
medium Severity medium
: ---
: ---
Assigned To: Orion Poplawski
Fedora Extras Quality Assurance
bzcl34nup
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-04-25 02:23 EDT by Anthony Messina
Modified: 2008-05-06 15:32 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-06 15:32:06 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
AVC messages from apcupsd on power failure (21.10 KB, text/plain)
2007-06-15 04:28 EDT, Simon
no flags Details
AVC messages from apcupsd, 2.6.4-17 (10.83 KB, text/plain)
2007-06-19 07:43 EDT, Simon
no flags Details
AVC messages from apcupsd, 2.6.4-17, Enforcing (7.43 KB, text/plain)
2007-06-19 09:46 EDT, Simon
no flags Details

  None (edit)
Description Anthony Messina 2007-04-25 02:23:10 EDT
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 09:33:08 EDT
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 11:58:23 EDT
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 12:22:09 EDT
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 12:23:54 EDT
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 10:02:50 EDT
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 10:54:54 EDT
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-08 22:47:05 EDT
This issue has resurfaced in Fedora 7 with selinux-policy-targeted-2.6.4-13.fc7

Comment 8 Daniel Walsh 2007-06-11 09:57:23 EDT
Fixed in selinux-policy-2.6.4-14
Comment 9 Simon 2007-06-13 04:08:09 EDT
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 09:55:09 EDT
If you put the machine in permissive mode do you see any other avc messages?
Comment 11 Simon 2007-06-13 10:00:46 EDT
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 08:57:42 EDT
Fixed in selinux-policy-2.6.4-15
Comment 13 Simon 2007-06-14 11:02:53 EDT
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 11:50:42 EDT
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 04:28:54 EDT
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 08:45:49 EDT
Ok added rules to allow mail, wall and shutdown.

selinux-policy-2.6.4-16
Comment 17 Simon 2007-06-18 04:41:42 EDT
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 07:43:57 EDT
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 09:30:27 EDT
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 09:46:09 EDT
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 03:06:09 EDT
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 15:32:05 EDT
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.

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