Chromium opens a database file within your profile directory and passes that file handle to the sandboxed renderer process. Something in SELinux appears to prevent that handle from being passed. This currently causes a crash on some websites, including twitter.com. We can fix Chromium to try to not crash, but we should also fix the SELinux policy to allow this file-handle-passing to not break the feature. Bug in the Chromium tracker: http://code.google.com/p/chromium/issues/detail?id=81413 It also contains SELinux auditing logs. Discussion on the Fedora forums: http://forums.fedoraforum.org/showthread.php?t=262432 Users are reporting these workarounds: - turn off selinux - run chrome as root - restorecon -R ~/.config I know the first two workarounds are bad; I don't understand the last one.
The last one isn't really a workaround, but an actual fix. If SELinux labels on the files in ~/.config are wrong, then the policy can easily deny otherwise correct and valid operations. This can happen for a variety of reasons. restorecon will reset labels to their defaults and correct the problem. New installs of Fedora should not see this issue, nor should properly upgraded ones (because I think restorecon is run). This issue can occur when a .config (or home directory, or whatever) is created somewhere else and then moved. mv doesn't change the SELinux labels. cp -a will also preserve (possibly wrong) labels as well, I think. The issue of labeling is one of the more brittle aspects of SELinux. setroubleshoot is supposed to automatically detect these kinds of issues and inform the user how to correct them (via restorecon or other means), or file a bug. The question is: why did setroubleshoot fail in this case? You can probably set the labels to something else to reproduce this. Let me follow up with how to try that.
It's easy to make dev Chrome crash on startup: chcon -Rv unconfined_u:object_r:user_home_dir_t:s0 ~/.config/google-chrome This basically locks the files from the sandbox. Indeed, setroubleshoot alerts me and tells me to restorecon (or file a bug): SELinux is preventing chrome from read access on the file /home/agoode/.config/google-chrome/Safe Browsing Phishing Model v1. ***** Plugin restorecon (99.5 confidence) suggests ************************* If you want to fix the label. /home/agoode/.config/google-chrome/Safe Browsing Phishing Model v1 default label should be config_home_t. Then you can run restorecon. Do # /sbin/restorecon -v /home/agoode/.config/google-chrome/Safe Browsing Phishing Model v1 ***** Plugin catchall (1.49 confidence) suggests *************************** If you believe that chrome should be allowed read access on the Safe Browsing Phishing Model v1 file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep chrome /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context unconfined_u:unconfined_r:chrome_sandbox_t:s0-s0:c 0.c1023 Target Context unconfined_u:object_r:user_home_dir_t:s0 Target Objects /home/agoode/.config/google-chrome/Safe Browsing Phishing Model v1 [ file ] Source chrome Source Path chrome Port <Unknown> Host datatype Source RPM Packages google-chrome-unstable-13.0.782.1-87465 Target RPM Packages Policy RPM selinux-policy-3.9.16-24.fc15 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name datatype Platform Linux datatype 2.6.38.6-27.fc15.x86_64 #1 SMP Sun May 15 17:23:28 UTC 2011 x86_64 x86_64 Alert Count 16 First Seen Thu 02 Jun 2011 11:19:37 PM EDT Last Seen Thu 02 Jun 2011 11:19:48 PM EDT Local ID 2f3117d0-5b17-433c-993d-7d17d5b9617b Raw Audit Messages type=AVC msg=audit(1307071188.432:1150): avc: denied { read } for pid=6064 comm="chrome" path=2F686F6D652F61676F6F64652F2E636F6E6669672F676F6F676C652D6368726F6D652F536166652042726F7773696E67205068697368696E67204D6F64656C207631 dev=dm-3 ino=18105747 scontext=unconfined_u:unconfined_r:chrome_sandbox_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_dir_t:s0 tclass=file type=SYSCALL msg=audit(1307071188.432:1150): arch=x86_64 syscall=recvmsg success=yes exit=EPERM a0=15 a1=7fc781f9ae60 a2=40 a3=7fffffff items=0 ppid=1 pid=6064 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=pts3 ses=1 comm=chrome exe=/opt/google/chrome/chrome subj=unconfined_u:unconfined_r:chrome_sandbox_t:s0-s0:c0.c1023 key=(null) Hash: chrome,chrome_sandbox_t,user_home_dir_t,file,read audit2allow #============= chrome_sandbox_t ============== allow chrome_sandbox_t user_home_dir_t:file read; audit2allow -R #============= chrome_sandbox_t ============== allow chrome_sandbox_t user_home_dir_t:file read;
There was a bug in Fedora 15 where policycoreutils-restorecond was not installed in a default installation. This caused that user home directory contexts turned out mislabelled. Most of the time one does not notice this because many apps run as the user (which is unrestricted). Some apps like chrome however are protected/restricted and so they ended up broken. Same goes for system services that need to be able to access files in the user home space. In Fedora 16 we implemented a new way of dealing with that and so this issue will probably no longer be there in Fedora 16. So the fix is to tell people to install policycoreutils-restorecond, then to relogin to the session and then run restorecon -R -v ~
Yes, you need to execute # restorecon -R -v /home at least.
Do you have any suggestion about what we can do for our users? (I'm not sure how the Fedora community works -- is it expected that users will be able to dig up this bug and run that command? Or should we add code to detect Fedora and instruct users "go run sudo foobar if your browser stops working"?) See e.g. http://rhecizen.web.id/mengakses-twitter-melalui-chromium-fedora/ http://twitter.com/#!/harishpillay/statuses/76316071744901120 http://twitter.com/#!/jrothwell/statuses/76778649516384256
I commented here: bug #701066.
Besides this restorecon bug there is another issue that i have been trying to put in the spot light. unconfined'users should not be confined in anyway. So chromium in my view should not have been restricted for unconfined users in the first place. Granted that this still would not be a solution to issue described obove since targeted system services sometimes also need access to the user home space (for example httpd, mail, no colord and dbus etc. But still confining apps like chrome for unconfined users is risky. Unconfined users usually are not familiar with SELinux or they do not care about it or about security, and so they will have a hard time troubleshooting/fixing the issue themselves. Its a pity though because this class of users are probably the most vulnerable. http://danwalsh.livejournal.com/30084.html?thread=211844
I just added a boolean for uncofined_t in Rawhide. unconfined_chrome_sandbox_transition defaulted to false.
I'm reopening this for now, there are at least 2 bugs that are blocking a good resolution. (restorecond stuff)
*** Bug 725048 has been marked as a duplicate of this bug. ***
I ran into this problem just now, my .config was ancient and visiting twitter would cause Chrome to malfunction. restorecon -R ~/.config cured the problem.