SELinux is preventing nacl_helper_boo from 'execute' accesses on the file /opt/google/chrome/nacl_helper_bootstrap. ***** Plugin catchall_labels (83.8 confidence) suggests ******************** If you want to allow nacl_helper_boo to have execute access on the nacl_helper_bootstrap file Then you need to change the label on /opt/google/chrome/nacl_helper_bootstrap Do # semanage fcontext -a -t FILE_TYPE '/opt/google/chrome/nacl_helper_bootstrap' where FILE_TYPE is one of the following: textrel_shlib_t, execmem_exec_t, lib_t, chrome_sandbox_exec_t, bin_t, abrt_helper_exec_t, ld_so_t. Then execute: restorecon -v '/opt/google/chrome/nacl_helper_bootstrap' ***** Plugin catchall (17.1 confidence) suggests *************************** If you believe that nacl_helper_boo should be allowed execute access on the nacl_helper_bootstrap 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 nacl_helper_boo /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context unconfined_u:unconfined_r:chrome_sandbox_t:s0 Target Context system_u:object_r:usr_t:s0 Target Objects /opt/google/chrome/nacl_helper_bootstrap [ file ] Source nacl_helper_boo Source Path nacl_helper_boo Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages google-chrome-unstable-16.0.891.0-102650 Policy RPM selinux-policy-3.9.16-38.fc15 Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name (removed) Platform Linux (removed) 2.6.40.4-5.fc15.x86_64 #1 SMP Tue Aug 30 14:38:32 UTC 2011 x86_64 x86_64 Alert Count 1 First Seen Tue 04 Oct 2011 06:30:55 PM MSK Last Seen Tue 04 Oct 2011 06:30:55 PM MSK Local ID d8e9989a-b060-4e6a-8411-4d130e5a5f93 Raw Audit Messages type=AVC msg=audit(1317742255.250:61): avc: denied { execute } for pid=6412 comm="chrome" name="nacl_helper_bootstrap" dev=dm-3 ino=183389 scontext=unconfined_u:unconfined_r:chrome_sandbox_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=file type=AVC msg=audit(1317742255.250:61): avc: denied { execute_no_trans } for pid=6412 comm="chrome" path="/opt/google/chrome/nacl_helper_bootstrap" dev=dm-3 ino=183389 scontext=unconfined_u:unconfined_r:chrome_sandbox_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=file type=AVC msg=audit(1317742255.250:61): avc: denied { mmap_zero } for pid=6412 comm="nacl_helper_boo" scontext=unconfined_u:unconfined_r:chrome_sandbox_t:s0 tcontext=unconfined_u:unconfined_r:chrome_sandbox_t:s0 tclass=memprotect type=SYSCALL msg=audit(1317742255.250:61): arch=x86_64 syscall=execve success=no exit=EPERM a0=7f39b10b06a8 a1=7f39b10e4a40 a2=7fff548452e0 a3=7fff548424e0 items=0 ppid=1 pid=6412 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm=nacl_helper_boo subj=unconfined_u:unconfined_r:chrome_sandbox_t:s0 key=(null) Hash: nacl_helper_boo,chrome_sandbox_t,usr_t,file,execute audit2allow #============= chrome_sandbox_t ============== allow chrome_sandbox_t self:memprotect mmap_zero; allow chrome_sandbox_t usr_t:file { execute execute_no_trans }; audit2allow -R #============= chrome_sandbox_t ============== allow chrome_sandbox_t self:memprotect mmap_zero; allow chrome_sandbox_t usr_t:file { execute execute_no_trans };
This is not something we will allow. mmap_zero is very dangerous, Please report to google. allow chrome_sandbox_t usr_t:file { execute execute_no_trans }; is fixed in selinux-policy-3.9.16-43.fc15
nacl_helper_bootstrap does not need mmap_zero. It simply attempts to reserve the lowest available portion of the address space. Its phdrs reserve the space starting at 0x10000, since some systems might be configured with sysctl -w vm.mmap_min_addr=0x10000 and we don't want the exec to fail as that is not recoverable. It then does an explicit mmap for the pages below 0x10000. Since some systems might be configured with sysctl -w vm.mmap_min_addr=0, it starts at zero and moves up a page at a time on failure. Is there a way to configure setroubleshootd or whatever it is so that it just suppresses complaints about certain failures? We could conceivably make nacl_helper attempt to read vm.mmap_min_addr and only start from that value. But it's more robust across a variety of systems and configurations to simply start at zero and move up a page until it works (or until we hit the static reservation at 0x10000 without any lower mapping having worked).
I don't like hiding it, but if this program really needs to first usable page there isn't another way. vm.mmap_min_addr only works for the protections controlled by CAP_SYS_RAWIO. There is a separate kernel build time selection of the mmap_min_addr as enforced by SELinux. I guess in this case vm.mmap_min_addr < the kernel LSM build min addr else you should have been silently denied by DAC. I'd rather not dontaudit the potential CAP_SYS_RAWIO we would get if you ran as root. However, Miroslav, I guess our only choice is to dontaudit the mmap_zero, since there is no reason people can't run with different build time and run time options....
I hadn't noticed CONFIG_LSM_MMAP_MIN_ADDR and assumed this was testing against vm.mmap_min_addr. Since there isn't any reasonable way to find out this setting at all, I guess that settles it. I was considering the possibility of discovering vm.mmap_min_addr and not trying pages below that, but that would be onerous to arrange underneath the sandboxing layers and IMHO it's just less robust to use complex logic like that rather than the current simple-minded "fail and move up a page until we're sure we either failed or reserved all the pages". The NaCl security model requires that we ensure that the entire address space below 1G is reserved so no "anywhere" mmap's can possibly land there. We can't do this "properly" (i.e. statically in the ELF headers of nacl_helper_bootstrap) for the region below 64k, since vm.mmap_min_addr or LSM might not permit the exec to succeed at all. So we bank on the vDSO not having appeared there (on a system with min_addr constraints that might allow that), and then reserve it manually with a MAP_FIXED mmap.
I guess this is where we come in again and ask if chrome_sandbox can be split into two apps, one to setup the sandbox and the other to actually run the sandboxed code. That way we could give better access to the setup code and less access to the actuall sandboxed code, from an SELinux point of view.
Added dontaudit in selinux-policy-3.10.0-40.fc16
I'm not really the person to answer about chrome_sandbox. But AIUI, one of the key features of the sandbox is that it cannot exec. So I suspect the split you have in mind is not feasible.
Well this specific denial is from a program labeled chrome_sandbox_t (comm=chrome) exec'ing /opt/google/chrome/nacl_helper_bootstrap. Its during the exec syscall that we are getting this mmap zero, not during an explicit mmap request. Given that fact, maybe we could transition nacl_helper_bootstrap to it's own domain that does not audit mmap_zero while leaving chrome_sandbox_t without such rules?
It's in the exec? That seems odd. It's at ET_EXEC with its lowest p_vaddr at 0x10000. Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x000000 0x0000000000010000 0x0000000000010000 0x000ff8 0x000ff8 R E 0x1000 LOAD 0x000ff8 0x0000000000210ff8 0x0000000000210ff8 0x000000 0x000004 RW 0x1000 LOAD 0x001000 0x0000000000211000 0x0000000000211000 0x3fdef000 0x3fdef000 0x1000 NOTE 0x000158 0x0000000000010158 0x0000000000010158 0x000024 0x000024 R 0x4 GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW 0x8 Yes, the third PT_LOAD is bizarre, and yes, that's how it's supposed to be.
Definitely during exec see the part of the audit log: type=SYSCALL msg=audit(1317742255.250:61): arch=x86_64 syscall=execve success=no exit=EPERM ...... Is it possible that something set the MMAP_PAGE_ZERO personality flag? aka PER_SVR4 or PER_UW7 ?
I don't really know how to read the audit log, and I don't have a Fedora system handy right now to reproduce the situation and investigate. I thought there were two problems: first, it's denying the exec altogether due to the labels and such. But I was assuming that this was a "permissive" denial so that the exec actually took place and then the mmap_zero complaints were separate. I don't know anything that would explain an mmap_zero being part of the exec. I can investigate further.
It turns out that in Chrome 15 for x86-64, nacl_helper_bootstrap is a completely botched binary that indeed has a PT_LOAD at zero. In Chrome 16 it is correct, and in Chrome 15 for x86-32 it is correct.
Does that mean we can remove the mmap_zero cruft?
It means it's less likely, but not impossible. I say we remove the dontaudits and readdress if find people regularly having trouble....
(In reply to comment #13) > Does that mean we can remove the mmap_zero cruft? Nope. Try the 32-bit version from Chrome 15 (beta) to see what it needs. Once the exec actually works and it runs the real thing, that will attempt mmap's for the range [0,0x10000), moving up a page from 0 until it works or until it gets to 0x10000. Note that those are mmap's with PROT_NONE, whose whole purpose is just to absolutely ensure that no random mmap can ever deliver any page below 0x10000. So another possible tack on this would be to change the kernel checks not to do the MMAP_ZERO avc when mapping with PROT_NONE, which of course also requires that mprotect to non-PROT_NONE start doing an MMAP_ZERO avc.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Is this still a problem with 3.9 based F19 kernels?
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 2 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.