This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 730449 - Chrome/Chromium cannot start due to text relocations
Chrome/Chromium cannot start due to text relocations
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Miroslav Grepl
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 739618 741430
  Show dependency treegraph
 
Reported: 2011-08-12 22:56 EDT by Evan Martin (Chromium)
Modified: 2011-11-21 11:56 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 739618 (view as bug list)
Environment:
Last Closed: 2011-11-21 11:56:46 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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

  None (edit)
Description Evan Martin (Chromium) 2011-08-12 22:56:46 EDT
Upstream bug:
http://code.google.com/p/chromium/issues/detail?id=87704

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


See also:
https://bugzilla.redhat.com/show_bug.cgi?id=710273
https://bugzilla.redhat.com/show_bug.cgi?id=710276
https://bugzilla.redhat.com/show_bug.cgi?id=730406

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 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?
Comment 2 Evan Martin (Chromium) 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.


http://src.chromium.org/viewvc/chrome/trunk/src/sandbox/linux/suid/sandbox.c?revision=79921&view=markup
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 10:55:20 EDT
http://code.google.com/p/chromium/issues/detail?id=87704#c23

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 

http://code.google.com/p/chromium/issues/detail?id=87704#c24

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 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.
Comment 5 Evan Martin (Chromium) 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?
Comment 6 Scott R. Godin 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...
Comment 7 Daniel Walsh 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 8 cornel panceac 2011-10-12 11:19:41 EDT
hello

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
chromium-14.0.835.186-1.fc14.i686

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 13:52:12 EDT
Cornel please open a new bugzilla for F14.
Comment 10 cornel panceac 2011-10-12 14:22:01 EDT
done
https://bugzilla.redhat.com/show_bug.cgi?id=745569

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