Bug 790980

Summary: Google Chrome has problems with SELinux rules when home directory is in NFS
Product: Red Hat Enterprise Linux 6 Reporter: Jonathan Billings <jsbillin>
Component: selinux-policyAssignee: Miroslav Grepl <mgrepl>
Status: CLOSED ERRATA QA Contact: Milos Malik <mmalik>
Severity: low Docs Contact:
Priority: unspecified    
Version: 6.2CC: dwalsh, mmalik
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: selinux-policy-3.7.19-137.el6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-06-20 12:31:27 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jonathan Billings 2012-02-15 21:05:27 UTC
Description of problem:

My Home directory is in AFS, but this also occurs with NFS home directories.  Both are labled as nfs_t mountpoints.

I'm using the latest stable release of google-chrome, and when I visit my Google Calendar page (https://www.google.com/calendar/) after signing in, it first starts to render then I get the 'Aw snap' internal error page.  If I set SELinux to permissive, it works, but I didn't see any logs in the audit log.  If I temporary remove dontaudits with 'semodule -DB', I see this in the audit log:

type=AVC msg=audit(1329336848.285:127497): avc:  denied  { write } for  pid=5347 comm="chrome" path="/afs/umich.edu/user/j/s/jsbillin/.config/google-chrome/Default/databases/https_www.google.com_0/1" dev=afs ino=665341522 scontext=unconfined_u:unconfined_r:chrome_sandbox_t:s0-s0:c0.c1023 tcontext=system_u:object_r:nfs_t:s0 tclass=file

When I create and load a policy module that allows:

#============= chrome_sandbox_t ==============
allow chrome_sandbox_t nfs_t:file write;

... google does not get an 'Aw snap' error page when I visit the Google Calendar page.


Version-Release number of selected component (if applicable):
google-chrome-stable-17.0.963.46-119351.x86_64
selinux-policy-3.7.19-126.el6_2.6.noarch

How reproducible:
Always

Steps to Reproduce:
1. Have a NFS or AFS home directory
2. Install google chrome
3. Go to https://www.google.com/calendar/ in chrome, sign in with google account.
  
Actual results:
The chrome 'Aw snap' error page

Expected results:
A working web session.

Additional info:
This problem doesn't occur in Fedora 16.  I spoke with Dan Walsh in the #fedora-selinux IRC channel, and he indicated that it was part of the selinux-policy in recent Fedora releases as part of the use_nfs_home_dirs SEboolean, but it wasn't in RHEL6.2.

Comparing the output of "sesearch -A -C |grep use_nfs_home_dirs |grep chrome", I can see that RHEL6.2 has

ET allow chrome_sandbox_t nfs_t : file { ioctl read getattr lock } ; [ use_nfs_home_dirs ]

while Fedora 16 has:

ET allow chrome_sandbox_t nfs_t : file { ioctl read write getattr lock append execute execute_no_trans open } ; [ use_nfs_home_dirs ]

Comment 2 Miroslav Grepl 2012-02-16 09:44:22 UTC
Fixed in selinux-policy-3.7.19-137.el6

Comment 8 errata-xmlrpc 2012-06-20 12:31:27 UTC
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-2012-0780.html