Bug 736924

Summary: SELinux is preventing /sbin/load_policy from 'read' accesses on the file policyvers.
Product: [Fedora] Fedora Reporter: Renich Bon Ciric <renich>
Component: selinux-policyAssignee: Miroslav Grepl <mgrepl>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 15CC: dominick.grift, dwalsh, mgrepl
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard: setroubleshoot_trace_hash:18c646a4f3b2f89c1a0df8b46f76dd09b03e3d4efd4e62c71f2d65781e4bb2fd
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-09-09 07:54:52 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
selinux errors provoked by boxgrinder-build none

Description Renich Bon Ciric 2011-09-09 05:49:32 UTC
SELinux is preventing /sbin/load_policy from 'read' accesses on the file policyvers.

*****  Plugin file (36.8 confidence) suggests  *******************************

If you think this is caused by a badly mislabeled machine.
Then you need to fully relabel.
Do
touch /.autorelabel; reboot

*****  Plugin file (36.8 confidence) suggests  *******************************

If you think this is caused by a badly mislabeled machine.
Then you need to fully relabel.
Do
touch /.autorelabel; reboot

*****  Plugin catchall_labels (23.2 confidence) suggests  ********************

If you want to allow load_policy to have read access on the policyvers file
Then you need to change the label on policyvers
Do
# semanage fcontext -a -t FILE_TYPE 'policyvers'
where FILE_TYPE is one of the following: user_cron_spool_t, textrel_shlib_t, rpm_script_tmp_t, etc_runtime_t, ld_so_cache_t, selinux_config_t, semanage_store_t, locale_t, load_policy_t, abrt_var_run_t, etc_t, proc_t, sysctl_crypto_t, security_t, abrt_t, lib_t, load_policy_exec_t, afs_cache_t, abrt_helper_exec_t, boolean_type, ld_so_t. 
Then execute: 
restorecon -v 'policyvers'


*****  Plugin catchall (5.04 confidence) suggests  ***************************

If you believe that load_policy should be allowed read access on the policyvers 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 load_policy /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                unconfined_u:unconfined_r:load_policy_t:s0-s0:c0.c
                              1023
Target Context                unconfined_u:object_r:file_t:s0
Target Objects                policyvers [ file ]
Source                        load_policy
Source Path                   /sbin/load_policy
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           policycoreutils-2.0.86-7.fc15
Target RPM Packages           
Policy RPM                    selinux-policy-3.9.16-38.fc15
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Permissive
Host Name                     (removed)
Platform                      Linux (removed) 2.6.40.4-5.fc15.x86_64 #1 SMP
                              Tue Aug 30 14:38:32 UTC 2011 x86_64 x86_64
Alert Count                   1
First Seen                    Fri 09 Sep 2011 12:47:45 AM CDT
Last Seen                     Fri 09 Sep 2011 12:47:45 AM CDT
Local ID                      659a9890-3770-45e0-bcd2-45394fc8ef46

Raw Audit Messages
type=AVC msg=audit(1315547265.120:2423): avc:  denied  { read } for  pid=13366 comm="load_policy" name="policyvers" dev=dm-3 ino=27 scontext=unconfined_u:unconfined_r:load_policy_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:file_t:s0 tclass=file


type=AVC msg=audit(1315547265.120:2423): avc:  denied  { open } for  pid=13366 comm="load_policy" name="policyvers" dev=dm-3 ino=27 scontext=unconfined_u:unconfined_r:load_policy_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:file_t:s0 tclass=file


type=SYSCALL msg=audit(1315547265.120:2423): arch=x86_64 syscall=open success=yes exit=ESRCH a0=7fffa621e270 a1=0 a2=7fffa621e283 a3=7fffa621dff0 items=0 ppid=13356 pid=13366 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm=load_policy exe=/sbin/load_policy subj=unconfined_u:unconfined_r:load_policy_t:s0-s0:c0.c1023 key=(null)

Hash: load_policy,load_policy_t,file_t,file,read

audit2allow

#============= load_policy_t ==============
allow load_policy_t file_t:file { read open };

audit2allow -R

#============= load_policy_t ==============
allow load_policy_t file_t:file { read open };

Comment 1 Miroslav Grepl 2011-09-09 07:49:47 UTC
The setroubleshoot tells you what to do

*****  Plugin file (36.8 confidence) suggests  *******************************

If you think this is caused by a badly mislabeled machine.
Then you need to fully relabel.
Do


touch /.autorelabel; reboot

Comment 2 Miroslav Grepl 2011-09-09 07:50:11 UTC
*** Bug 736925 has been marked as a duplicate of this bug. ***

Comment 3 Miroslav Grepl 2011-09-09 07:50:35 UTC
*** Bug 736926 has been marked as a duplicate of this bug. ***

Comment 4 Miroslav Grepl 2011-09-09 07:50:51 UTC
*** Bug 736927 has been marked as a duplicate of this bug. ***

Comment 5 Miroslav Grepl 2011-09-09 07:51:08 UTC
*** Bug 736928 has been marked as a duplicate of this bug. ***

Comment 6 Miroslav Grepl 2011-09-09 07:51:28 UTC
*** Bug 736922 has been marked as a duplicate of this bug. ***

Comment 7 Miroslav Grepl 2011-09-09 07:51:49 UTC
*** Bug 736921 has been marked as a duplicate of this bug. ***

Comment 8 Daniel Walsh 2011-09-09 12:06:46 UTC
Renich did you read the alert at all?  It told you that it was not a bug and how to fix.

Comment 9 Renich Bon Ciric 2011-09-09 22:03:42 UTC
(In reply to comment #8)
> Renich did you read the alert at all?  It told you that it was not a bug and
> how to fix.

Hehee... yes, I did! ;)

My thought was that, maybe, you needed all the reports in order to figure out what happened.

I was trying to use boxgrinder-build; which is packaged as rubygem-boxgrinder-build.

I think they never considered to talk to you. There are tons of alerts when one tries to build an image.

Sorry if I made a mess. Just wanted you to have a clear picture of what boxgrinder tries to do.

Comment 10 Renich Bon Ciric 2011-09-09 22:04:28 UTC
(In reply to comment #1)
> The setroubleshoot tells you what to do
> 
> *****  Plugin file (36.8 confidence) suggests  *******************************
> 
> If you think this is caused by a badly mislabeled machine.
> Then you need to fully relabel.
> Do
> 
> 
> touch /.autorelabel; reboot

Man, I do a fixfiles onboot all the time. I know I am not "badly mislabeled".

Comment 11 Miroslav Grepl 2011-09-12 11:20:58 UTC
So you are telling me you did 

touch /.autorelabel; reboot

and you are still getting this issue?


If yes, could you try to execute

# yum reinstall selinux-policy-targeted

and make sure nothing blows up on reinstall.

Comment 12 Daniel Walsh 2011-09-12 19:11:05 UTC
ls -lZ /sys/fs/selinux/policyvers 
-r--r--r--. root root system_u:object_r:security_t:s0  /sys/fs/selinux/policyvers

Comment 13 Renich Bon Ciric 2011-09-12 22:32:38 UTC
(In reply to comment #12)
> ls -lZ /sys/fs/selinux/policyvers 
> -r--r--r--. root root system_u:object_r:security_t:s0 
> /sys/fs/selinux/policyvers

# ls -lZ /sys/fs/selinux/policyvers 
ls: cannot access /sys/fs/selinux/policyvers: No such file or directory

(In reply to comment #11)
> So you are telling me you did 
> 
> touch /.autorelabel; reboot
> 
> and you are still getting this issue?

Yes; as I told you, I relabel often. Once every 2 weeks or so.

> 
> If yes, could you try to execute
> 
> # yum reinstall selinux-policy-targeted
> 
> and make sure nothing blows up on reinstall.

I'm doing so just now. I'll tell you what happened

Comment 14 Daniel Walsh 2011-09-13 17:35:51 UTC
I guess this is on F15.  ls -lZ /selinux/policyvers

Comment 15 Renich Bon Ciric 2011-09-13 18:36:57 UTC
(In reply to comment #14)
> I guess this is on F15.  ls -lZ /selinux/policyvers

You guessed right! ;=)
# ls -lZ /selinux/policyvers
-r--r--r--. root root system_u:object_r:security_t:s0  /selinux/policyvers

Comment 16 Renich Bon Ciric 2011-09-13 18:37:36 UTC
(In reply to comment #13)
> > 
> > If yes, could you try to execute
> > 
> > # yum reinstall selinux-policy-targeted
> > 
> > and make sure nothing blows up on reinstall.
> 
> I'm doing so just now. I'll tell you what happened

BTW, everything went cool; nothing blew up ;)

Comment 17 Daniel Walsh 2011-09-13 21:01:59 UTC
Ok Everything looks fine.  See if you can get it to happen again.

Comment 18 Renich Bon Ciric 2011-09-14 08:38:36 UTC
Created attachment 523082 [details]
selinux errors provoked by boxgrinder-build

An image is worth a thousand SELinux blocks ;)

This happens when I run a simple: boxgrinder-build -f centos.appl