Bug 741436 - SELinux is preventing /usr/libexec/totem-plugin-viewer from 'execute' accesses on the file /home/james.cape/orcexec.t54O9i (deleted).
Summary: SELinux is preventing /usr/libexec/totem-plugin-viewer from 'execute' accesse...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 16
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:31cbf1783bef91957933dd4bfcd...
: 741437 741438 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-09-26 19:55 UTC by James Cape
Modified: 2011-11-23 17:46 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-11-23 17:46:58 UTC


Attachments (Terms of Use)

Description James Cape 2011-09-26 19:55:56 UTC
abrt version: 2.0.5
executable:     /usr/bin/python
hashmarkername: setroubleshoot
kernel:         3.1.0-0.rc6.git0.3.fc16.x86_64
reason:         SELinux is preventing /usr/libexec/totem-plugin-viewer from 'execute' accesses on the file /home/james.cape/orcexec.t54O9i (deleted).
time:           Mon Sep 26 14:55:48 2011

description:
:SELinux is preventing /usr/libexec/totem-plugin-viewer from 'execute' accesses on the file /home/james.cape/orcexec.t54O9i (deleted).
:
:*****  Plugin restorecon (99.5 confidence) suggests  *************************
:
:If you want to fix the label. 
:/home/james.cape/orcexec.t54O9i (deleted) default label should be user_home_t.
:Then you can run restorecon.
:Do
:# /sbin/restorecon -v /home/james.cape/orcexec.t54O9i (deleted)
:
:*****  Plugin catchall (1.49 confidence) suggests  ***************************
:
:If you believe that totem-plugin-viewer should be allowed execute access on the orcexec.t54O9i (deleted) 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 totem-plugin-vi /var/log/audit/audit.log | audit2allow -M mypol
:# semodule -i mypol.pp
:
:Additional Information:
:Source Context                unconfined_u:unconfined_r:mozilla_plugin_t:s0-s0:c
:                              0.c1023
:Target Context                unconfined_u:object_r:user_home_dir_t:s0
:Target Objects                /home/james.cape/orcexec.t54O9i (deleted) [ file ]
:Source                        totem-plugin-vi
:Source Path                   /usr/libexec/totem-plugin-viewer
:Port                          <Unknown>
:Host                          (removed)
:Source RPM Packages           totem-mozplugin-3.1.4-1.fc16
:Target RPM Packages           
:Policy RPM                    selinux-policy-3.10.0-32.fc16
:Selinux Enabled               True
:Policy Type                   targeted
:Enforcing Mode                Permissive
:Host Name                     (removed)
:Platform                      Linux orwell.ignore-your.tv
:                              3.1.0-0.rc6.git0.3.fc16.x86_64 #1 SMP Fri Sep 16
:                              12:26:22 UTC 2011 x86_64 x86_64
:Alert Count                   1
:First Seen                    Mon 26 Sep 2011 02:55:33 PM CDT
:Last Seen                     Mon 26 Sep 2011 02:55:33 PM CDT
:Local ID                      c5dd194a-affc-46aa-9e52-7d1920297dc0
:
:Raw Audit Messages
:type=AVC msg=audit(1317066933.380:395): avc:  denied  { execute } for  pid=18266 comm="totem-plugin-vi" path=2F686F6D652F6A616D65732E636170652F6F7263657865632E7435344F3969202864656C6574656429 dev=dm-2 ino=314211 scontext=unconfined_u:unconfined_r:mozilla_plugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_dir_t:s0 tclass=file
:
:
:type=SYSCALL msg=audit(1317066933.380:395): arch=x86_64 syscall=mmap success=yes exit=140737086255104 a0=0 a1=10000 a2=5 a3=1 items=0 ppid=1 pid=18266 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=7 comm=totem-plugin-vi exe=/usr/libexec/totem-plugin-viewer subj=unconfined_u:unconfined_r:mozilla_plugin_t:s0-s0:c0.c1023 key=(null)
:
:Hash: totem-plugin-vi,mozilla_plugin_t,user_home_dir_t,file,execute
:
:audit2allow
:
:#============= mozilla_plugin_t ==============
:allow mozilla_plugin_t user_home_dir_t:file execute;
:
:audit2allow -R
:
:#============= mozilla_plugin_t ==============
:allow mozilla_plugin_t user_home_dir_t:file execute;
:

Comment 1 Daniel Walsh 2011-09-27 13:21:24 UTC
This looks like you have a mislabeled homedir.

restorecon -R -v ~/

Do you have mozplugger installed?

If yes you probably need to turn off the confinement.

setsebool -P unconfined_mozilla_plugin_transition 0

Comment 2 Daniel Walsh 2011-09-27 13:22:01 UTC
*** Bug 741438 has been marked as a duplicate of this bug. ***

Comment 3 James Cape 2011-09-27 13:26:21 UTC
I don't have mozplugger installed, no.

Comment 4 Dominick Grift 2011-09-27 22:02:02 UTC
fabian: why is liborc still creating these orcexec.* files in user home directories rather than /tmp?

Comment 5 Miroslav Grepl 2011-09-27 23:07:05 UTC
This is a good question.

Comment 6 Dominick Grift 2011-09-29 09:17:01 UTC
I guess we are going to have to support this.

<grift> fabiand any new on why liborc still puts orcexec.* file in user home dirs instead of /tmp?
<grift> those orcexec files should go to tmp
<fabiand> grift: that can be because tmpfs is noexec 
<fabiand> and afaik the logic tries /tmp but falls back to $home if it can not be executed there ..
<fabiand> it's more dramatic that they sometimes don't get removed ..

<grift> fabiand i see, makes sense
<fabiand> grift: there is an update out for 14/15 which fixes some problems, i'll push it to 16 when the beta is out ..

Comment 7 Fabian Deutsch 2011-10-01 19:36:03 UTC
Maybe those are based on the same problem:
https://bugzilla.redhat.com/show_bug.cgi?id=723001
https://bugzilla.redhat.com/show_bug.cgi?id=741437

In a default setup /tmp is noexec, so orc is falling back to XDG_RUNIME_DIR and HOME. 
What place would be a viable solution for you selinux guys/grils?

Comment 8 Dominick Grift 2011-10-01 20:08:57 UTC
This is a bug in liborc and were waiting for a fix in F16.

Any reports where name="orcexec.*" we can likely chalk up to this bug.

Comment 9 Dominick Grift 2011-10-01 20:28:02 UTC
http://code.entropywave.com/git?p=orc.git;a=commit;h=fbc554f450e37380104e2730d8685caf37abe24c

Let me explain the issues involved here.

different apps use the liborc. Usually a default user will not notice this issue.
except when a confine domain uses liborc

for example gnash in the mozilla plugin domain. gnash calls liborc which makes gnash create a file in $home in the current case the file has a random suffix. so the file gets created with for example mozilla_home_t type. Restorecond -u picks it up as mislabelled and resets the context (usually to user_home_t) this causes that the confined domain can no longer write to it or delete it. So we end up with orcexec files in the home dir that arent deleted.

We cannot add a file context for this because different apps (domains) call liborc , for example totem-thumbnailer. So we cant tell selinux what the label should be. should it be mozilla_home_t or thumb_home_t or, or,?

the named file trans could maybe help here but the random suffix breaks it. We could for example say if a domain creates a file with name orcexec.1 then type transition to orc_home_t if another domain creates a file with orcexec.2 then type transition to orc_home_t as well. As long as its not a random suffix and it uses a reasonable range [0-10]?

Then we CAN add a file context spec HOME_DIR/orcexec.* -- gen_context(system_u:object_r:orc_home_t,s0)

We need to find a way to make this work regardless of whether orc fixes the /tmp and home ordering. Because if for some reason tmp or tmpfs cannot be used (noexec?) then it will try to fallback to home.

Comment 10 Dominick Grift 2011-10-03 14:24:19 UTC
Issue where orc creates files in ~ by default rather than /tmp is fixed in orc-0.4.16-1.fc16.x86_64.rpm.

Comment 11 Daniel Walsh 2011-10-03 15:20:30 UTC
Could we change the default so it creates the file under .config or .local

Comment 12 Fabian Deutsch 2011-10-03 15:36:17 UTC
AFAIK this can easily be patched and maybe upstream is also interested if there are valid arguments in using those locations.

Comment 13 Dominick Grift 2011-10-03 15:40:47 UTC
(In reply to comment #11)
> Could we change the default so it creates the file under .config or .local

why do you want that? I do not see how that changes anything.

Comment 14 Daniel Walsh 2011-10-03 15:54:44 UTC
Confined user domains have rules about labels on files created in ~/ and more significance can be placed on these files in these directories.  If we create a directory in .config/orc/  And create the orc content there, we can allow all of the confined apps created orc_home_t.  And then we could use a named_file_trans rule to make sure .config/orc gets created with the correct context.

Comment 15 Dominick Grift 2011-10-03 16:07:00 UTC
I see you point but you are not explaining it right i believe.

Let me try:

1. we cannot use a named file transition because of the random suffix of the orcexec.* files.

2. we can use the named file transition *if* orc creates a dir (~/.cache/orc) and then create these orcexec.* files in there.

because we *can* define a rule for the orc dir but not for the orcexec.* files:

# create orc dir in ~/.cache with a named file transition
manage_dirs_pattern($1, orc_cache_home_t, orc_cache_home_t)
filetrans_pattern($1, cache_home_t, orc_cache_home_t, dir, "orc")

# allow orc to manage/exec orcexec.* files in directories with type orc_cache_home_t
manage_files_pattern($1, orc_cache_home_t, orc_cache_home_t)
exec_files_pattern($1, orc_cache_home_t, orc_cache_home_t)

Comment 16 Dominick Grift 2011-10-03 16:08:37 UTC
And then:

HOME_DIR/\.cache/orc(/.*)? gen_context(system_u:object_r:orc_cache_home_t,s0)

Comment 17 Daniel Walsh 2011-10-03 16:14:15 UTC
That is the idea.  

.cache is a better directory for this also.

Comment 18 Dominick Grift 2011-10-03 16:18:44 UTC
i will pitch this idea at #orc

Comment 19 Fabian Deutsch 2011-10-16 12:59:16 UTC
I've just build orc with a patch, putting all temporary files into a subdir, could you try it and give some feedback?
https://koji.fedoraproject.org/koji/taskinfo?taskID=3434537

Comment 20 Daniel Walsh 2011-11-23 14:47:46 UTC
So is this fixed in the current release?

Comment 21 Daniel Walsh 2011-11-23 14:50:38 UTC
*** Bug 741437 has been marked as a duplicate of this bug. ***

Comment 22 Fabian Deutsch 2011-11-23 16:50:25 UTC
(In reply to comment #20)
> So is this fixed in the current release?

From my pov yes. I tried to grab Dominick Grift a cuople of times, so he could check if the selinux rules are in place and the whole think works (he requested the change in orc).


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