Description of problem: 99% of the time that mls_compute_sid is called on my system, it's from shmem_file_setup creating Radeon GEM objects. At the minimum, shmem_file_setup needs a flag to create private inodes. The only other user of shmem_file_setup besides DRM is IPC, which already has it's own SELinux enforcement interface. Perhaps shmem_file_setup can unconditionally make all the inodes it creates private. # 4.56% Xorg [kernel] [k] mls_compute_sid # | # |--99.88%-- security_compute_sid # | security_transition_sid # | inode_doinit_with_dentry # | selinux_d_instantiate # | security_d_instantiate # | d_instantiate # | shmem_file_setup # | drm_gem_object_alloc [drm] # | radeon_gem_object_create [radeon] # | radeon_gem_create_ioctl [radeon] # | drm_ioctl [drm] # | vfs_ioctl # | do_vfs_ioctl # | sys_ioctl # | system_call_fastpath # | __GI_ioctl # --0.12%-- [...]
Created attachment 378857 [details] annotated mls_compute_sid
KERNEL: /usr/lib/debug/lib/modules/2.6.31.6-166.fc12.x86_64/vmlinux DUMPFILE: /dev/crash CPUS: 2 DATE: Wed Dec 16 14:11:41 2009 UPTIME: 4 days, 19:39:46 LOAD AVERAGE: 0.19, 0.13, 0.08 TASKS: 256 NODENAME: entropy RELEASE: 2.6.31.6-166.fc12.x86_64 VERSION: #1 SMP Wed Dec 9 10:46:22 EST 2009 MACHINE: x86_64 (2004 Mhz) MEMORY: 2 GB PID: 29566 COMMAND: "crash" TASK: ffff88007b449780 [THREAD_INFO: ffff88005641e000] CPU: 1 STATE: TASK_RUNNING (ACTIVE) crash> print policydb.range_tr $8 = (struct range_trans *) 0xffff880049d96d80 crash> list range_trans.next 0xffff880049d96d80 | wc -l 1821 crash> 1821 entries seems high for a linear search.
This seems to be specific to the Fedora policy. The upstream refpolicy has only around 31 range_transition rules. We could of course replace the simple list with a hashtab, but it would be useful to know why there are so many range_transition rules in Fedora policy.
init_domtrans_script has a range_transition in it. init_domtrans_script(system_dbusd_t) init_domtrans_script(ricci_modcluster_t) init_domtrans_script(ricci_modservice_t) init_domtrans_script(NetworkManager_t) init_domtrans_script(system_crond_t) init_domtrans_script(apmd_t) init_domtrans_script(hald_t) interface(`init_domtrans_script',` init_domtrans_script(init_t) init_domtrans_script(hotplug_t) init_domtrans_script(unconfined_t) init_domtrans_script(dpkg_t) init_domtrans_script(dpkg_script_t) init_domtrans_script(logrotate_t) init_domtrans_script(firstboot_t) init_domtrans_script(rpm_t) init_domtrans_script(rpm_script_t) init_domtrans_script(anaconda_t) And the range_transition uses the attribute initscript rather then initrc_t So you end up with range_transition unconfined_t rpcbind_initrc_exec_t : process s0; range_transition unconfined_t iptables_initrc_exec_t : process s0; range_transition unconfined_t setrans_initrc_exec_t : process s0; range_transition unconfined_t zabbix_initrc_exec_t : process s0; range_transition unconfined_t sssd_initrc_exec_t : process s0; range_transition unconfined_t fail2ban_initrc_exec_t : process s0; range_transition unconfined_t memcached_initrc_exec_t : process s0; range_transition unconfined_t nslcd_initrc_exec_t : process s0; range_transition unconfined_t rpcd_initrc_exec_t : process s0; range_transition unconfined_t rwho_initrc_exec_t : process s0; Maybe we could do some of the attribute expansion magic to prevent this?
Possible patch posted to selinux list. http://marc.info/?l=selinux&m=126289781004177&w=2
Should be fixed in 2.6.34, let me know if you still see issues....