Bug 739618 - Chrome/Chromium cannot start due to text relocations
Summary: Chrome/Chromium cannot start due to text relocations
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: selinux-policy
Version: 6.1
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Miroslav Grepl
QA Contact: Milos Malik
Depends On: 730449
Blocks: 741430
TreeView+ depends on / blocked
Reported: 2011-09-19 16:05 UTC by Jiri Koten
Modified: 2012-10-10 09:10 UTC (History)
10 users (show)

Fixed In Version: selinux-policy-3.7.19-115.el6
Doc Type: Bug Fix
Doc Text:
Clone Of: 730449
: 741430 (view as bug list)
Last Closed: 2011-12-06 10:19:09 UTC

Attachments (Terms of Use)
AVC output (3.21 KB, text/plain)
2011-09-19 16:09 UTC, Jiri Koten
no flags Details

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:1511 normal SHIPPED_LIVE selinux-policy bug fix and enhancement update 2011-12-06 00:39:17 UTC

Description Jiri Koten 2011-09-19 16:05:34 UTC
+++ This bug was initially created as a clone of Bug #730449 +++

Upstream bug:

/opt/google/chrome/chrome: error while loading shared libraries: cannot restore segment prot after reloc: Permission denied

See also:

As usual, if there's something we (Chrome) can be doing to help, let us know.  It seems users are recommending turning off SELinux to make it work.

--- Additional comment from dwalsh@redhat.com on 2011-08-15 07:27:38 EDT ---

Well the first one you refer to is strange in that we have not seen before.  This chome-sandbox loading the chrome executable as a shared library requiring execmod.  I just asked the F15 maintainer of selinux-policy to add allow rules to make this happen and I checked in fixes for F16.

Secondly we are going to stop confining chrome-sandbox by default for most users (unconfined_t).  

We have fixes coming in F16 that should automatically get the label on the ~/.chrome directory correct. 

Is Chrome or Chrome-sandbox moving files into the ~/.config directory or creating them there directly?

--- Additional comment from evan@chromium.org on 2011-08-15 11:17:13 EDT ---

(In reply to comment #1)
> Is Chrome or Chrome-sandbox moving files into the ~/.config directory or
> creating them there directly?

No, I don't believe so.  But chrome_sandbox does chroot into /proc/self/fdinfo, which has the potential to confuse things.

is most of the code -- scroll to the very bottom for the main() overview.

  if (!MoveToNewNamespaces())
    return 1;
  if (!SpawnChrootHelper())
    return 1;
  if (!DropRoot())
    return 1;
  if (!SetupChildEnvironment())
    return 1;

--- Additional comment from mactech@webdragon.net on 2011-08-18 10:55:20 EDT ---


would like to note that this particular issue was triggered by chrome doing text-relocations and that this policy for selinux has been around at least since F12. 

did some followup and discovered the following 


how relevant this is to the issue, I leave to you guys, but for the record, I haven't changed the selinux policy on this box to match the current F15 policy, chrome worked previously, and now it triggers text relocation alerts in selinux. 

i.e. something changed in chrome, not selinux policy. policy does not IMHO need rewriting for this issue.

*tips proverbial hat*

--- Additional comment from mactech@webdragon.net on 2011-08-18 12:23:34 EDT ---

Created attachment 518904 [details]
full details of the AVC

attached is the full avc denial message as reported by setroubleshoot. Again this issue exists on F12 and is NOT caused by any new SELinux policy change in newer releases of Fedora, but is in fact cause by chrome now doing text-relocations.

--- Additional comment from evan@chromium.org on 2011-08-18 12:28:42 EDT ---

Thanks for your help!  I will try to track down what has changed.

To clarify the problem is it true that Fedora 12 would warn, and later Fedoras won't run any binary with text relocations?

--- Additional comment from mactech@webdragon.net on 2011-08-18 12:46:57 EDT ---

I don't recall offhand what the default setting of Fedora 12 was, but I believe it was started with Enforcing, not Permissive. If I'm not mistaken, the default policy has been Enforcing, for a while now...

--- Additional comment from dwalsh@redhat.com on 2011-08-22 14:39:35 EDT ---

Yes chrome-sandbox has been locked down for a while.  The major problems we are seeing now are files being created under ~/.config with the wrong label.  I think this will only happen if the first app run at login before .config was created was chrome.  In F16  Hopefully this problem will disappear, as unconfined_t creating .config will automagically label it correctly.  

The other problem we see is around memory handling chrome seems to fail on lots of memory checks (So does firefox)  And we have slowly loosened the policy.  Although doing this on chrome-sandbox is not great.  The best possible outcome of crome-sandbox would be to split the label of the process that sets up the sandbox from the actual running of the code within the sandbox.

Right now since we only have one process running, we have to give far greater privs to chrome-sandbox that we would like.

Comment 1 Jiri Koten 2011-09-19 16:09:41 UTC
Created attachment 523863 [details]
AVC output

The same issue happens also in rhel6.

Comment 2 Daniel Walsh 2011-09-19 17:22:02 UTC
Need to back port fix from F16 for wacky Chrome Code.

Comment 3 Milos Malik 2011-09-20 13:23:12 UTC
If allow_execmod boolean is off, then following AVC appears:
time->Tue Sep 20 14:12:03 2011
type=SYSCALL msg=audit(1316520723.723:127): arch=40000003 syscall=125 success=no exit=-13 a0=b45bb000 a1=31fd000 a2=5 a3=bff83490 items=0 ppid=4250 pid=5722 auid=503 uid=503 gid=505 euid=503 suid=503 fsuid=503 egid=505 sgid=505 fsgid=505 tty=pts0 ses=5 comm="chrome" exe="/opt/google/chrome/chrome" subj=unconfined_u:unconfined_r:unconfined_execmem_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1316520723.723:127): avc:  denied  { execmod } for  pid=5722 comm="chrome" path="/opt/google/chrome/chrome" dev=dm-0 ino=14873 scontext=unconfined_u:unconfined_r:unconfined_execmem_t:s0-s0:c0.c1023 tcontext=system_u:object_r:execmem_exec_t:s0 tclass=file

If allow_execmod boolean is on, then following AVC appears:
time->Tue Sep 20 15:19:50 2011
type=SYSCALL msg=audit(1316524790.921:185): arch=40000003 syscall=125 success=no exit=-13 a0=b467d000 a1=31fd000 a2=5 a3=bf99c890 items=0 ppid=0 pid=6217 auid=503 uid=503 gid=505 euid=503 suid=503 fsuid=503 egid=505 sgid=505 fsgid=505 tty=pts0 ses=5 comm="chrome" exe="/opt/google/chrome/chrome" subj=unconfined_u:unconfined_r:chrome_sandbox_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1316524790.921:185): avc:  denied  { execmod } for  pid=6217 comm="chrome" path="/opt/google/chrome/chrome" dev=dm-0 ino=14873 scontext=unconfined_u:unconfined_r:chrome_sandbox_t:s0-s0:c0.c1023 tcontext=system_u:object_r:execmem_exec_t:s0 tclass=file

Comment 4 Miroslav Grepl 2011-09-20 15:32:14 UTC
Fixed in selinux-policy-3.7.19-112.el6

Comment 7 Miroslav Grepl 2011-09-21 13:48:31 UTC
I have found a bug in the interface. Also fixed in Fedora

Comment 10 Miroslav Grepl 2011-09-22 09:15:34 UTC
We need to add


to execmem_role_template() interface

Comment 14 Miroslav Grepl 2011-09-26 13:23:55 UTC
Well, I think I got this. The problem is with policycoreutils and with 

* Tue Sep 13 2011 Dan Walsh <dwalsh@redhat.com> 2.0.83-19.14 - restorecon should not alter MCS/MLS labels only types unless you specify -F Resolves: #736153

which causes after "touch /.autorelabel" /dev is not relabeled back to s0 how is defined in the policy.

/dev            -d  gen_context(system_u:object_r:device_t,s0)

The issue is with /usr/share/dracut/modules.d/99base/selinux-loadpolicy.sh

[ -e "$NEWROOT"/.autorelabel ] && ( echo 0 > "$NEWROOT"/selinux/enforce )
            mount --bind /dev "$NEWROOT/dev"
            chroot "$NEWROOT" /sbin/restorecon -R /dev

where we need to add -F flag.

Comment 15 Petr Sklenar ⛄ 2011-09-27 09:04:33 UTC
it looks like this bug change behavior of many tools as many of our test starts failing:
see few example:

$ service iptables save
$ iptables: Saving firewall rules to /etc/sysconfig/iptables: [FAILED]
with policycoreutils-2.0.83-19.13.el6.i686 it works well !!!

$ rm -rf /etc/named.conf
$ touch /etc/named.conf
$ restorecon /etc/named.conf
$ echo $?
$ ls -laZ /etc/named.conf
-rw-r--r--. root root unconfined_u:object_r:named_conf_t:s0 /etc/named.conf
# with policycoreutils-2.0.83-19.13.el6.i686 it works well !!!

... adding keyword Regression

Comment 16 Petr Sklenar ⛄ 2011-09-27 09:10:00 UTC
(In reply to comment #15)
policycoreutils-2.0.83-19.15.el6.x86_64 was used ^

maybe it has something in common with bug 736153 but comment 736153#c10 says that its verified. So I am not sure which bug it is.

Comment 17 Miroslav Grepl 2011-09-27 10:11:55 UTC
this is a different issue which is fixed in 

* Fri Sep 23 2011 Dan Walsh <dwalsh@redhat.com> 2.0.83-19.16
- Restorecon should not be exiting with a 1 when it is successful in relabeling a file
Resolves: #740699
Resolves: #739587

Comment 18 Miroslav Grepl 2011-09-27 10:12:41 UTC
I am moving this bug back to MODIFIED.

Comment 23 Daniel Walsh 2011-10-03 16:12:26 UTC
Miroslav I just added this to F16.

diff --git a/policy/modules/apps/execmem.if b/policy/modules/apps/execmem.if
index fc9014f..e23f640 100644
--- a/policy/modules/apps/execmem.if
+++ b/policy/modules/apps/execmem.if
@@ -66,9 +66,8 @@ template(`execmem_role_template',`
-       optional_policy(`
-               execmem_execmod($1_execmem_t)
-       ')
+       allow $3 execmem_exec_t:file execmod;
+       allow $1_execmem_t execmem_exec_t:file execmod;
        # needed by plasma-desktop

Lets add it to RHEL6.

Comment 24 Miroslav Grepl 2011-10-03 18:40:46 UTC
The problem is we don't have execmem role for xguest.

Comment 25 Daniel Walsh 2011-10-03 20:20:17 UTC
We should add that also.

Comment 26 Miroslav Grepl 2011-10-05 13:39:14 UTC
Fixed in selinux-policy-3.7.19-115.el6

Comment 29 Scott R. Godin 2011-10-07 22:37:12 UTC
http://code.google.com/p/chromium/issues/detail?id=87704  noting that google chrome devs seem to be on track for removing the text relocations, set for milestone v16 of chrome

Comment 30 errata-xmlrpc 2011-12-06 10:19:09 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


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