From: Chris PeBenito <pebenito@ieee.org>
To: Russell Coker <russell@coker.com.au>,
"selinux-refpolicy@vger.kernel.org"
<selinux-refpolicy@vger.kernel.org>
Subject: Re: [PATCH] chromium
Date: Tue, 29 Jan 2019 18:53:54 -0500 [thread overview]
Message-ID: <743dd8f5-9288-8216-4551-b7a74fda3e6d@ieee.org> (raw)
In-Reply-To: <20190128084648.GA5441@xev>
On 1/28/19 3:46 AM, Russell Coker wrote:
> There are several nacl binaries that need labels.
>
> Put an ifdef debian for some chromium paths.
>
> Git policy misses chromium_role() lines, were they in another patch that was
> submitted at the same time?
>
> I don't know what this is for but doesn't seem harmful to allow it:
> type=PROCTITLE msg=audit(28/01/19 19:31:42.361:3218) : proctitle=/bin/bash /usr/bin/google-chrome
> type=SYSCALL msg=audit(28/01/19 19:31:42.361:3218) : arch=x86_64 syscall=openat success=yes exit=3 a0=0xffffff9c a1=0x563328f7b590 a2=O_WRONLY|O_CREAT|O_TRUNC a3=0x1b6 items=0 ppid=5158 pid=5166 auid=test uid=test gid=test euid=test suid=test fsuid=test egid=test sgid=test fsgid=test tty=pts7 ses=232 comm=google-chrome exe=/bin/bash subj=user_u:user_r:chromium_t:s0 key=(null)
> type=AVC msg=audit(28/01/19 19:31:42.361:3218) : avc: granted { associate } for pid=5166 comm=google-chrome name=63 scontext=user_u:object_r:chromium_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=filesystem
> type=AVC msg=audit(28/01/19 19:31:42.361:3218) : avc: granted { create } for pid=5166 comm=google-chrome name=63 scontext=user_u:user_r:chromium_t:s0 tcontext=user_u:object_r:chromium_t:s0 tclass=file
> type=AVC msg=audit(28/01/19 19:31:42.361:3218) : avc: granted { add_name } for pid=5166 comm=google-chrome name=63 scontext=user_u:user_r:chromium_t:s0 tcontext=user_u:user_r:chromium_t:s0 tclass=dir
>
> Allow domain_use_interactive_fds() for running via ssh -X.
>
> Allow managing xdg data, cache, and config.
>
> Allow reading public data from apt and dpkg, probably from lsb_release or some
> other shell script.
>
> How does the whold naclhelper thing work anyway? I'm nervous about process
> share access involving chromium_sandbox_t, is that really what we want?
>
> Added lots of other stuff like searching cgroup dirs etc.
>
>
> Index: refpolicy-2.20180701/policy/modules/apps/chromium.fc
> ===================================================================
> --- refpolicy-2.20180701.orig/policy/modules/apps/chromium.fc
> +++ refpolicy-2.20180701/policy/modules/apps/chromium.fc
> @@ -2,7 +2,7 @@
> /opt/google/chrome/chrome_sandbox -- gen_context(system_u:object_r:chromium_sandbox_exec_t,s0)
> /opt/google/chrome/chrome-sandbox -- gen_context(system_u:object_r:chromium_sandbox_exec_t,s0)
> /opt/google/chrome/google-chrome -- gen_context(system_u:object_r:chromium_exec_t,s0)
> -/opt/google/chrome/nacl_helper_bootstrap -- gen_context(system_u:object_r:chromium_naclhelper_exec_t,s0)
> +/opt/google/chrome/nacl_.* -- gen_context(system_u:object_r:chromium_naclhelper_exec_t,s0)
> /opt/google/chrome/libudev.so.0 gen_context(system_u:object_r:lib_t,s0)
>
> /opt/google/chrome-beta/chrome -- gen_context(system_u:object_r:chromium_exec_t,s0)
> @@ -19,9 +19,14 @@
> /opt/google/chrome-unstable/nacl_helper_bootstrap -- gen_context(system_u:object_r:chromium_naclhelper_exec_t,s0)
> /opt/google/chrome-unstable/libudev.so.0 gen_context(system_u:object_r:lib_t,s0)
>
> +ifdef(`distro_debian',`
> +/usr/lib/chromium/chromium -- gen_context(system_u:object_r:chromium_exec_t,s0)
> +/usr/lib/chromium/chrome-sandbox -- gen_context(system_u:object_r:chromium_sandbox_exec_t,s0)
> +', `
> /usr/lib/chromium-browser/chrome -- gen_context(system_u:object_r:chromium_exec_t,s0)
> /usr/lib/chromium-browser/chrome_sandbox -- gen_context(system_u:object_r:chromium_sandbox_exec_t,s0)
> /usr/lib/chromium-browser/chrome-sandbox -- gen_context(system_u:object_r:chromium_sandbox_exec_t,s0)
> +')
> /usr/lib/chromium-browser/chromium-launcher\.sh -- gen_context(system_u:object_r:chromium_exec_t,s0)
> /usr/lib/chromium-browser/nacl_helper_bootstrap -- gen_context(system_u:object_r:chromium_naclhelper_exec_t,s0)
>
> Index: refpolicy-2.20180701/policy/modules/roles/staff.te
> ===================================================================
> --- refpolicy-2.20180701.orig/policy/modules/roles/staff.te
> +++ refpolicy-2.20180701/policy/modules/roles/staff.te
> @@ -82,6 +82,10 @@ ifndef(`distro_redhat',`
> ')
>
> optional_policy(`
> + chromium_role(staff_r, staff_t)
> + ')
> +
> + optional_policy(`
> cron_role(staff_r, staff_t)
> ')
>
> Index: refpolicy-2.20180701/policy/modules/roles/sysadm.te
> ===================================================================
> --- refpolicy-2.20180701.orig/policy/modules/roles/sysadm.te
> +++ refpolicy-2.20180701/policy/modules/roles/sysadm.te
> @@ -1272,6 +1272,10 @@ ifndef(`distro_redhat',`
> ')
>
> optional_policy(`
> + chromium_role(sysadm_r, sysadm_t)
> + ')
> +
> + optional_policy(`
> cron_admin_role(sysadm_r, sysadm_t)
> ')
>
> Index: refpolicy-2.20180701/policy/modules/roles/unprivuser.te
> ===================================================================
> --- refpolicy-2.20180701.orig/policy/modules/roles/unprivuser.te
> +++ refpolicy-2.20180701/policy/modules/roles/unprivuser.te
> @@ -50,6 +50,10 @@ ifndef(`distro_redhat',`
> ')
>
> optional_policy(`
> + chromium_role(user_r, user_t)
> + ')
> +
> + optional_policy(`
> cron_role(user_r, user_t)
> ')
>
> Index: refpolicy-2.20180701/policy/modules/apps/chromium.te
> ===================================================================
> --- refpolicy-2.20180701.orig/policy/modules/apps/chromium.te
> +++ refpolicy-2.20180701/policy/modules/apps/chromium.te
> @@ -78,6 +78,8 @@ xdg_cache_content(chromium_xdg_cache_t)
>
> # execmem for load in plugins
> allow chromium_t self:process { execmem getsched getcap setcap setrlimit setsched sigkill signal };
> +allow chromium_t self:dir { write add_name };
> +allow chromium_t self:file create;
I dropped this and the related proc_t associate. I would like to have a
better understanding what is happening. The domain type on
file/dir/lnk_file is supposed to be exclusively for the the /proc/pid
entries. The domain shouldn't be creating files with this type. The
fact that it is creating it in proc is even weirder.
> allow chromium_t self:fifo_file rw_fifo_file_perms;
> allow chromium_t self:sem create_sem_perms;
> allow chromium_t self:netlink_kobject_uevent_socket client_stream_socket_perms;
> @@ -94,11 +96,14 @@ allow chromium_t chromium_renderer_t:shm
> allow chromium_t chromium_renderer_t:unix_dgram_socket { read write };
> allow chromium_t chromium_renderer_t:unix_stream_socket { read write };
>
> -allow chromium_t chromium_sandbox_t:unix_dgram_socket { read write };
> -allow chromium_t chromium_sandbox_t:unix_stream_socket { read write };
> +allow chromium_t chromium_sandbox_t:unix_dgram_socket { getattr read write };
> +allow chromium_t chromium_sandbox_t:unix_stream_socket { getattr read write };
>
> allow chromium_t chromium_naclhelper_t:process { share };
>
> +# for self:file create
> +kernel_associate_proc(chromium_t)
> +
> # tmp has a wide class access (used for plugins)
> manage_files_pattern(chromium_t, chromium_tmp_t, chromium_tmp_t)
> allow chromium_t chromium_tmp_t:file map;
> @@ -149,6 +154,7 @@ dev_rw_xserver_misc(chromium_t)
> dev_map_xserver_misc(chromium_t)
>
> domain_dontaudit_search_all_domains_state(chromium_t)
> +domain_use_interactive_fds(chromium_t)
>
> files_list_home(chromium_t)
> files_search_home(chromium_t)
> @@ -159,12 +165,17 @@ files_read_etc_files(chromium_t)
> files_dontaudit_getattr_all_dirs(chromium_t)
>
> fs_dontaudit_getattr_xattr_fs(chromium_t)
> +fs_getattr_tmpfs(chromium_t)
> +fs_search_cgroup_dirs(chromium_t)
>
> miscfiles_read_all_certs(chromium_t)
> miscfiles_read_localization(chromium_t)
>
> sysnet_dns_name_resolve(chromium_t)
>
> +# for /run/udev/data/*
> +udev_read_pid_files(chromium_t)
> +
> userdom_user_content_access_template(chromium, chromium_t)
> userdom_dontaudit_list_user_home_dirs(chromium_t)
> # Debugging. Also on user_tty_device_t if X is started through "startx" for instance
> @@ -172,12 +183,10 @@ userdom_use_user_terminals(chromium_t)
> userdom_manage_user_certs(chromium_t)
> userdom_user_home_dir_filetrans_user_cert(chromium_t, dir, ".pki")
>
> -xdg_create_cache_dirs(chromium_t)
> -xdg_create_config_dirs(chromium_t)
> -xdg_create_data_dirs(chromium_t)
> +xdg_manage_cache(chromium_t)
> +xdg_manage_config(chromium_t)
> +xdg_manage_data(chromium_t)
It seems like it might be best to have chromium-specific
cache/data/config if it is modifying them.
> xdg_manage_downloads(chromium_t)
> -xdg_read_config_files(chromium_t)
> -xdg_read_data_files(chromium_t)
>
> xserver_user_x_domain_template(chromium, chromium_t, chromium_tmpfs_t)
>
> @@ -195,6 +204,8 @@ tunable_policy(`chromium_rw_usb_dev',`
> tunable_policy(`chromium_read_system_info',`
> kernel_read_kernel_sysctls(chromium_t)
> # Memory optimizations & optimizations based on OS/version
> + kernel_read_crypto_sysctls(chromium_t)
> + kernel_read_kernel_sysctls(chromium_t)
> kernel_read_system_state(chromium_t)
>
> # Debugging (sys/kernel/debug) and device information (sys/bus and sys/devices).
> @@ -237,6 +248,13 @@ optional_policy(`
> ')
> ')
>
> +optional_policy(`
> + apt_read_cache(chromium_t)
> + apt_read_db(chromium_t)
> + dpkg_exec(chromium_t)
> + dpkg_read_db(chromium_t)
> +')
> +
> ifdef(`use_alsa',`
> optional_policy(`
> alsa_domain(chromium_t, chromium_tmpfs_t)
> @@ -309,23 +327,27 @@ allow chromium_sandbox_t chromium_t:dir
> allow chromium_sandbox_t chromium_t:lnk_file read_lnk_file_perms;
> allow chromium_sandbox_t chromium_t:file rw_file_perms;
>
> -allow chromium_sandbox_t chromium_t:unix_stream_socket { read write };
> -allow chromium_sandbox_t chromium_t:unix_dgram_socket { read write };
> +allow chromium_sandbox_t chromium_t:unix_stream_socket { getattr read write };
> +allow chromium_sandbox_t chromium_t:unix_dgram_socket { getattr read write };
>
> kernel_list_proc(chromium_sandbox_t)
>
> domain_dontaudit_read_all_domains_state(chromium_sandbox_t)
> +domain_use_interactive_fds(chromium_sandbox_t)
>
> userdom_use_user_ptys(chromium_sandbox_t)
>
> chromium_domtrans(chromium_sandbox_t)
> +domtrans_pattern(chromium_sandbox_t, chromium_naclhelper_exec_t, chromium_naclhelper_t)
> +allow chromium_sandbox_t chromium_naclhelper_t:process share;
>
> ##########################################
> #
> # Chromium nacl helper local policy
> #
>
> -allow chromium_naclhelper_t chromium_t:unix_stream_socket { read write };
> +allow chromium_naclhelper_t chromium_t:unix_stream_socket { getattr read write };
> +allow chromium_naclhelper_t chromium_sandbox_t:unix_stream_socket { getattr read write };
>
> domain_mmap_low_uncond(chromium_naclhelper_t)
>
> @@ -338,3 +360,6 @@ tunable_policy(`chromium_read_system_inf
> kernel_dontaudit_read_kernel_sysctl(chromium_naclhelper_t)
> kernel_dontaudit_read_system_state(chromium_naclhelper_t)
> ')
> +
> +dev_read_sysfs(chromium_naclhelper_t)
> +dev_read_urand(chromium_naclhelper_t)
> Index: refpolicy-2.20180701/policy/modules/kernel/kernel.if
> ===================================================================
> --- refpolicy-2.20180701.orig/policy/modules/kernel/kernel.if
> +++ refpolicy-2.20180701/policy/modules/kernel/kernel.if
> @@ -2364,6 +2364,24 @@ interface(`kernel_rw_all_sysctls',`
>
> ########################################
> ## <summary>
> +## Associate a file to proc_t (/proc)
> +## </summary>
> +## <param name="domain">
> +## <summary>
> +## Domain allowed access.
> +## </summary>
> +## </param>
> +## <rolecap/>
> +#
> +interface(`kernel_associate_proc',`
> + gen_require(`
> + type proc_t;
> + ')
> + allow $1 proc_t:filesystem associate;
> +')
> +
> +########################################
> +## <summary>
> ## Send a kill signal to unlabeled processes.
> ## </summary>
> ## <param name="domain">
Otherwise merged.
--
Chris PeBenito
next prev parent reply other threads:[~2019-01-30 0:00 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-28 8:46 [PATCH] chromium Russell Coker
2019-01-29 23:53 ` Chris PeBenito [this message]
2019-01-30 12:52 ` Russell Coker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=743dd8f5-9288-8216-4551-b7a74fda3e6d@ieee.org \
--to=pebenito@ieee.org \
--cc=russell@coker.com.au \
--cc=selinux-refpolicy@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).