Summary: SELinux is preventing /sbin/apcupsd "sys_admin" access. Detailed Description: SELinux denied access requested by apcupsd. It is not expected that this access is required by apcupsd and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: You can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Please file a bug report. Additional Information: Source Context system_u:system_r:apcupsd_t:s0 Target Context system_u:system_r:apcupsd_t:s0 Target Objects None [ capability ] Source apcupsd Source Path /sbin/apcupsd Port <Unknown> Host (removed) Source RPM Packages apcupsd-3.14.7-2.fc12 Target RPM Packages Policy RPM selinux-policy-3.6.32-41.fc12 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall Host Name (removed) Platform Linux (removed) 2.6.31.5-127.fc12.x86_64 #1 SMP Sat Nov 7 21:11:14 EST 2009 x86_64 x86_64 Alert Count 3 First Seen Fri 13 Nov 2009 02:34:29 PM EST Last Seen Sat 14 Nov 2009 04:16:57 AM EST Local ID 76f1f8dc-ce3e-482d-a6e1-edfb50d735b6 Line Numbers Raw Audit Messages node=(removed) type=AVC msg=audit(1258190217.65:7): avc: denied { sys_admin } for pid=1537 comm="apcupsd" capability=21 scontext=system_u:system_r:apcupsd_t:s0 tcontext=system_u:system_r:apcupsd_t:s0 tclass=capability node=(removed) type=SYSCALL msg=audit(1258190217.65:7): arch=c000003e syscall=2 success=no exit=-16 a0=216a0a8 a1=902 a2=0 a3=88 items=0 ppid=1536 pid=1537 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="apcupsd" exe="/sbin/apcupsd" subj=system_u:system_r:apcupsd_t:s0 key=(null) Hash String generated from selinux-policy-3.6.32-41.fc12,catchall,apcupsd,apcupsd_t,apcupsd_t,capability,sys_admin audit2allow suggests: #============= apcupsd_t ============== allow apcupsd_t self:capability sys_admin;
Do you have any idea why apcupsd would need this access? It is a very powerful capability. And before I add it I want to make sure it really needs it. CAP_SYS_ADMIN Permit a range of system administration operations including: quotactl(2), mount(2), umount(2), swapon(2), swapoff(2), sethostname(2), setdomainname(2), IPC_SET and IPC_RMID operations on arbitrary System V IPC objects; perform operations on trusted and security Extended Attributes (see attr(5)); call lookup_dcookie(2); use ioprio_set(2) to assign IOPRIO_CLASS_RT and IOPRIO_CLASS_IDLE I/O scheduling classes; perform keyctl(2) KEYCTL_CHOWN and KEYCTL_SETPERM operations. allow forged UID when passing socket credentials; exceed /proc/sys/fs/file-max, the system-wide limit on the number of open files, in system calls that open files (e.g., accept(2), execve(2), open(2), pipe(2); without this capability these system calls will fail with the error ENFILE if this limit is encountered); employ CLONE_NEWNS flag with clone(2) and unshare(2); perform KEYCTL_CHOWN and KEYCTL_SETPERM keyctl(2) operations. These are the access provided by this capability. Andre did every thing seem to work correctly even with this denial?
Sometimes the apcupsd daemon isn't running, but after running "service apcupsd start" it seems to work normally.
(In reply to comment #1) > Do you have any idea why apcupsd would need this access? I don't know (yet). I've tried to reproduce this with my usb attached ups (apc back-up rs 500), but got no selinux message. Andre: Do you know what causes this selinux message? Starting/stopping daemon, running on batteries, power failure, ... ?
I was using the 3.6.32-46 testing versions of selinux-policy and selinux-policy-testing, just downgraded to the original 3.6.32-41, and at the moment can't reproduce the selinux message. However, when booting up, apcupsd didn't start, and I got the following in /var/log/messages: Nov 18 09:43:41 localhost apcupsd[1618]: apcupsd FATAL ERROR in dumbsetup.c at line 65#012Cannot open UPS port /dev/ttyUSB0: Device or resource busy Nov 18 09:43:41 localhost apcupsd[1618]: apcupsd error shutdown completed I was then able to start it with "service apcupsd start" and it now seems to be running normally. Stopping and restarting the service isn't generating the selinux message.
Here is the output in /var/log/messages corresponding to the selinux message in my original post. Nov 14 04:16:57 localhost apcupsd[1537]: apcupsd FATAL ERROR in dumbsetup.c at line 65#012Cannot open UPS port /dev/ttyUSB0: Device or resource busy Nov 14 04:16:57 localhost apcupsd[1537]: apcupsd error shutdown completed Nov 14 04:17:04 localhost setroubleshoot: SELinux is preventing /sbin/apcupsd "sys_admin" access. For complete SELinux messages. run sealert -l 76f1f8dc-ce3e-482d-a6e1-edfb50d735b6
I've tried to reproduce this, but still with no luck. Could you please test if apcupsd start during boot when you set selinux to permissive mode? (you can use system-config-selinux for changing selinux to permissive mode) Does apcupsd start if you turn boot startup off and try to start it manually? (chkconfig apcupsd off; reboot and service apcupsd start) Do you have virtualbox or vmware installed?
The only time apcupsd fails to start (and I get the selinux message) is during boot. Afterwards, I can always start it manually and it seems to run normally after that, with no selinux messages. I have virtualbox installed. I'm reluctant to try permissive mode due to vague memories of having trouble while reverting it. I've just updated to selinux-policy*-3.6.32-46.fc12.noarch and would prefer to watch this for a few days to see what happens.
You can make just apcupsd permissive # semanage permissive -a apcupsd_t
I haven't made the suggested semanage change yet, but have rebooted twice. apcupsd fails consistently to start, due to the Nov 24 17:26:49 localhost apcupsd[1563]: apcupsd FATAL ERROR in dumbsetup.c at l ine 65#012Cannot open UPS port /dev/ttyUSB0: Device or resource busy Nov 24 17:26:49 localhost apcupsd[1563]: apcupsd error shutdown completed message, but the selinux message doesn't always appear. I got it on the second reboot, though. Here is the entire output of /var/log/messages between the above message and the selinux message, maybe it will help. If not, I'll try the semanage change. Nov 24 17:26:49 localhost apcupsd[1563]: apcupsd FATAL ERROR in dumbsetup.c at line 65#012Cannot open UPS port /dev/ttyUSB0: Device or resource busy Nov 24 17:26:49 localhost apcupsd[1563]: apcupsd error shutdown completed Nov 24 17:26:49 localhost abrtd: Plugin Python (0.0.1) succesfully loaded Nov 24 17:26:49 localhost abrtd: Plugin Logger (0.0.1) succesfully loaded Nov 24 17:26:49 localhost abrtd: Plugin KerneloopsScanner (0.0.1) succesfully loaded Nov 24 17:26:49 localhost abrtd: Plugin KerneloopsReporter (0.0.1) succesfully loaded Nov 24 17:26:49 localhost abrtd: Plugin CCpp (0.0.1) succesfully loaded Nov 24 17:26:49 localhost abrtd: Plugin SQLite3 (0.0.2) succesfully loaded Nov 24 17:26:49 localhost abrtd: Plugin Bugzilla (0.0.4) succesfully loaded Nov 24 17:26:49 localhost abrtd: Plugin Kerneloops (0.0.2) succesfully loaded Nov 24 17:26:49 localhost abrtd: Registered plugin Bugzilla(Reporter) Nov 24 17:26:49 localhost abrtd: Registered plugin CCpp(Analyzer) Nov 24 17:26:49 localhost abrtd: Registered plugin Kerneloops(Analyzer) Nov 24 17:26:49 localhost abrtd: Registered plugin KerneloopsReporter(Reporter) Nov 24 17:26:49 localhost abrtd: Registered plugin KerneloopsScanner(Action) Nov 24 17:26:49 localhost abrtd: Registered plugin Logger(Reporter) Nov 24 17:26:49 localhost abrtd: Registered plugin Python(Analyzer) Nov 24 17:26:49 localhost abrtd: Registered plugin SQLite3(Database) Nov 24 17:26:49 localhost /usr/sbin/gpm[1618]: *** info [daemon/startup.c(136)]: Nov 24 17:26:49 localhost /usr/sbin/gpm[1618]: Started gpm successfully. Entered daemon mode. Nov 24 17:26:50 localhost kernel: Bridge firewalling registered Nov 24 17:26:50 localhost NetworkManager: <WARN> device_creator(): /sys/devices/virtual/net/virbr0: couldn't determine device driver; ignoring... Nov 24 17:26:50 localhost kernel: virbr0: starting userspace STP failed, starting kernel STP Nov 24 17:26:50 localhost avahi-daemon[1275]: Joining mDNS multicast group on interface virbr0.IPv4 with address 192.168.122.1. Nov 24 17:26:50 localhost avahi-daemon[1275]: New relevant interface virbr0.IPv4 for mDNS. Nov 24 17:26:50 localhost avahi-daemon[1275]: Registering new address record for 192.168.122.1 on virbr0.IPv4. Nov 24 17:26:50 localhost dnsmasq[1743]: started, version 2.48 cachesize 150 Nov 24 17:26:50 localhost dnsmasq[1743]: compile time options: IPv6 GNU-getopt DBus no-I18N DHCP TFTP Nov 24 17:26:50 localhost dnsmasq-dhcp[1743]: DHCP, IP range 192.168.122.2 -- 192.168.122.254, lease time 1h Nov 24 17:26:50 localhost dnsmasq[1743]: reading /etc/resolv.conf Nov 24 17:26:50 localhost dnsmasq[1743]: using nameserver 192.168.1.1#53 Nov 24 17:26:50 localhost dnsmasq[1743]: read /etc/hosts - 2 addresses Nov 24 17:26:50 localhost abrtd: Running... Nov 24 17:26:51 localhost dhclient: DHCPREQUEST on eth0 to 255.255.255.255 port 67 Nov 24 17:26:51 localhost dhclient: DHCPACK from 192.168.1.1 Nov 24 17:26:51 localhost NetworkManager: <info> DHCP: device eth0 state changed preinit -> reboot Nov 24 17:26:51 localhost NetworkManager: <info> Activation (eth0) Stage 4 of 5 (IP4 Configure Get) scheduled... Nov 24 17:26:51 localhost NetworkManager: <info> Activation (eth0) Stage 4 of 5 (IP4 Configure Get) started... Nov 24 17:26:51 localhost NetworkManager: <info> address 192.168.1.43 Nov 24 17:26:51 localhost NetworkManager: <info> prefix 24 (255.255.255.0) Nov 24 17:26:51 localhost NetworkManager: <info> gateway 192.168.1.1 Nov 24 17:26:51 localhost NetworkManager: <info> nameserver '192.168.1.1' Nov 24 17:26:51 localhost NetworkManager: nm_ip4_config_add_nameserver: assertion `nameserver != s' failed Nov 24 17:26:51 localhost NetworkManager: <info> nameserver '192.168.1.1' Nov 24 17:26:51 localhost NetworkManager: <info> domain name 'myhome.westell.com' Nov 24 17:26:51 localhost NetworkManager: <info> Activation (eth0) Stage 5 of 5 (IP Configure Commit) scheduled... Nov 24 17:26:51 localhost NetworkManager: <info> Activation (eth0) Stage 4 of 5 (IP4 Configure Get) complete. Nov 24 17:26:51 localhost NetworkManager: <info> Activation (eth0) Stage 5 of 5 (IP Configure Commit) started... Nov 24 17:26:51 localhost avahi-daemon[1275]: Joining mDNS multicast group on interface eth0.IPv4 with address 192.168.1.43. Nov 24 17:26:51 localhost avahi-daemon[1275]: New relevant interface eth0.IPv4 for mDNS. Nov 24 17:26:51 localhost avahi-daemon[1275]: Registering new address record for 192.168.1.43 on eth0.IPv4. Nov 24 17:26:51 localhost dhclient: bound to 192.168.1.43 -- renewal in 37341 seconds. Nov 24 17:26:51 localhost kernel: lo: Disabled Privacy Extensions Nov 24 17:26:51 localhost acpid: client connected from 1740[0:0] Nov 24 17:26:51 localhost acpid: 1 client rule loaded Nov 24 17:26:52 localhost NetworkManager: <info> (eth0): device state change: 7 -> 8 (reason 0) Nov 24 17:26:52 localhost NetworkManager: <info> Policy set 'System eth0' (eth0) as default for routing and DNS. Nov 24 17:26:52 localhost NetworkManager: <info> Activation (eth0) successful, device activated. Nov 24 17:26:52 localhost NetworkManager: <info> Activation (eth0) Stage 5 of 5 (IP Configure Commit) complete. Nov 24 17:26:52 localhost ntpd[1553]: Listening on interface #5 eth0, 192.168.1.43#123 Enabled Nov 24 17:26:52 localhost ntpd[1553]: Listening on interface #6 virbr0, 192.168.122.1#123 Enabled Nov 24 17:26:54 localhost rtkit-daemon[1880]: Sucessfully made thread 1878 of process 1878 (/usr/bin/pulseaudio) owned by '42' high priority at nice level -11. Nov 24 17:26:54 localhost rtkit-daemon[1880]: Sucessfully made thread 1884 of process 1878 (/usr/bin/pulseaudio) owned by '42' RT at priority 5. Nov 24 17:26:54 localhost rtkit-daemon[1880]: Sucessfully made thread 1885 of process 1878 (/usr/bin/pulseaudio) owned by '42' RT at priority 5. Nov 24 17:26:54 localhost kernel: ALSA sound/usb/usbaudio.c:1295: 4:3:1: cannot get freq at ep 0x84 Nov 24 17:26:54 localhost kernel: ALSA sound/usb/usbaudio.c:1295: 4:3:1: cannot get freq at ep 0x84 Nov 24 17:26:54 localhost pulseaudio[1878]: alsa-mixer.c: Your kernel driver is broken: it reports a volume range from 18.00 dB to 18.00 dB which makes no sense. Nov 24 17:26:54 localhost pulseaudio[1878]: alsa-mixer.c: Your kernel driver is broken: it reports a volume range from 18.00 dB to 18.00 dB which makes no sense. Nov 24 17:26:54 localhost pulseaudio[1878]: alsa-mixer.c: Your kernel driver is broken: it reports a volume range from 18.00 dB to 18.00 dB which makes no sense. Nov 24 17:26:54 localhost pulseaudio[1878]: alsa-mixer.c: Your kernel driver is broken: it reports a volume range from 18.00 dB to 18.00 dB which makes no sense. Nov 24 17:26:54 localhost pulseaudio[1878]: alsa-mixer.c: Your kernel driver is broken: it reports a volume range from 18.00 dB to 18.00 dB which makes no sense. Nov 24 17:26:54 localhost pulseaudio[1878]: alsa-mixer.c: Your kernel driver is broken: it reports a volume range from 18.00 dB to 18.00 dB which makes no sense. Nov 24 17:26:54 localhost pulseaudio[1878]: alsa-mixer.c: Your kernel driver is broken: it reports a volume range from 18.00 dB to 18.00 dB which makes no sense. Nov 24 17:26:54 localhost rtkit-daemon[1880]: Sucessfully made thread 1886 of process 1878 (/usr/bin/pulseaudio) owned by '42' RT at priority 5. Nov 24 17:26:54 localhost rtkit-daemon[1880]: Sucessfully made thread 1887 of process 1878 (/usr/bin/pulseaudio) owned by '42' RT at priority 5. Nov 24 17:26:55 localhost rtkit-daemon[1880]: Sucessfully made thread 1890 of process 1878 (/usr/bin/pulseaudio) owned by '42' RT at priority 5. Nov 24 17:26:55 localhost rtkit-daemon[1880]: Sucessfully made thread 1892 of process 1878 (/usr/bin/pulseaudio) owned by '42' RT at priority 5. Nov 24 17:26:56 localhost setroubleshoot: SELinux is preventing /sbin/apcupsd "sys_admin" access. For complete SELinux messages. run sealert -l 76f1f8dc-ce3e-482d-a6e1-edfb50d735b6 Nov 24 17:26:59 localhost modem-manager: (ttyUSB0) closing serial device...
What does ausearch -m avc -i Show
Created attachment 373574 [details] output of "ausearch -m avc -i"
So it is getting an sys_admin on the open call. eric any ideas?
(In reply to comment #7) > The only time apcupsd fails to start (and I get the selinux message) is during > boot. Afterwards, I can always start it manually and it seems to run normally > after that, with no selinux messages. yes, so please try to boot up with apcupsd disabled and start it manually later when system boot is completed, as I've asked you in comment #6 > I have virtualbox installed. virtualbox is third party package and sometimes makes some troubles because it's configuration (for example udev rules - changing owners and permissions on devices) are not following fedora ways. What's output of ll /dev/ttyUSB0 > I'm > reluctant to try permissive mode due to vague memories of having trouble while > reverting it. I think your memories are about disabling and enabling selinux completely which needs complete filesystem relabel when turned on again. Or what issues did you have when changing selinux from enforcing to permissive (and back)?
If apcupsd is disabled, I can start it up manually with no trouble after booting up. [andre@compaq-pc ~]$ ll /dev/ttyUSB0 crw-rw----. 1 root dialout 188, 0 2009-11-25 03:30 /dev/ttyUSB0 [andre@compaq-pc ~]$ I don't remember the details of what happened regarding disabling selinux, but I'd rather not risk doing it again. However, after enabling apcupsd again and running "semanage permissive -a apcupsd_t" from comment #8, apcupsd starts automatically during bootup with no trouble.
Are you still getting the sys_admin avc in permissive mode?
No - checking the latest output of "ausearch -m avc -i", there are no additional entries corresponding to either of my experiments in comment #14.
See also bug #544121 where I have similar problems with the ups service failing to start at boot time when using nut, but able to start it manually after that.
AFAICT, there is no remaining selinux issue, but problem with apcupsd starting during boot is persisting. Can you confirm this Andre? If it's correct I'll close this bug as duplicate of #544121, because problem would be the same.
That's correct, apcupsd still won't start during boot.
*** This bug has been marked as a duplicate of bug 544121 ***