Bug 237744
Summary: | SELinux denial of apcupsd apccontrol | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Anthony Messina <amessina> | ||||||||
Component: | apcupsd | Assignee: | Orion Poplawski <orion> | ||||||||
Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
Severity: | medium | Docs Contact: | |||||||||
Priority: | medium | ||||||||||
Version: | 6 | CC: | 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
Anthony Messina
2007-04-25 06:23:10 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. 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. 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. 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. I have changed the context to work in selinux-policy-2.4.6-68 for fc6, but this should be fixed in rawhide. 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. This issue has resurfaced in Fedora 7 with selinux-policy-targeted-2.6.4-13.fc7 Fixed in selinux-policy-2.6.4-14 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 If you put the machine in permissive mode do you see any other avc messages? 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" Fixed in selinux-policy-2.6.4-15 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) 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? 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.
Ok added rules to allow mail, wall and shutdown. selinux-policy-2.6.4-16 Where can I get 2.6.4-16 from to test? I've been using http://koji.fedoraproject.org/koji/packageinfo?packageID=32 before. 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.
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 Created attachment 157364 [details]
AVC messages from apcupsd, 2.6.4-17, Enforcing
Last log was permissive; here's enforcing...
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 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. |