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.
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?
(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;
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*
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.
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?
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...
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.
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 ...)
Cornel please open a new bugzilla for F14.
done https://bugzilla.redhat.com/show_bug.cgi?id=745569