Bug 730449 - Chrome/Chromium cannot start due to text relocations
Summary: Chrome/Chromium cannot start due to text relocations
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: rawhide
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: 739618 741430
TreeView+ depends on / blocked
Reported: 2011-08-13 02:56 UTC by Evan Martin (Chromium)
Modified: 2011-11-21 16:56 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 739618 (view as bug list)
Last Closed: 2011-11-21 16:56:46 UTC

Attachments (Terms of Use)
full details of the AVC (3.12 KB, text/plain)
2011-08-18 16:23 UTC, Scott R. Godin
no flags Details

Description Evan Martin (Chromium) 2011-08-13 02:56:46 UTC
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.

Comment 1 Daniel Walsh 2011-08-15 11:27:38 UTC
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?

Comment 2 Evan Martin (Chromium) 2011-08-15 15:17:13 UTC
(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;

Comment 3 Scott R. Godin 2011-08-18 14:55:20 UTC

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*

Comment 4 Scott R. Godin 2011-08-18 16:23:34 UTC
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.

Comment 5 Evan Martin (Chromium) 2011-08-18 16:28:42 UTC
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?

Comment 6 Scott R. Godin 2011-08-18 16:46:57 UTC
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...

Comment 7 Daniel Walsh 2011-08-22 18:39:35 UTC
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 8 cornel panceac 2011-10-12 15:19:41 UTC

here's what i've got on (updated) f14 right now:

Oct 12 18:13:15 otp-cpanceac-l1 kernel: [ 6026.209887] type=1400 audit(1318432395.873:7): avc:  denied  { execmod } for  pid=4427 comm="chromium-browse" path="/usr/lib/chromium-browser/chromium-browser" dev=sda5 ino=3016262 scontext=unconfined_u:unconfined_r:chrome_sandbox_t:s0-s0:c0.c1023 tcontext=system_u:object_r:execmem_exec_t:s0 tclass=file

i've fixed the first denial at home then i had to fix another one to get chromium start again. i can confirm that chromium worked fine before it was updated to a newer version. right now i have:

$ rpm -q chromium

off-topic: there was no selinux applet warning about this, but maybe abrtd was messed by too many messages :) (i remember it complaining about a qeue being full or something like this ...)

Comment 9 Daniel Walsh 2011-10-12 17:52:12 UTC
Cornel please open a new bugzilla for F14.

Comment 10 cornel panceac 2011-10-12 18:22:01 UTC

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