Bug 706489

Summary:	SELinux is preventing /sbin/apcupsd from read access on the lnk_file /var/lock.
Product:	[Fedora] Fedora	Reporter:	Andre Robatino <robatino>
Component:	selinux-policy	Assignee:	Miroslav Grepl <mgrepl>
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	15	CC:	dominick.grift, dwalsh, mgrepl
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-05-22 18:35:56 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Andre Robatino 2011-05-20 18:14:55 UTC

Description of problem:

Attempting to start the apcupsd service results in

SELinux is preventing /sbin/apcupsd from read access on the lnk_file /var/lock.

*****  Plugin restorecon (94.8 confidence) suggests  *************************

If you want to fix the label. 
/var/lock default label should be var_lock_t.
Then you can run restorecon.
Do
# /sbin/restorecon -v /var/lock

*****  Plugin catchall_labels (5.21 confidence) suggests  ********************

If you want to allow apcupsd to have read access on the lock lnk_file
Then you need to change the label on /var/lock
Do
# semanage fcontext -a -t FILE_TYPE '/var/lock'
where FILE_TYPE is one of the following: var_run_t, var_lock_t, bin_t, cert_t, device_t, devlog_t, locale_t, etc_t, proc_t, apcupsd_t, abrt_t, lib_t, root_t, var_run_t, device_t, ld_so_t, proc_t, mta_exec_type, textrel_shlib_t, rpm_script_tmp_t, init_t. 
Then execute: 
restorecon -v '/var/lock'


*****  Plugin catchall (1.44 confidence) suggests  ***************************

If you believe that apcupsd should be allowed read access on the lock lnk_file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep apcupsd /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp


Version-Release number of selected component (if applicable):
selinux-policy-3.9.16-23.fc15.noarch
apcupsd-3.14.8-7.fc15

How reproducible:
always

Additional info:

Seen on 2 machines (one i686 and one x86_64) with a F15 Final (AKA RC3) clean DVD install with all available updates applied.

Comment 1 Dominick Grift 2011-05-20 18:25:52 UTC

Could you please enclose the whole report. You left out the informative part of it.

You can probably also retrieve it by running:

ausearch -m avc -ts today (provided that this event occurred today)

Also can you please enclose output of the following commands:

ps auxZ | grep apcupsd
matchpatchcon /var/lock
ls -dZ /var/lock
sesearch --allow -s apcupsd_t -t var_lock_t -c lnk_file -p read (this command requires that package setools-console is installed i believe)

Comment 2 Dominick Grift 2011-05-20 18:31:31 UTC

Thats "matchpathcon /var/lock". (i do that every time...)

Comment 3 Andre Robatino 2011-05-20 18:40:42 UTC

I included the entire output of "sealert -l 08254268-3d94-453a-9aa0-415a847a3d30". Just noticed that if I click on sealert's "Notify Admin", it composes an email with additional info, below are the entire contents. I'm not sure which if any of the info you requested is missing, let me know and I'll add that as well. In any case, this should be reproducible on any F15 machine with the apcupsd package installed, by running "service apcupsd start". (I know I should be using systemd commands but I couldn't figure out the name of the service to use.)

SELinux is preventing /sbin/apcupsd from read access on the lnk_file /var/lock.

*****  Plugin restorecon (94.8 confidence) suggests  *************************

If you want to fix the label. 
/var/lock default label should be var_lock_t.
Then you can run restorecon.
Do
# /sbin/restorecon -v /var/lock

*****  Plugin catchall_labels (5.21 confidence) suggests  ********************

If you want to allow apcupsd to have read access on the lock lnk_file
Then you need to change the label on /var/lock
Do
# semanage fcontext -a -t FILE_TYPE '/var/lock'
where FILE_TYPE is one of the following: var_run_t, var_lock_t, bin_t, cert_t, device_t, devlog_t, locale_t, etc_t, proc_t, apcupsd_t, abrt_t, lib_t, root_t, var_run_t, device_t, ld_so_t, proc_t, mta_exec_type, textrel_shlib_t, rpm_script_tmp_t, init_t. 
Then execute: 
restorecon -v '/var/lock'


*****  Plugin catchall (1.44 confidence) suggests  ***************************

If you believe that apcupsd should be allowed read access on the lock lnk_file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep apcupsd /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:apcupsd_t:s0
Target Context                system_u:object_r:var_t:s0
Target Objects                /var/lock [ lnk_file ]
Source                        apcupsd
Source Path                   /sbin/apcupsd
Port                          <Unknown>
Host                          compaq-pc
Source RPM Packages           apcupsd-3.14.8-7.fc15
Target RPM Packages           filesystem-2.4.40-1.fc15
Policy RPM                    selinux-policy-3.9.16-23.fc15
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     compaq-pc
Platform                      Linux compaq-pc 2.6.38.6-27.fc15.x86_64 #1 SMP Sun
                              May 15 17:23:28 UTC 2011 x86_64 x86_64
Alert Count                   6
First Seen                    Thu 19 May 2011 06:50:20 PM EDT
Last Seen                     Fri 20 May 2011 02:00:07 PM EDT
Local ID                      08254268-3d94-453a-9aa0-415a847a3d30

Raw Audit Messages
type=AVC msg=audit(1305914407.551:312): avc:  denied  { read } for  pid=5704 comm="apcupsd" name="lock" dev=dm-1 ino=4195866 scontext=system_u:system_r:apcupsd_t:s0 tcontext=system_u:object_r:var_t:s0 tclass=lnk_file


type=SYSCALL msg=audit(1305914407.551:312): arch=x86_64 syscall=open success=no exit=EACCES a0=23d81e0 a1=0 a2=23dc1e8 a3=64 items=0 ppid=1 pid=5704 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: apcupsd,apcupsd_t,var_t,lnk_file,read

audit2allow

#============= apcupsd_t ==============
allow apcupsd_t var_t:lnk_file read;

audit2allow -R

#============= apcupsd_t ==============
allow apcupsd_t var_t:lnk_file read;

Comment 4 Dominick Grift 2011-05-20 18:55:53 UTC

Thanks, the lnk_file at /var/lock is mislabeled. Running restorecon -R -v -F /var/lock should reset it to type var_lock_t.

I think that one of the updates changed /var/lock to be a symbolic link, that its context was not restored by whatever package changed it and i suspect this will not happen with the final version of Fedora but i may be wrong.

I thought the plan was to use bind mounts for this in F15 and use symbolic links in F16.

mgrepl or dwalsh may have more details about this issue

Comment 5 Andre Robatino 2011-05-20 19:13:20 UTC

Thanks, that appears to fix the sealert, but something else is also broken:

[root@compaq-pc ~]# systemctl start apcupsd.service
[root@compaq-pc ~]# systemctl status apcupsd.service
apcupsd.service - LSB: apcupsd daemon
	  Loaded: loaded (/etc/rc.d/init.d/apcupsd)
	  Active: active (exited) since Fri, 20 May 2011 15:05:44 -0400; 4min 56s ago
	 Process: 6935 ExecStop=/etc/rc.d/init.d/apcupsd stop (code=exited, status=0/SUCCESS)
	 Process: 6951 ExecStart=/etc/rc.d/init.d/apcupsd start (code=exited, status=0/SUCCESS)
	Main PID: 1344 (code=exited, status=1/FAILURE)
	  CGroup: name=systemd:/system/apcupsd.service
[root@compaq-pc ~]#

and the apcupsd process is not running. Should I change the component to apcupsd?

Comment 6 Andre Robatino 2011-05-20 19:16:33 UTC

I take it back, by stopping and restarting apcupsd.service again, I was able to reproduce what appears to be the identical sealert as before, so there still seems to be an selinux issue.

Comment 7 Dominick Grift 2011-05-20 19:19:37 UTC

Can you enclose the "new" sealert please? It should not be the same.

Comment 8 Andre Robatino 2011-05-20 19:25:21 UTC

OK, I ran

[root@compaq-pc ~]# restorecon -R -v -F /var/lock
[root@compaq-pc ~]# systemctl start apcupsd.service
[root@compaq-pc ~]# systemctl status apcupsd.service
apcupsd.service - LSB: apcupsd daemon
	  Loaded: loaded (/etc/rc.d/init.d/apcupsd)
	  Active: active (exited) since Fri, 20 May 2011 15:23:33 -0400; 15s ago
	 Process: 7379 ExecStop=/etc/rc.d/init.d/apcupsd stop (code=exited, status=0/SUCCESS)
	 Process: 7401 ExecStart=/etc/rc.d/init.d/apcupsd start (code=exited, status=0/SUCCESS)
	Main PID: 7175 (code=exited, status=1/FAILURE)
	  CGroup: name=systemd:/system/apcupsd.service
[root@compaq-pc ~]#

which caused the sealert

SELinux is preventing /sbin/apcupsd from read access on the lnk_file /var/lock.

*****  Plugin restorecon (94.8 confidence) suggests  *************************

If you want to fix the label. 
/var/lock default label should be var_lock_t.
Then you can run restorecon.
Do
# /sbin/restorecon -v /var/lock

*****  Plugin catchall_labels (5.21 confidence) suggests  ********************

If you want to allow apcupsd to have read access on the lock lnk_file
Then you need to change the label on /var/lock
Do
# semanage fcontext -a -t FILE_TYPE '/var/lock'
where FILE_TYPE is one of the following: var_run_t, var_lock_t, bin_t, cert_t, device_t, devlog_t, locale_t, etc_t, proc_t, apcupsd_t, abrt_t, lib_t, root_t, var_run_t, device_t, ld_so_t, proc_t, mta_exec_type, textrel_shlib_t, rpm_script_tmp_t, init_t. 
Then execute: 
restorecon -v '/var/lock'


*****  Plugin catchall (1.44 confidence) suggests  ***************************

If you believe that apcupsd should be allowed read access on the lock lnk_file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep apcupsd /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:apcupsd_t:s0
Target Context                system_u:object_r:var_t:s0
Target Objects                /var/lock [ lnk_file ]
Source                        apcupsd
Source Path                   /sbin/apcupsd
Port                          <Unknown>
Host                          compaq-pc
Source RPM Packages           apcupsd-3.14.8-7.fc15
Target RPM Packages           filesystem-2.4.40-1.fc15
Policy RPM                    selinux-policy-3.9.16-23.fc15
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     compaq-pc
Platform                      Linux compaq-pc 2.6.38.6-27.fc15.x86_64 #1 SMP Sun
                              May 15 17:23:28 UTC 2011 x86_64 x86_64
Alert Count                   3
First Seen                    Fri 20 May 2011 03:23:33 PM EDT
Last Seen                     Fri 20 May 2011 03:23:33 PM EDT
Local ID                      bcc760b1-6538-46f7-bbac-26df388b9578

Raw Audit Messages
type=AVC msg=audit(1305919413.836:365): avc:  denied  { read } for  pid=7409 comm="apcupsd" name="lock" dev=dm-1 ino=4195866 scontext=system_u:system_r:apcupsd_t:s0 tcontext=system_u:object_r:var_t:s0 tclass=lnk_file


type=SYSCALL msg=audit(1305919413.836:365): arch=x86_64 syscall=open success=no exit=EACCES a0=11981e0 a1=0 a2=119c1e8 a3=64 items=0 ppid=1 pid=7409 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: apcupsd,apcupsd_t,var_t,lnk_file,read

audit2allow

#============= apcupsd_t ==============
allow apcupsd_t var_t:lnk_file read;

audit2allow -R

#============= apcupsd_t ==============
allow apcupsd_t var_t:lnk_file read;

Comment 9 Dominick Grift 2011-05-20 19:28:28 UTC

Please run the following commands and enclose the output:

matchpathcon /var/lock
ls -alZ /var | grep lock
semanage fcontext -l | grep var_lock_t

Comment 10 Andre Robatino 2011-05-20 19:32:12 UTC

[root@compaq-pc ~]# matchpathcon /var/lock
/var/lock	system_u:object_r:var_lock_t:s0
[root@compaq-pc ~]# ls -alZ /var | grep lock
lrwxrwxrwx. root root system_u:object_r:var_t:s0       lock -> ../run/lock
[root@compaq-pc ~]# semanage fcontext -l | grep var_lock_t
/run/lock(/.*)?                                    all files          system_u:object_r:var_lock_t:s0 
/var/lock                                          symbolic link      system_u:object_r:var_lock_t:s0 
/var/lock(/.*)?                                    all files          system_u:object_r:var_lock_t:s0 
/var/lock/dirsrv(/.*)?                             all files          system_u:object_r:dirsrv_var_lock_t:s0 
/var/lock/subsys/denyhosts                         regular file       system_u:object_r:denyhosts_var_lock_t:s0 
[root@compaq-pc ~]#

Comment 11 Dominick Grift 2011-05-20 19:34:08 UTC

Can you also please run the following commands (again) and enclose the output:

restorecon -R -v -F /var/lock
ls -alZ /var | grep lock

Comment 12 Andre Robatino 2011-05-20 19:36:14 UTC

[root@compaq-pc ~]# restorecon -R -v -F /var/lock
[root@compaq-pc ~]# ls -alZ /var | grep lock
lrwxrwxrwx. root root system_u:object_r:var_t:s0       lock -> ../run/lock
[root@compaq-pc ~]#

Comment 13 Dominick Grift 2011-05-20 19:39:37 UTC

That is just strange indeed.

Please try the following (in this order) and paste output:

chcon -t var_lock_t /var/lock
ls -alZ /var | grep lock
restorecon -R -v -F /var/lock

Comment 14 Andre Robatino 2011-05-20 19:41:07 UTC

[root@compaq-pc ~]# chcon -t var_lock_t /var/lock
[root@compaq-pc ~]# ls -alZ /var | grep lock
lrwxrwxrwx. root root system_u:object_r:var_t:s0       lock -> ../run/lock
[root@compaq-pc ~]# restorecon -R -v -F /var/lock
[root@compaq-pc ~]#

Comment 15 Dominick Grift 2011-05-20 19:46:24 UTC

Ok i think i found the issue (hopefully)

Please try this instead:

chcon -v -t var_lock_t /var/lock
ls -alZ var | grep lock
restorecon -R -v -F /var/lock

Comment 16 Andre Robatino 2011-05-20 19:48:57 UTC

[root@compaq-pc ~]# chcon -v -t var_lock_t /var/lock
changing security context of `/var/lock'
[root@compaq-pc ~]# ls -alZ var | grep lock
ls: cannot access var: No such file or directory
[root@compaq-pc ~]# ls -alZ /var | grep lock
lrwxrwxrwx. root root system_u:object_r:var_t:s0       lock -> ../run/lock
[root@compaq-pc ~]# restorecon -R -v -F /var/lock
[root@compaq-pc ~]#

Comment 17 Dominick Grift 2011-05-20 19:53:06 UTC

Whoops sorry i meant:

chcon -h -t var_lock_t /var/lock
ls -alZ /var | lock
restorecon -R -v -F /var/lock

Comment 18 Andre Robatino 2011-05-20 19:55:14 UTC

[root@compaq-pc ~]# chcon -h -t var_lock_t /var/lock
[root@compaq-pc ~]# ls -alZ /var | lock
bash: lock: command not found...
[root@compaq-pc ~]# ^C
[root@compaq-pc ~]# ls -alZ /var | grep lock
lrwxrwxrwx. root root system_u:object_r:var_lock_t:s0  lock -> ../run/lock
[root@compaq-pc ~]# restorecon -R -v -F /var/lock
[root@compaq-pc ~]#

Comment 19 Andre Robatino 2011-05-20 19:57:08 UTC

I can also run apcupsd now:

[root@compaq-pc ~]# systemctl start apcupsd.service
[root@compaq-pc ~]# systemctl status apcupsd.service
apcupsd.service - LSB: apcupsd daemon
	  Loaded: loaded (/etc/rc.d/init.d/apcupsd)
	  Active: active (running) since Fri, 20 May 2011 15:55:50 -0400; 5s ago
	 Process: 7501 ExecStop=/etc/rc.d/init.d/apcupsd stop (code=exited, status=0/SUCCESS)
	 Process: 7928 ExecStart=/etc/rc.d/init.d/apcupsd start (code=exited, status=0/SUCCESS)
	Main PID: 7935 (apcupsd)
	  CGroup: name=systemd:/system/apcupsd.service
		  └ 7935 /sbin/apcupsd -f /etc/apcupsd/apcupsd.conf
[root@compaq-pc ~]# ps -A | grep apcupsd
 7935 ?        00:00:00 apcupsd
[root@compaq-pc ~]# apcaccess 
APC      : 001,035,0886
DATE     : 2011-05-20 15:55:51 -0400  
HOSTNAME : compaq-pc
VERSION  : 3.14.8 (16 January 2010) redhat
UPSNAME  : compaq-pc
CABLE    : USB Cable
MODEL    : Back-UPS ES 650 
UPSMODE  : Stand Alone
STARTTIME: 2011-05-20 15:55:50 -0400  
STATUS   : ONLINE 
LINEV    : 120.0 Volts
LOADPCT  :  23.0 Percent Load Capacity
BCHARGE  : 100.0 Percent
TIMELEFT :  22.6 Minutes
MBATTCHG : 5 Percent
MINTIMEL : 3 Minutes
MAXTIME  : 0 Seconds
SENSE    : Medium
LOTRANS  : 088.0 Volts
HITRANS  : 139.0 Volts
ALARMDEL : Always
BATTV    : 13.5 Volts
LASTXFER : No transfers since turnon
NUMXFERS : 0
TONBATT  : 0 seconds
CUMONBATT: 0 seconds
XOFFBATT : N/A
STATFLAG : 0x07000008 Status Flag
MANDATE  : 2009-11-17
SERIALNO : 4B0953290924  
BATTDATE : 2009-11-17
NOMINV   : 120 Volts
NOMBATTV :  12.0 Volts
FIRMWARE : 842.J3 .D USB FW:J3
APCMODEL : Back-UPS ES 650 
END APC  : 2011-05-20 15:56:36 -0400  
[root@compaq-pc ~]#

Comment 20 Dominick Grift 2011-05-20 20:02:34 UTC

can you give me the full path to the apcupsd lock file please? It is missing a file context specification in the policy

Comment 21 Dominick Grift 2011-05-20 20:04:06 UTC

It is just so weird/ not natural that restorecon -R -v -F does not restore the /var/lock symlink context.

Comment 22 Andre Robatino 2011-05-20 20:09:48 UTC

(In reply to comment #20)
> can you give me the full path to the apcupsd lock file please? It is missing a
> file context specification in the policy

Not sure if this is what you want:

[root@compaq-pc ~]# ls -l /var/lock
lrwxrwxrwx. 1 root root 11 May 19 04:29 /var/lock -> ../run/lock
[root@compaq-pc ~]# ls -l /run/lock
total 4
-rw-r--r--. 1 root root  11 May 20 15:55 LCK..
drwxrwxr-x. 2 root lock  40 May 19 18:50 lockdev
drwx------. 2 root root  40 May 19 18:50 lvm
drwxr-xr-x. 2 root root 520 May 20 15:55 subsys
[root@compaq-pc ~]#

Comment 23 Dominick Grift 2011-05-20 20:12:06 UTC

i mean the actual lock file

"var/lock/subsys/apcupsd" i suspect?

ls -alZ /var/lock/subsys/apcupsd

Comment 24 Andre Robatino 2011-05-20 20:19:14 UTC

Apparently so:

[root@compaq-pc ~]# ls -alZ /var/lock/subsys/apcupsd
-rw-r--r--. root root system_u:object_r:var_lock_t:s0  /var/lock/subsys/apcupsd
[root@compaq-pc ~]#

Comment 25 Dominick Grift 2011-05-20 20:38:05 UTC

Well this issue may or may not be resolved in Fedora yet. Lets see what the others have to say about restorecon not restoring the /var/lock symlink.

I did however add a file context specification for /var/lock/subsys/apcupsd to the rawhide policy.

http://git.fedorahosted.org/git/?p=selinux-policy.git;a=commitdiff;h=e9bba73123846b9a1e9355fb138a184a775be7e9

Comment 26 Andre Robatino 2011-05-20 20:45:09 UTC

As mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=706489#c0 , this was a clean install from the Fedora 15 Final (AKA RC3) DVD with all available updates applied, so it's not resolved until there's an update pushed to stable.

Comment 27 Miroslav Grepl 2011-05-22 18:35:56 UTC


*** This bug has been marked as a duplicate of bug 698223 ***