Resum: SELinux is preventing /opt/google/chrome/chrome-sandbox "write" access on oom_adj. Descripció detallada: [chrome-sandbox has a permissive type (chrome_sandbox_t). This access was not denied.] SELinux denied access requested by chrome-sandbox. It is not expected that this access is required by chrome-sandbox and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Permet l'accés: You can generate a local policy module to allow this access - see FAQ (http://docs.fedoraproject.org/selinux-faq-fc5/#id2961385) Please file a bug report. Informació addicional: Context de la font unconfined_u:unconfined_r:chrome_sandbox_t:s0-s0:c 0.c1023 Context de l'objectiu unconfined_u:unconfined_r:unconfined_execmem_t:s0- s0:c0.c1023 Objectes objectius oom_adj [ file ] Font chrome-sandbox Camí de la font /opt/google/chrome/chrome-sandbox Port <Desconegut> Ordinador (removed) Paquests RPM font google-chrome-beta-5.0.342.9-43360 Paquets RPM destí RPM de política selinux-policy-3.6.32-110.fc12 S'ha habilitat el Selinux True Tipus de la política targeted Mode forçat Enforcing Nom del connector catchall Nom de la màquina (removed) Plataforma Linux (removed) 2.6.32.10-90.fc12.x86_64 #1 SMP Tue Mar 23 09:47:08 UTC 2010 x86_64 x86_64 Contador d'alertes 1 Vist per primera vegada dg 11 abr 2010 14:23:39 CEST Vist per darrera vegada dg 11 abr 2010 14:23:39 CEST Identificador local 5a9c5d9f-c347-4b31-8742-d8469a543057 Número de línies Missatges d'auditoria sense p node=(removed) type=AVC msg=audit(1270988619.557:1565): avc: denied { write } for pid=15967 comm="chrome-sandbox" name="oom_adj" dev=proc ino=4752545 scontext=unconfined_u:unconfined_r:chrome_sandbox_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_execmem_t:s0-s0:c0.c1023 tclass=file node=(removed) type=SYSCALL msg=audit(1270988619.557:1565): arch=c000003e syscall=2 success=yes exit=3 a0=7fff8c5dee70 a1=1 a2=6a64615f6d6f6f2f a3=7fff8c5deb60 items=0 ppid=8759 pid=15967 auid=500 uid=500 gid=500 euid=0 suid=0 fsuid=0 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="chrome-sandbox" exe="/opt/google/chrome/chrome-sandbox" subj=unconfined_u:unconfined_r:chrome_sandbox_t:s0-s0:c0.c1023 key=(null) Hash String generated from catchall,chrome-sandbox,chrome_sandbox_t,unconfined_execmem_t,file,write audit2allow suggests: #============= chrome_sandbox_t ============== allow chrome_sandbox_t unconfined_execmem_t:file write;
Please report this as a bug to chrome. This is a leaked file descriptor, and allowing it would allow chrome_sandbox to prevent itself from being oom killed. I will not fix this in SELinux in that I consider it a potential problem in Systems that do not use SELinux. Google/Chrome developers should set the close on exec flag after opening this file. fcntl(fd, F_SETFD, FD_CLOEXEC)
Reported at http://code.google.com/p/chromium/issues/detail?id=41853
Not a file descriptor leak. In this case we're running the chrome-sandbox binary to use its SUID capabilities in order to set the OOM value for the child process. (Yep, it's a bit nasty. No argument there. Open to suggestions.) However, if you don't want to open up oom_score for this then I'm happy to submit a change which tries to stat '/selinux' and, if found, doesn't try to adjust the OOM score. AGL
It's not clear to me why you need suid priviledges for that... I can certainly write a '1' to /proc/$$/oom_adj without becoming root, and I don't see any chrome processes not running as myself. Furthermore, do these settings stick around across exec? Wouldn't it be enough to set them before the exec?
Looks like you only need privs to lower the oom_adj value. If you set it in an unpriv process to 2 you can not set it back to 1 or anything less. (10 seconds worth of testing.)
*** Bug 585966 has been marked as a duplicate of this bug. ***
Sorry for letting this slip though the cracks for so long... 1) You can't change the oom_adj of a non-dumpable process (EPERM) unless you're root. Because of this, we can't set the oom_adj from the browser process. 2) We can't set the oom_adj before entering the sandbox because the zygote is in the sandbox and the zygote is as critical as the browser process. Its oom_adj value shouldn't be changed. 3) A non-dumpable process can't even change its own oom_adj because it's root owned 0644. The sandboxed processes don't even have /proc, but one could imagine passing in a descriptor from outside. I've run out of tricks for this case so I'm just going to disable oom_adj in the SELinux case.
(In reply to comment #7) > Sorry for letting this slip though the cracks for so long... > > 1) You can't change the oom_adj of a non-dumpable process (EPERM) unless you're > root. Because of this, we can't set the oom_adj from the browser process. > 2) We can't set the oom_adj before entering the sandbox because the zygote is > in the sandbox and the zygote is as critical as the browser process. Its > oom_adj value shouldn't be changed. > 3) A non-dumpable process can't even change its own oom_adj because it's root > owned 0644. The sandboxed processes don't even have /proc, but one could > imagine passing in a descriptor from outside. > > I've run out of tricks for this case so I'm just going to disable oom_adj in > the SELinux case. If that is the case I would prefer Google fix their access violation instead of SELinux being careless about it.
(In reply to comment #8) > If that is the case I would prefer Google fix their access violation instead of > SELinux being careless about it. I think that's what I just said.
Hopefully fixed by http://src.chromium.org/viewvc/chrome?view=rev&revision=46724 I think this bug can be closed.
Well wait a second. Is adjusting the oom_adj making the chrome sandbox more likely to be killed? If so then I think I have got to figure a way to allow this. If comment 5 is correct I can add a label to oom_adj and then allow the sandbox to write to it.
We are adjusting oom_adj to make the renderer processes more likely to be killed. These processes are children of the zygote (which is important, and not adjusted). Killing a renderer just "Sad tabs" all the pages for a given domain. If you're willing to change the policy to allow this then that works too.
Steven or Eric, Is there a way to add a label to /proc/*/oom_adj Such that I can say chrome_sandbox_t can write to its parents oom_adj field?
Not presently, no. All /proc/pid inodes are labeled with the label of the associated task (security_task_to_inode). Changes to the kernel would be required to support finer-grained labeling within /proc/pid. Other (not per-process) /proc nodes can be individually labeled already via genfscon. FWIW, testing for presence of /selinux is not a strong indicator of SELinux as it may just be an empty mountpoint if the distro ships SELinux support at all but it is disabled by default or disabled by the user. Better to check whether there is something mounted there, e.g. - statfs("/selinux", &buf) == 0 && buf.f_type == SELINUX_MAGIC -or- - access("/selinux/enforce", F_OK) == 0
I guess then the question is what is the risk of allowing the chrome-sandbox from writing to /proc/PPID/*
(In reply to comment #15) > I guess then the question is what is the risk of allowing the chrome-sandbox > from writing to /proc/PPID/* If you do that I think I will uninstall it. Does Firefox have that ability?
Firefox does not sandbox its content processing, so for this process it is still more secure then firefox. When using firefox, you run it in the users context by default. Probably unconfined_t so if you had a bug that is triggered by content, it could take over firefox. If you use chrome it runs in unconfined_t but its sandbox runs in chrome_sandbox_t. What we are looking at is allowing chrome_sandbox_t the ability to write to files under /proc/PID/ of the chrome application.
(In reply to comment #17) > If you use chrome it runs in unconfined_t but its sandbox runs in > chrome_sandbox_t. What we are looking at is allowing chrome_sandbox_t the > ability to write to files under /proc/PID/ of the chrome application. yeah .. I don't like that part. I don't like giving Google Chrome more access to my system than I have on a regular basis. I think the real problem resides in the fact that Google Chrome is in itself an OS, a Linux based fork, and Google has not fully separated the OS aspect from it's "browser" so Chrome is attempting to act like it is at home and do what it would normally do. If you allow Google's Chrome more access than I have .... I uninstall it.
(In reply to comment #15) > I guess then the question is what is the risk of allowing the chrome-sandbox > from writing to /proc/PPID/* I wouldn't recommend allowing it. First, the granularity is all wrong - you just want to allow this particular instance of the sandbox to write to the oom_adj file of the parent. But the SELinux denial is in terms of the security contexts only, and can't distinguish this instance of the sandbox from any other, nor the parent from anything else running in unconfined_execmem_t, nor oom_adj from any other file in /proc/pid. Second, it sounds like the only reason it is being done this way in the first place is as a compromise to address limitations introduced by the earlier decision to make the process non-dumpable. And that in turn was motivated by a desire to block ptrace among the renderers? But if they were just run in different contexts (e.g. just randomly generate and use a category like sandbox or svirt does), ptrace could be blocked based on that without impairing dumpability.
(In reply to comment #19) > (In reply to comment #15) > > I guess then the question is what is the risk of allowing the chrome-sandbox > > from writing to /proc/PPID/* > > I wouldn't recommend allowing it. > Hey thanks for listening. I am done newbing up your geek talk here. I just wanted to say one last thing. With what Daniel is saying, Chrome is trying to write to the proc/PID/, and with the errors I am getting from Google on my Fedora 11 32bit machine I would have to say that Google's subprocessing / forked processing of their tabs is something Google needs to look at. I've been getting a new error, only after I open a new tab. I think Google is trying to run an OS / Browser that is a fork of Linux without giving it a proper VM to live in. So it tries to act like it's at home, but it's not, it is a guest. I thank Stephen for not recommending the allowance and Daniel for putting up with my newbery. And with that I am back to reading emails.
> yeah .. I don't like that part. I don't like giving Google Chrome more access > to my system than I have on a regular basis. But, you _do_ have that access on a regular basis (as does any non-specially restricted/sandboxed process). > I think the real problem resides in the fact that Google Chrome is in itself > an OS, a Linux based fork, and Google has not fully separated the OS aspect > from it's "browser" so Chrome is attempting to act like it is at home and do > what it would normally do. Calling Chrome an 'OS' and a 'Linux fork' is wrong on so many levels... I'm not sure there's any way you can look at that statement to see it as 'correct' (unless you subscribe to the entire 'the web is the OS' way of thinking). > With what Daniel is saying, Chrome is trying to write to the proc/PID/, and > with the errors I am getting from Google on my Fedora 11 32bit machine I would > have to say that Google's subprocessing / forked processing of their tabs is > something Google needs to look at. I've been getting a new error, only after I > open a new tab. Sure, new tab -> new renderer -> new sandbox/process -> on startup needs to be adjusted so it preferentially dies on OOM [Out of Memory: ie. memory exhaustion]. That's actually pretty sane. The fact that there doesn't seem to currently be a sane way to give Chrome the ability to do that is the problem. Chrome's behaviour is correct and desirable. What broke down is the granularity of the security model. This can be fixed in many ways: * easy way: widen the privileges of a slightly less granular ACL (ie. grant access to /proc/PID/*) [ie. what was suggested here] * hard way: rework the security of /proc in kernel so you can grant access to single files within /proc/PID (ie. /proc/PID/oom_adj) as opposed to just /proc/PID/* (like can be done currently) [this is an easy change, hard to get accepted upstream, and hard to get rolled out] * hard way: rework the way Chrome does sandboxing to potentially work around this problem [this is a very complex change, but easy to get rolled out] * stupid way (currently implemented) on selinux don't touch oom_adj and thus have other processes (like the X server) die on OOM instead of tabs of a browser (which is likely the memory hog anyway) - this is definitely sub-optimal. > I think Google is trying to run an OS / Browser that is a fork of Linux > without giving it a proper VM to live in. So it tries to act like it's at > home, but it's not, it is a guest. It's the responsibility of the kernel (ie. Linux) to provide to userspace (ie. Chrome) sufficient hooks/calls/functionality/etc. to make it possible to create a good sandbox. Linux is currently a little lacking in this department - it is kind-of-sort-of doable, but very hard, very fragile, and extremely complex.
(In reply to comment #21) I know I am a newb, but please don't call me wrong. You can't toss away Google's ad campaign. What else am I supposed to think? Google Chrome OS: http://www.youtube.com/watch?v=0QRO3gKj3qw
(In reply to comment #21) > Calling Chrome an 'OS' and a 'Linux fork' is wrong on so many levels... I'm not > sure there's any way you can look at that statement to see it as 'correct' > (unless you subscribe to the entire 'the web is the OS' way of thinking). Wait a minute! This is you? http://www.linkedin.com/in/maciejzenczykowski And you have not subscribed to the 'statelessness' of Google Chrome OS? I quit! I am done with Google.
Maciej, Why cant the chrome-sandbox to set the oom_adj on itself, then have the tab process die when its chrome-sandbox gets killed?
Okay I see what the problem is. You are confusing "Chrome OS" with "Chrome". I guess it is quite a confusing choice of names. There is quite a significant difference between "Chrome" (the web browser) which is entirely a userspace application (and runs on Windows, Mac, various distributions of Linux, etc) and "Chrome OS" (which is a Linux based OS, which includes the 'Chrome' browser as a vital component - and this is where the 'Chrome OS' name comes from). Now it is true, that from a user's perspective there may actually be little difference between 'Chrome' and 'Chrome OS', since the user visible UI [User Interface] of 'Chrome OS' is just (for the most part) the 'Chrome' browser. However... from a technical standpoint the difference between 'Chrome' the browser and 'Chrome OS' the operating system is humongous. This entire discussion/bug is about the Chrome browser and how it runs on Fedora Linux (which is the OS here). It doesn't really relate in any particular way to "Chrome OS". ie. think of it this way: - "Chrome" the web browser is roughly a parallel to "Firefox" the web browser - "Chrome OS" the operating system is basically a Linux distribution just like "Fedora" (or Ubuntu or Debian or any other Linux distro). Fedora comes with Firefox by default (and you can install Chrome). Chrome OS comes with Chrome by default (and you could install/hack Firefox onto it as well, although that's not really what it's meant for: it's supposed to be very light weight).
Dan: the SUID helper gets run and it sandboxes the Zygote process. The Zygote process (which is critical and shouldn't have its oom_adj changed) forks off the renderer processes. However, within the sandbox, /proc doesn't exist so we can't access it from there. I'll make the change to reflect Stephen's suggestions for /selinux, otherwise I think this bug is taking more time than is warranted. We have to start of 'real' SELinux support behind a #ifdef. If I get around to it, I'll do the trick of randomly selecting categories for each renderer. Cheers
Daniel, I have no idea... I just happen to run Chrome (the browser) on my Fedora laptop and home desktop/media center. I've never even looked at the browser source code (I'm just a very newb-ish kernel hacker...). I remember there was some LWN article [ http://lwn.net/Articles/347547/ ] about Chrome sandboxing and something about using some secure computing (seccomp) aspect of the Linux kernel to lock down the rendering threads so that they have no syscall access besides read/write/sigreturn/exit. I'm not sure if and how this fits into the picture here, but maybe the threads/processes in question have already been locked down so tight they can't do anything at that point??? [still not clear to be why they couldn't change oom_adj before they drop privs...] [/opt/google/chrome]$ ls -alZ chrome chrome-sandbox -rwxr-xr-x. root root system_u:object_r:execmem_exec_t:s0 chrome -rwsr-xr-x. root root system_u:object_r:chrome_sandbox_exec_t:s0 chrome-sandbox Notice that chrome is 42MB while the setuid root chrome-sandbox is 14KB. It's probably related to how (for memory savings) the zygote works. Here's a guesstimate: you launch the browser (chrome), the browser launches the zygote (chrome --type=zygote) which then forks of an instance of the renderer (chrome --type=renderer) or extension (chrome --type=extension) for each rendered (tab) or extension that it needs. Now it wants to lock down these renderers and extensions (before they start doing anything), but it doesn't have sufficient privileges, so it forks of and execs chrome-sandbox (which is suid-root) to do any needed selinux transitioning or other (oom_adj) twiddling needed. I'm *really* *really* _guessing_ here though, since I'm basing this on what I see in ps and ls output and what I remember reading in LWN. Maybe giving the chrome binary it's own type (ie. execmem_exec_t -> chrome_exec_t with same privs) and allowing chrome_sandbox_exec_t to write to chrome_exec_t would be enough?
It was probably a mistake to put this suggestion at the bottom of the previous comment, so I'll repeat it here: Maybe giving the chrome binary it's own selinux type (ie. change from the current 'execmem_exec_t' to 'chrome_exec_t' with the same privs) and allowing chrome_sandbox_exec_t to write to chrome_exec_t would be enough?
This just eats me that Google would try and change Linux instead of working within the set path. Now, I do understand Qt, so I am not a total newb. I picked up oom_adj was an Out of Memory Adjustment, but I had to research that. This file can be used to adjust the score used to select which process should be killed in an out-of-memory (OOM) situation. The kernel uses this value for a bit-shift operation of the process's oom_score value: valid values are in the range -16 to +15, plus the special value -17, which disables OOM-killing altogether for this process. A positive score increases the likelihood of this process being killed by the OOM-killer; a negative score decreases the likelihood. The default value for this file is 0; a new process inherits its parent's oom_adj setting. A process must be privileged (CAP_SYS_RESOURCE) to update this file. (In reply to comment #26) > Dan: the SUID helper gets run and it sandboxes the Zygote process. The Zygote > process (which is critical and shouldn't have its oom_adj changed) forks off > the renderer processes. However, within the sandbox, /proc doesn't exist so we > can't access it from there. > > I'll make the change to reflect Stephen's suggestions for /selinux, otherwise I > think this bug is taking more time than is warranted. > > We have to start of 'real' SELinux support behind a #ifdef. If I get around to > it, I'll do the trick of randomly selecting categories for each renderer. > > > Cheers Whether or not /proc/ doesn't exist in the sandbox, Qt can pass the location as an object so that it can be accessed. After looking at how oom_adj works, I would rather see Google create a script that can accept CAP_SYS_RESOURCE (thought I have not researched that yet.) than attempt to gain some weird sounding tunnel through. (In reply to comment #19) > (In reply to comment #15) > > I guess then the question is what is the risk of allowing the chrome-sandbox > > from writing to /proc/PPID/* > > I wouldn't recommend allowing it. > > First, the granularity is all wrong - you just want to allow this particular > instance of the sandbox to write to the oom_adj file of the parent. But the > SELinux denial is in terms of the security contexts only, and can't distinguish > this instance of the sandbox from any other, nor the parent from anything else > running in unconfined_execmem_t, nor oom_adj from any other file in /proc/pid. > > Second, it sounds like the only reason it is being done this way in the first > place is as a compromise to address limitations introduced by the earlier > decision to make the process non-dumpable. And that in turn was motivated by a > desire to block ptrace among the renderers? But if they were just run in > different contexts (e.g. just randomly generate and use a category like sandbox > or svirt does), ptrace could be blocked based on that without impairing > dumpability. But Stephen said the subprocess is attempting to change the the oom_adj of the parent? Then, again, that is a fault of Googles browser, isn't it? Each and every error occurs when a new tab is opened (apparently .. even when the first tab is opened), so it sounds like the tab, which is a forked process, is not even sending an object back to the parent but is attempting to make changes with it's own privileges. When in fact the forked tabs should be communicating through the parent to the OS. I don't want to see Chrome receive extra privileges ... I apologize if I am getting on anyone's nerves.
Dan: I think this bug can be closed. You're always welcome to email me if you need any changes from Chrome. I'm taking myself of the CC now because of the level of noise that this bug has picked up.
[New Thread 7688] [New Thread 7689] [New Thread 7698] [New Thread 7699] [New Thread 7700] [New Thread 7795] [New Thread 7794] [New Thread 9734] Core was generated by `/opt/google/chrome/chrome --type=plugin --plugin-path=/opt/google/chrome/libgcf'. Program terminated with signal 11, Segmentation fault. #0 0x1180d068 in ?? () Thread 8 (Thread 9734): #0 0x00971424 in __kernel_vsyscall () No symbol table info available. #1 0x008b6d33 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 No symbol table info available. #2 0x00fd62a9 in ?? () from /opt/google/chrome/libgcflashplayer.so No symbol table info available. #3 0x00ff87d3 in ?? () from /opt/google/chrome/libgcflashplayer.so No symbol table info available. #4 0x00fd6cd4 in ?? () from /opt/google/chrome/libgcflashplayer.so No symbol table info available. #5 0x008b1f19 in start_thread () from /lib/libpthread.so.0 No symbol table info available. #6 0x00ed9ebe in clone () from /lib/libc.so.6 No symbol table info available. Thread 7 (Thread 7794): #0 0x00971424 in __kernel_vsyscall () No symbol table info available. #1 0x00eced96 in poll () from /lib/libc.so.6 No symbol table info available. #2 0x02a89ce3 in ?? () from /usr/lib/libpulse.so.0 No symbol table info available. #3 0x02a764ca in pa_mainloop_poll () from /usr/lib/libpulse.so.0 No symbol table info available. #4 0x02a77d54 in pa_mainloop_iterate () from /usr/lib/libpulse.so.0 No symbol table info available. #5 0x02a77e34 in pa_mainloop_run () from /usr/lib/libpulse.so.0 No symbol table info available. #6 0x02a89a84 in ?? () from /usr/lib/libpulse.so.0 No symbol table info available. #7 0x02ade863 in ?? () from /usr/lib/libpulsecommon-0.9.21.so No symbol table info available. #8 0x008b1f19 in start_thread () from /lib/libpthread.so.0 No symbol table info available. #9 0x00ed9ebe in clone () from /lib/libc.so.6 No symbol table info available. Thread 6 (Thread 7795): #0 0x00971424 in __kernel_vsyscall () No symbol table info available. #1 0x00eced96 in poll () from /lib/libc.so.6 No symbol table info available. #2 0x036fab66 in ?? () from /lib/libasound.so.2 No symbol table info available. #3 0x036fad3b in snd_pcm_wait () from /lib/libasound.so.2 No symbol table info available. #4 0x0137bb83 in ?? () from /opt/google/chrome/libgcflashplayer.so No symbol table info available. #5 0x008b1f19 in start_thread () from /lib/libpthread.so.0 No symbol table info available. #6 0x00ed9ebe in clone () from /lib/libc.so.6 No symbol table info available. Thread 5 (Thread 7700): #0 0x00971424 in __kernel_vsyscall () No symbol table info available. #1 0x008b6d33 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 No symbol table info available. #2 0x00fd62a9 in ?? () from /opt/google/chrome/libgcflashplayer.so No symbol table info available. #3 0x00ff87d3 in ?? () from /opt/google/chrome/libgcflashplayer.so No symbol table info available. #4 0x00fd6cd4 in ?? () from /opt/google/chrome/libgcflashplayer.so No symbol table info available. #5 0x008b1f19 in start_thread () from /lib/libpthread.so.0 No symbol table info available. #6 0x00ed9ebe in clone () from /lib/libc.so.6 No symbol table info available. Thread 4 (Thread 7699): #0 0x00971424 in __kernel_vsyscall () No symbol table info available. #1 0x008b698b in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 No symbol table info available. #2 0x00fd62d7 in ?? () from /opt/google/chrome/libgcflashplayer.so No symbol table info available. #3 0x010db2e5 in ?? () from /opt/google/chrome/libgcflashplayer.so No symbol table info available. #4 0x00fd6cd4 in ?? () from /opt/google/chrome/libgcflashplayer.so No symbol table info available. #5 0x008b1f19 in start_thread () from /lib/libpthread.so.0 No symbol table info available. #6 0x00ed9ebe in clone () from /lib/libc.so.6 No symbol table info available. Thread 3 (Thread 7698): #0 0x00971424 in __kernel_vsyscall () No symbol table info available. #1 0x008b698b in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 No symbol table info available. #2 0x00fd62d7 in ?? () from /opt/google/chrome/libgcflashplayer.so No symbol table info available. #3 0x010db2e5 in ?? () from /opt/google/chrome/libgcflashplayer.so No symbol table info available. #4 0x00fd6cd4 in ?? () from /opt/google/chrome/libgcflashplayer.so No symbol table info available. #5 0x008b1f19 in start_thread () from /lib/libpthread.so.0 No symbol table info available. #6 0x00ed9ebe in clone () from /lib/libc.so.6 No symbol table info available. Thread 2 (Thread 7689): #0 0x00971424 in __kernel_vsyscall () No symbol table info available. #1 0x00ed54b7 in syscall () from /lib/libc.so.6 No symbol table info available. #2 0x0876f1be in ?? () No symbol table info available. #3 0x0876ecd9 in ?? () No symbol table info available. #4 0x0876d34b in ?? () No symbol table info available. #5 0x0875a088 in ?? () No symbol table info available. #6 0x087308f4 in ?? () No symbol table info available. #7 0x087309f6 in ?? () No symbol table info available. #8 0x08748fe0 in ?? () No symbol table info available. #9 0x0873b331 in ?? () No symbol table info available. #10 0x008b1f19 in start_thread () from /lib/libpthread.so.0 No symbol table info available. #11 0x00ed9ebe in clone () from /lib/libc.so.6 No symbol table info available. Thread 1 (Thread 7688): #0 0x1180d068 in ?? () No symbol table info available. From To Syms Read Shared Object Library 0x00aef4b0 0x00b7fbb8 Yes (*) /usr/lib/libX11.so.6 0x008c8a40 0x008c9a68 Yes (*) /lib/libdl.so.2 0x00df52c0 0x00dfb158 Yes (*) /usr/lib/libXrender.so.1 0x006a38f0 0x006a4768 Yes /usr/lib/libXss.so.1 0x00d716b0 0x00d7be28 Yes (*) /usr/lib/libXext.so.6 0x008e68c0 0x008ea928 Yes (*) /lib/librt.so.1 0x045ae0a0 0x048916c8 Yes (*) /usr/lib/libgtk-x11-2.0.so.0 0x029b1f10 0x02a19f38 Yes (*) /usr/lib/libgdk-x11-2.0.so.0 0x002f6480 0x00303ad8 Yes (*) /usr/lib/libatk-1.0.so.0 0x002732f0 0x00287978 Yes (*) /usr/lib/libgdk_pixbuf-2.0.so.0 0x003146b0 0x00319b98 Yes (*) /usr/lib/libpangocairo-1.0.so.0 0x002af240 0x002d1138 Yes (*) /usr/lib/libpango-1.0.so.0 0x00401020 0x00487928 Yes (*) /usr/lib/libcairo.so.2 0x00a68ea0 0x00a9e238 Yes (*) /lib/libgobject-2.0.so.0 0x00ad5bd0 0x00ad6d48 Yes (*) /lib/libgmodule-2.0.so.0 0x00a5bf30 0x00a5d718 Yes (*) /lib/libgthread-2.0.so.0 0x00122160 0x001ba2d8 Yes (*) /lib/libglib-2.0.so.0 0x03105fc0 0x031efc28 Yes (*) /opt/google/chrome/libnss3.so.1d 0x030c8c90 0x030d5048 Yes (*) /opt/google/chrome/libnssutil3.so.1d 0x03318bb0 0x03332768 Yes (*) /opt/google/chrome/libsmime3.so.1d 0x006e2ab0 0x006e3a98 Yes (*) /opt/google/chrome/libplds4.so.0d 0x030bde40 0x030bf818 Yes (*) /opt/google/chrome/libplc4.so.0d 0x030877c0 0x030aac78 Yes (*) /opt/google/chrome/libnspr4.so.0d 0x008b0640 0x008bcdc8 Yes (*) /lib/libpthread.so.0 0x008cf670 0x008dc298 Yes (*) /lib/libz.so.1 0x00daff60 0x00dcbcf8 Yes (*) /usr/lib/libfontconfig.so.1 0x00324340 0x00387788 Yes (*) /usr/lib/libfreetype.so.6 0x03341e50 0x03375f28 Yes (*) /usr/lib/libjpeg.so.62 0x00d856f0 0x00da16d8 Yes (*) /usr/lib/libpng12.so.0 0x02e39f10 0x02e57a28 Yes (*) /usr/lib/libgconf-2.so.4 0x0339a000 0x033a74a8 Yes (*) /opt/google/chrome/libbz2.so.1.0 0x036cce00 0x0375f1d8 Yes (*) /lib/libasound.so.2 0x00d47040 0x00d5fef8 Yes /lib/libexpat.so.1 0x005b16b0 0x005c33c8 Yes (*) /usr/lib/libdbus-glib-1.so.2 0x002236a0 0x00252728 Yes (*) /lib/libdbus-1.so.3 0x02b8f880 0x02bc7078 Yes (*) /usr/lib/libcups.so.2 0x004b4240 0x00506988 Yes /lib/libgcrypt.so.11 0x0074eb30 0x007c18c8 Yes (*) /usr/lib/libstdc++.so.6 0x008884b0 0x008a23a8 Yes (*) /lib/libm.so.6 0x008f1f90 0x00908818 Yes (*) /lib/libgcc_s.so.1 0x00e13bf0 0x00f36514 Yes (*) /lib/libc.so.6 0x00abbe80 0x00aca628 Yes (*) /usr/lib/libxcb.so.1 0x006e8850 0x00700e6f Yes (*) /lib/ld-linux.so.2 0x00269e70 0x0026c3b8 Yes (*) /usr/lib/libXfixes.so.3 0x00c35d50 0x00cef638 Yes (*) /lib/libgio-2.0.so.0 0x003cf360 0x003ec798 Yes (*) /usr/lib/libpangoft2-1.0.so.0 0x00290780 0x00291258 Yes /usr/lib/libXinerama.so.1 0x00de4780 0x00dee938 Yes (*) /usr/lib/libXi.so.6 0x00294150 0x00298c38 Yes /usr/lib/libXrandr.so.2 0x0029ce40 0x002a2418 Yes (*) /usr/lib/libXcursor.so.1 0x003af890 0x003b0498 Yes (*) /usr/lib/libXcomposite.so.1 0x003b27c0 0x003b3268 Yes (*) /usr/lib/libXdamage.so.1 0x0052fb70 0x00587958 Yes (*) /usr/lib/libpixman-1.so.0 0x02eb8e30 0x02ee0a88 Yes (*) /usr/lib/libORBit-2.so.0 0x02e703a0 0x02e96b18 Yes (*) /lib/libgssapi_krb5.so.2 0x02f370d0 0x02fa2c78 Yes (*) /lib/libkrb5.so.3 0x02f02970 0x02f192c8 Yes (*) /lib/libk5crypto.so.3 0x006d7e30 0x006d8ba8 Yes (*) /lib/libcom_err.so.2 0x0323c8a0 0x032b6ed8 Yes (*) /usr/lib/libgnutls.so.26 0x00607630 0x00607c08 Yes (*) /lib/libgpg-error.so.0 0x003b7550 0x003bd8f8 Yes (*) /usr/lib/libavahi-common.so.3 0x033e6950 0x033f01a8 Yes (*) /usr/lib/libavahi-client.so.3 0x005d58c0 0x005da738 Yes (*) /lib/libcrypt.so.1 0x00c14a00 0x00c157f8 Yes (*) /usr/lib/libXau.so.6 0x00a42630 0x00a52298 Yes (*) /lib/libresolv.so.2 0x00a23230 0x00a34c58 Yes (*) /lib/libselinux.so.1 0x02c98cc0 0x02c9d198 Yes (*) /lib/libkrb5support.so.0 0x006dd860 0x006ddfc8 Yes /lib/libkeyutils.so.1 0x030e2200 0x030eed38 Yes (*) /usr/lib/libtasn1.so.3 0x0060e980 0x0063d398 Yes (*) /usr/lib/libfreebl3.so 0x005969b0 0x0059da48 Yes (*) /lib/libnss_files.so.2 0x00659b30 0x0067de38 Yes (*) /usr/lib/gtk-2.0/2.10.0/engines/libclearlooks.so 0x003c30e0 0x003c3a68 Yes (*) /usr/lib/gtk-2.0/modules/libpk-gtk-module.so 0x00805720 0x00807848 Yes (*) /usr/lib/gtk-2.0/modules/libcanberra-gtk-module.so 0x003c6540 0x003c7aa8 Yes (*) /usr/lib/libcanberra-gtk.so.0 0x006853c0 0x0068f408 Yes (*) /usr/lib/libcanberra.so.0 0x034b8720 0x034bd878 Yes (*) /usr/lib/libvorbisfile.so.3 0x033ae770 0x033c3a08 Yes (*) /usr/lib/libvorbis.so.0 0x033922f0 0x03394b38 Yes /usr/lib/libogg.so.0 0x03526610 0x0352f858 Yes /usr/lib/libtdb.so.1 0x033d9a20 0x033de438 Yes (*) /usr/lib/libltdl.so.7 0x00fbbf80 0x018d62e8 Yes (*) /opt/google/chrome/libgcflashplayer.so 0x00816b40 0x008539e8 Yes (*) /usr/lib/libXt.so.6 0x032df020 0x033047c8 Yes (*) /usr/lib/libssl3.so 0x02c8e380 0x02c92d28 Yes /usr/lib/libSM.so.6 0x02ff2530 0x030021f8 Yes /usr/lib/libICE.so.6 0x005cef00 0x005d0bc8 Yes (*) /lib/libuuid.so.1 0x00917810 0x0095b2c8 Yes (*) /usr/lib/libcurl.so.4 0x00973d30 0x00978848 Yes (*) /lib/libidn.so.11 0x034a9710 0x034b0f28 Yes (*) /usr/lib/liblber-2.4.so.2 0x03645080 0x03676718 Yes (*) /usr/lib/libldap-2.4.so.2 0x006a93f0 0x006c5618 Yes (*) /usr/lib/libssh2.so.1 0x0348f1b0 0x0349f9d8 Yes (*) /usr/lib/libsasl2.so.2 0x03032e60 0x0306ac98 Yes (*) /usr/lib/libssl.so.10 0x02cd9e80 0x02dbd798 Yes (*) /usr/lib/libcrypto.so.10 0x009a6bc0 0x009d2fd8 Yes (*) /usr/lib/libsoftokn3.so 0x033fbf80 0x0346f9b8 Yes (*) /usr/lib/libsqlite3.so.0 0x005a2810 0x005a4bd8 Yes (*) /usr/lib/alsa-lib/libasound_module_pcm_pulse.so 0x02a61000 0x02a90af8 Yes (*) /usr/lib/libpulse.so.0 0x02aad7c0 0x02ae1008 Yes (*) /usr/lib/libpulsecommon-0.9.21.so 0x00694ec0 0x00697bd8 Yes (*) /usr/lib/libXtst.so.6 0x0069bf10 0x006a0008 Yes (*) /lib/libwrap.so.0 0x01b0b340 0x01b5baa8 Yes (*) /usr/lib/libsndfile.so.1 0x006cdd80 0x006d0a58 Yes (*) /usr/lib/libasyncns.so.0 0x0300e0d0 0x0301cc68 Yes (*) /lib/libnsl.so.1 0x009e9580 0x00a13848 Yes (*) /usr/lib/libFLAC.so.8 0x01e28b90 0x01e2b068 Yes (*) /usr/lib/libvorbisenc.so.2 0x005a7440 0x005a8ad8 Yes (*) /usr/lib/gconv/UTF-16.so 0x01b78390 0x01b79da8 Yes (*) /usr/lib/gconv/GB18030.so 0x007f7580 0x007f9898 Yes (*) /usr/lib/gconv/EUC-CN.so 0x00867510 0x00867618 Yes (*) /usr/lib/gconv/libGB.so 0x007fd950 0x007ffae8 Yes (*) /usr/lib/gtk-2.0/2.10.0/immodules/im-ibus.so 0x01bb12e0 0x01bd1c38 Yes (*) /usr/lib/libibus.so.2 0x01becb80 0x01bf9f18 Yes (*) /usr/lib/gio/modules/libgioremote-volume-monitor.so 0x01c05c00 0x01c10f18 Yes (*) /usr/lib/libgvfscommon.so.0 0x006d3a00 0x006d4438 Yes (*) /lib/libutil.so.1 0x01c1c480 0x01c37bf8 Yes (*) /usr/lib/gio/modules/libgvfsdbus.so 0x01c430a0 0x01c4bfc8 Yes (*) /lib/libudev.so.0 (*): Shared library is missing debugging information. $1 = 0x0 No symbol "__glib_assert_msg" in current context. eax 0x1 1 ecx 0x1180d068 293654632 edx 0x1180d068 293654632 ebx 0x0 0 esp 0x1180d068 0x1180d068 ebp 0x0 0x0 esi 0x0 0 edi 0x0 0 eip 0x1180d068 0x1180d068 eflags 0x210202 [ IF RF ID ] cs 0x73 115 ss 0x7b 123 ds 0x7b 123 es 0x7b 123 fs 0x0 0 gs 0x33 51 No function contains program counter for selected frame. Debuginfo absent: 02387c511bf69dc9612cddb59f150e4bac79a436 Debuginfo absent: 0768378f38047f17d48b9e9f7f151a8394aa9160 Debuginfo absent: 0a9045f1e53836d398bc54a47d3d6a8a34eba1e8 Debuginfo absent: 0e84498ba9ebc54d908d90604a20ed780efc4f63 Debuginfo absent: 1072a751dd6ce8ecf06707710faac5b32836e361 Debuginfo absent: 18d7d7067cac808fe4dbf2e790c81dffc3b54e85 Debuginfo absent: 19809ca64911a23e3b3eda4f757e6ac490421aea Debuginfo absent: 24ded4515cb2703c2966e3f8d762f8449fba9569 Debuginfo absent: 25dbc55a617ca87b146f5c50a8867b56c725081c Debuginfo absent: 2618a6cf5690f708ca7ac840f136eb7aeeb0eea6 Debuginfo absent: 2646de4387ff5c1e017ee11c375c842f2651293e Debuginfo absent: 2810dd57201dd4156f9723a5b6b346f461403307 Debuginfo absent: 2d460a2adb813bffeb975c623b4ec2cfafabd2b5 Debuginfo absent: 2d70063139f2c1c51a878073584b6796e95177e6 Debuginfo absent: 2ef49f10785af6a1108ae06eea0b371107730e2c Debuginfo absent: 360e9b55dbe2bc28991d91c70377ec8ccd885ea7 Debuginfo absent: 3833c2a579f057bb859a8e954167eca75e0de6b6 Debuginfo absent: 3871edc037d3c657488adc1b5412e6f0575c973c Debuginfo absent: 39d0599c44a3330d3e0feb466bda73256acb46fa Debuginfo absent: 39ea914bbf6e8cd106c45fc84c7c318520f75ad9 Debuginfo absent: 3b58fe3361986b948b8f2e67c52894014ab81aeb Debuginfo absent: 3d57253169cd92a592a9e9d142f5c4ec7758b446 Debuginfo absent: 447c85bc6ed60cdf8b67dd0bb911b873b1bf5831 Debuginfo absent: 44fff6ff9994506a4f2321aa4edfb06c0879e7fb Debuginfo absent: 493299b14aee2974de72aaa32167c8ba8d9a3b45 Debuginfo absent: 49570b839e1c81aa23a1f67853a580ae15b6f6d2 Debuginfo absent: 4a41b45333067dc9d6f6aac6b6425ec8c58f1473 Debuginfo absent: 4aae34e6b63bccae0ca874e5901563c094020b47 Debuginfo absent: 4bf617ba297eaa743836031bf227f0c3cd9c5749 Debuginfo absent: 4ca9769d208e496e4eb855339fbfad8ef46b79e0 Debuginfo absent: 4d891f47399896f1e982c94c9b3017c5b71ba6a6 Debuginfo absent: 4dd7e58ead89156c9745fd4a575dcc27e348ad42 Debuginfo absent: 4ea3cc3f38faaf8821fc7361f45add896e94be7f Debuginfo absent: 4eaf27c1985602052fc2054c04d76564758777cf Debuginfo absent: 53c91d5c59eef4ff5fd29be9f88db3252aa02e37 Debuginfo absent: 53ea712d27c8a4401e32c0f8078da7774bb434d5 Debuginfo absent: 566d91601782324bd8ca0c2bb1cd5578016376d3 Debuginfo absent: 56e7c2c5b3daebd2e16652298cd16e82afcb4411 Debuginfo absent: 585cacadadae2413253c56b9cd900dd20fd9f628 Debuginfo absent: 5f06b38be49ad5b1a9905159a63426c05e719bd1 Debuginfo absent: 698410ac6c42e852bf4fca9bcbedbb17ded50707 Debuginfo absent: 6a37ce62c96cf5cb58256c90a57b0d0716c3571f Debuginfo absent: 72dcfe6feb090980a905966e2c2b443d4ce16570 Debuginfo absent: 72f64ad9b6d79fab13189b7de92252bc9c4f47a2 Debuginfo absent: 7b6bdc37b61b6eca81b25a64d9f110008a1a2913 Debuginfo absent: 7be1bd5c25732bcf16acc9fbeab2ef6e0acea88f Debuginfo absent: 7d6adb4652e7c95e3e87758ecd3bac46a79f5781 Debuginfo absent: 803dcf446ddfca6bc21d0080afa1ecdbee109365 Debuginfo absent: 833cefc956955eb38c7480f97484af29170870c0 Debuginfo absent: 84f5d6af10e941cc566d4dfee3275f0dc7772dee Debuginfo absent: 8514f084a1026b039c77ecf8e52d1f2d00e21e5f Debuginfo absent: 854b43661b864b677eb6726609fcdfeb78536d15 Debuginfo absent: 8981a35be6b02de75b5f1bcd5b0871ff85ba6eb1 Debuginfo absent: 89ddce98f457cf0206c3df0e3c8d9ed3f2088b34 Debuginfo absent: 8a19166ca2e8042e7130cbe507dd33d6d03e5fca Debuginfo absent: 8aa2d4a3559a9d8411927ff1659682c390149aa0 Debuginfo absent: 8d50e6f99af6d8c6e8750995a618b479f8716508 Debuginfo absent: 91158a001773ed732a6bfc8859dc935d97eed2f0 Debuginfo absent: 9239eaaf595f82fcc2b59bdb491cbab174f6ab4c Debuginfo absent: 980679b6bdedffd505f75a000da9e8772d90dd16 Debuginfo absent: 98238fa6c859c77073b285cd52976f8ea341097c Debuginfo absent: 9c823ec9bfe31a1ed1b2a88213d9797113f74ec0 Debuginfo absent: a150dc301065d9027302b4dcb62c665c6c6d8829 Debuginfo absent: a244f90a262e0069120df73d8b97a3b6ddb6a3b8 Debuginfo absent: a3732532c5f5edecfb4bfac37893431f74a518ae Debuginfo absent: a5e465990cbff18a8adf56d59fb45b72ab090714 Debuginfo absent: aa1edb076ddfb1f5a96308a6f73a375acfaf1c72 Debuginfo absent: ab03d46dea6fa701571a22f3944715788064b41c Debuginfo absent: ac19cea9410a15efc67ffdf89d9a5111349bb57b Debuginfo absent: ac27405845153e582587e8eccb596a6f25a01daa Debuginfo absent: af0add81509b4e35970dfae65d9187762e0e5e44 Debuginfo absent: b00a4547b125ec7fc5983247b6065cf70b173be9 Debuginfo absent: b0e5e00c8117beb1e19b32a8f8a584ddd9a6491d Debuginfo absent: b212433d6a1b297da241e4942419149bbc01cafd Debuginfo absent: b4349180465743c4555f8e24437c4ab5d25b3f78 Debuginfo absent: be76f9e2ecac6f6c8a0e925e71fa1d3057f127fe Debuginfo absent: c9dae628809e61c856c6b1d8417d52d0ff957b5d Debuginfo absent: ccca7b7752e98f6ddc3a8302ec897d1f230f325a Debuginfo absent: d1008f0daeb3e025567c535ce411b7b666047c80 Debuginfo absent: d10e4b7006f478c480f711bd264c8db820546a53 Debuginfo absent: d3a4a4f4202345cfb81c47afc4f5eef707f660a4 Debuginfo absent: d3ed02b9d190bf5ac5476897806e531a28cd5f52 Debuginfo absent: d420b3ac9d4f138e2b9813db10bd568174f9d9e4 Debuginfo absent: da39f91b65bdd00b6bf2290ffdd90e93ed76885a Debuginfo absent: dad0d5881afb24f116605c2ebe5f42861aa454a1 Debuginfo absent: db2f3912f9316dffe0c572f1fa4b471a1a077b38 Debuginfo absent: db688579022abc43a2e27c1e850a08ace452adf8 Debuginfo absent: dcb18b1be38a6eb757e064b63dac6db24d0f6850 Debuginfo absent: dd25bde637b0f8963724bcabb962baf74e7360d7 Debuginfo absent: dd4567e40d4c5967e2156aaf8d0ba8208f4daef2 Debuginfo absent: de454c0a26adc89b069df877046148971cc97983 Debuginfo absent: deb312a7cb499731779149c9aeb9b16416e2034a Debuginfo absent: dec477b7e69e33e81e76aa8f2201a07ec8186973 Debuginfo absent: df5dd7f20306816336f9d0f2cfc477f74a9fdb41 Debuginfo absent: e072877b59522a02303cab26412f83dba4e82753 Debuginfo absent: e11c2b1cbbececd0c4bfd0d6397074a341b503f6 Debuginfo absent: e4076b8a7e979a29269b005ec846a3176153eab2 Debuginfo absent: e4348ff2068b1b03263454f4d80bd4ac7068b1b3 Debuginfo absent: eb7c12ab3beeaf7bdbb5e9f479405fdb5cec6c70 Debuginfo absent: ee92a12ce1a6f36705b9b01dc3bf9ff3098a33e3 Debuginfo absent: eef2645df179a6eeaefc243aad5c223cc8524ff5 Debuginfo absent: ef2dc4c8a43bf476b4866adad4df4c421c5f9e14 Debuginfo absent: f403dff3727cbe36c323a3ce959b35f829dff9e0 Debuginfo absent: f977d45a4ab80ec37972bf0777e8bd7064441be3 Debuginfo absent: fbedf91fea5ffa5772f83a83d7a132c0f81939d2 Debuginfo absent: fe4ff4c8d2523eed5275a2c2e311a191905bbc6d Debuginfo absent: ff0c67b4f33aac0cc43f9b704ea8c26ef2545fc7
Miroslav could you back port the F14 chrome-sandbox policy to F12/F13
Fixed in selinux-policy-3.6.32-123.fc12
selinux-policy-3.6.32-123.fc12 has been submitted as an update for Fedora 12. https://admin.fedoraproject.org/updates/selinux-policy-3.6.32-123.fc12
selinux-policy-3.6.32-123.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update selinux-policy'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/selinux-policy-3.6.32-123.fc12
selinux-policy-3.6.32-123.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.