Hide Forgot
+++ This bug was initially created as a clone of Bug #730449 +++ 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. --- Additional comment from dwalsh 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 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. 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; --- Additional comment from mactech on 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* --- Additional comment from mactech 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 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 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 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.
Created attachment 523863 [details] AVC output The same issue happens also in rhel6.
Need to back port fix from F16 for wacky Chrome Code.
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 ----
Fixed in selinux-policy-3.7.19-112.el6
I have found a bug in the interface. Also fixed in Fedora
We need to add optional_policy(` execmem_execmod($1_execmem_t) ') to execmem_role_template() interface
Well, I think I got this. The problem is with policycoreutils and with * Tue Sep 13 2011 Dan Walsh <dwalsh> 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.
hello, 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 $? 1 $ 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
(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.
this is a different issue which is fixed in * Fri Sep 23 2011 Dan Walsh <dwalsh> 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
I am moving this bug back to MODIFIED.
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',` files_execmod_tmp($1_execmem_t) - 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 optional_policy(` Lets add it to RHEL6.
The problem is we don't have execmem role for xguest.
We should add that also.
Fixed in selinux-policy-3.7.19-115.el6
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
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. http://rhn.redhat.com/errata/RHBA-2011-1511.html