All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dominick Grift <dominick.grift@defensec.nl>
To: Russell Coker <russell@coker.com.au>
Cc: selinux-refpolicy@vger.kernel.org
Subject: Re: [PATCH] strict 2
Date: Thu, 21 Jan 2021 09:36:15 +0100	[thread overview]
Message-ID: <5eac30f5-2c98-94e2-32d5-698d3792026c@defensec.nl> (raw)
In-Reply-To: <ypjl1refn2dy.fsf@defensec.nl>



On 1/20/21 2:50 PM, Dominick Grift wrote:
> Russell Coker <russell@coker.com.au> writes:
> 
>> Second set of strict configuration patches.  Ready for inclusion.
>>
>> Signed-off-by: Russell Coker <russell@coker.com.au>
>>
>> Index: refpolicy-2.20210120/policy/modules/system/userdomain.if
>> ===================================================================
>> --- refpolicy-2.20210120.orig/policy/modules/system/userdomain.if
>> +++ refpolicy-2.20210120/policy/modules/system/userdomain.if
>> @@ -68,6 +68,8 @@ template(`userdom_base_user_template',`
>>  	dontaudit $1_t user_tty_device_t:chr_file ioctl;
>>  
>>  	kernel_read_kernel_sysctls($1_t)
>> +	kernel_read_crypto_sysctls($1_t)
>> +	kernel_read_vm_overcommit_sysctl($1_t)
> 
> Probably more suitable for userdom_unpriv_user_template() instead
> 
> This is the least required user template and so an effort should be made
> to keep this one really minimal.
> 
>>  	kernel_dontaudit_list_unlabeled($1_t)
>>  	kernel_dontaudit_getattr_unlabeled_files($1_t)
>>  	kernel_dontaudit_getattr_unlabeled_symlinks($1_t)
>> @@ -3552,6 +3554,25 @@ interface(`userdom_delete_all_user_runti
>>  ')
>>  
>>  ########################################
>> +## <summary>
>> +##     write user runtime socket files
>> +## </summary>
>> +## <param name="domain">
>> +##     <summary>
>> +##     Domain allowed access.
>> +##     </summary>
>> +## </param>
>> +#
>> +interface(`userdom_write_all_user_runtime_named_sockets',`
>> +	gen_require(`
>> +		attribute user_runtime_content_type;
>> +	')
>> +
>> +	allow $1 user_runtime_content_type:dir list_dir_perms;
>> +	allow $1 user_runtime_content_type:sock_file write;
>> +')
> 
> I think this is just too broad. see below.
> 
>> +
>> +########################################
>>  ## <summary>
>>  ##	delete user runtime files
>>  ## </summary>
>> Index: refpolicy-2.20210120/policy/modules/roles/sysadm.te
>> ===================================================================
>> --- refpolicy-2.20210120.orig/policy/modules/roles/sysadm.te
>> +++ refpolicy-2.20210120/policy/modules/roles/sysadm.te
>> @@ -33,11 +33,22 @@ ifndef(`enable_mls',`
>>  # Local policy
>>  #
>>  
>> +allow sysadm_t self:netlink_generic_socket { create setopt bind write read };
>> +
>> +# for ptrace
>> +allow sysadm_t self:netlink_tcpdiag_socket { create write nlmsg_read
>> read };
> 
> r_netlink_socket_perms (i suppose, but i dont know how this relates to
> ptrace ... might be the wrong place to add this)
> 
>> +
>> +allow sysadm_t self:capability audit_write;
> 
> Can you explain the above permission?
> 
>> +allow sysadm_t self:system status;
> 
> the status permission is *theorically* systemd specific (needs an ifdef init_systemd?)
> 
> But regardless, and this is personal:
> 
> Why associate all these permissions with the sysadm_t shell. Shells do
> not have systemd awareness. Why not just target whatever command is
> doing this instead so that we can enforce some integrity in the sysadm_t domain?
> 
>> +
>>  corecmd_exec_shell(sysadm_t)
>>  
>>  corenet_ib_access_unlabeled_pkeys(sysadm_t)
>>  corenet_ib_manage_subnet_unlabeled_endports(sysadm_t)
>>  
>> +domain_getsched_all_domains(sysadm_t)
>> +
>> +dev_read_cpuid(sysadm_t)
>>  dev_read_kmsg(sysadm_t)
>>  
>>  mls_process_read_all_levels(sysadm_t)
>> @@ -55,6 +66,9 @@ init_admin(sysadm_t)
>>  userdom_manage_user_home_dirs(sysadm_t)
>>  userdom_home_filetrans_user_home_dir(sysadm_t)
>>  
>> +# for systemd-analyze
>> +files_get_etc_unit_status(sysadm_t)
> 
> See above
> 
>> +
>>  ifdef(`direct_sysadm_daemon',`
>>  	optional_policy(`
>>  		init_run_daemon(sysadm_t, sysadm_r)
>> @@ -1121,6 +1135,10 @@ optional_policy(`
>>  ')
>>  
>>  optional_policy(`
>> +	systemd_dbus_chat_logind(sysadm_t)
>> +')
> 
> shells do not dbus chat with systemd-logind. associating rules with the
> sysadm_t shell instead of targeting commands will eventually lead to
> sysadm_t becoming a unconfined_t clone
> 
>> +
>> +optional_policy(`
>>  	tboot_run_txtstat(sysadm_t, sysadm_r)
>>  ')
>>  
>> @@ -1188,6 +1206,7 @@ optional_policy(`
>>  ')
>>  
>>  optional_policy(`
>> +	dev_rw_generic_usb_dev(sysadm_t)
> 
> shells do not write usb devices. If you want this kind of access then
> why not use unconfined_t shell?
> 
> 
>>  	usbmodules_run(sysadm_t, sysadm_r)
>>  ')
>>  
>> Index: refpolicy-2.20210120/policy/modules/services/xserver.if
>> ===================================================================
>> --- refpolicy-2.20210120.orig/policy/modules/services/xserver.if
>> +++ refpolicy-2.20210120/policy/modules/services/xserver.if
>> @@ -100,6 +100,7 @@ interface(`xserver_restricted_role',`
>>  	xserver_xsession_entry_type($2)
>>  	xserver_dontaudit_write_log($2)
>>  	xserver_stream_connect_xdm($2)
>> +	xserver_use_user_fonts($2)
>>  	# certain apps want to read xdm.pid file
>>  	xserver_read_xdm_runtime_files($2)
>>  	# gnome-session creates socket under /tmp/.ICE-unix/
>> @@ -141,7 +142,7 @@ interface(`xserver_role',`
>>  	gen_require(`
>>  		type iceauth_home_t, xserver_t, xserver_tmp_t, xserver_tmpfs_t, xauth_home_t;
>>  		type user_fonts_t, user_fonts_cache_t, user_fonts_config_t;
>> -		type mesa_shader_cache_t;
>> +		type mesa_shader_cache_t, xdm_t;
>>  	')
>>  
>>  	xserver_restricted_role($1, $2)
>> @@ -184,6 +185,8 @@ interface(`xserver_role',`
>>  
>>  	xserver_read_xkb_libs($2)
>>  
>> +	allow $2 xdm_t:unix_stream_socket accept;
> 
> Looks weird, why would $2 have to accept connections on xdm_t unix
> stream sockets?
> 
>> +
>>  	optional_policy(`
>>  		xdg_cache_filetrans($2, mesa_shader_cache_t, dir, "mesa_shader_cache")
>>  	')
>> @@ -1239,6 +1242,7 @@ interface(`xserver_read_xkb_libs',`
>>  	allow $1 xkb_var_lib_t:dir list_dir_perms;
>>  	read_files_pattern($1, xkb_var_lib_t, xkb_var_lib_t)
>>  	read_lnk_files_pattern($1, xkb_var_lib_t, xkb_var_lib_t)
>> +	allow $1 xkb_var_lib_t:file map;
>>  ')
>>  
>>  ########################################
>> Index: refpolicy-2.20210120/policy/modules/services/dbus.if
>> ===================================================================
>> --- refpolicy-2.20210120.orig/policy/modules/services/dbus.if
>> +++ refpolicy-2.20210120/policy/modules/services/dbus.if
>> @@ -84,6 +84,7 @@ template(`dbus_role_template',`
>>  
>>  	allow $3 $1_dbusd_t:unix_stream_socket connectto;
>>  	allow $3 $1_dbusd_t:dbus { send_msg acquire_svc };
>> +	allow $1_dbusd_t $3:dbus send_msg;
> 
> I do not believe this is needed, or that it should be part of this
> template (too broad)
> 
>>  	allow $3 $1_dbusd_t:fd use;
>>  
>>  	allow $3 system_dbusd_t:dbus { send_msg acquire_svc };
>> @@ -99,9 +100,13 @@ template(`dbus_role_template',`
>>  
>>  	allow $1_dbusd_t $3:process sigkill;
>>  
>> +	allow $1_dbusd_t self:process getcap;
>> +
>>  	corecmd_bin_domtrans($1_dbusd_t, $3)
>>  	corecmd_shell_domtrans($1_dbusd_t, $3)
>>  
>> +	dev_read_sysfs($1_dbusd_t)
>> +
>>  	auth_use_nsswitch($1_dbusd_t)
>>  
>>  	ifdef(`hide_broken_symptoms',`
>> @@ -111,6 +116,15 @@ template(`dbus_role_template',`
>>  	optional_policy(`
>>  		systemd_read_logind_runtime_files($1_dbusd_t)
>>  	')
>> +
>> +	optional_policy(`
>> +		init_dbus_chat($1_dbusd_t)
>> +		dbus_system_bus_client($1_dbusd_t)
> 
> Why did you add this? is this to resolve dynamic users with systemd?
> Using dbus to resolve dynamic users was a fluke and has been
> reimplemented. So if this was added for that then its obsolete and it
> should be revisited with modern systemd
> 
>> +	')
>> +
>> +	optional_policy(`
>> +		xdg_read_data_files($1_dbusd_t)
>> +	')
> 
> Is this for ~/.local/share/dbus-1? I would probably consider creating a
> private xdg_data type for that , but thats subjective.
> 
>>  ')
>>  
>>  #######################################
>> Index: refpolicy-2.20210120/policy/modules/services/ssh.if
>> ===================================================================
>> --- refpolicy-2.20210120.orig/policy/modules/services/ssh.if
>> +++ refpolicy-2.20210120/policy/modules/services/ssh.if
>> @@ -439,6 +439,7 @@ template(`ssh_role_template',`
>>  		xserver_use_xdm_fds($1_ssh_agent_t)
>>  		xserver_rw_xdm_pipes($1_ssh_agent_t)
>>  		xserver_sigchld_xdm($1_ssh_agent_t)
>> +		xserver_write_inherited_xsession_log($1_ssh_agent_t)
> 
> this access should probably be allowed on application_domain level, but
> thats a personal opinion. Basicall stdout of all application domains is
> directed to the xsession log AFAIK.
> 
> No strong feelings about this though as xserver is dead anyway.
> 
>>  	')
>>  ')
>>  
>> Index: refpolicy-2.20210120/policy/modules/kernel/corecommands.te
>> ===================================================================
>> --- refpolicy-2.20210120.orig/policy/modules/kernel/corecommands.te
>> +++ refpolicy-2.20210120/policy/modules/kernel/corecommands.te
>> @@ -13,7 +13,7 @@ attribute exec_type;
>>  #
>>  # bin_t is the type of files in the system bin/sbin directories.
>>  #
>> -type bin_t alias { ls_exec_t sbin_t };
>> +type bin_t alias { ls_exec_t sbin_t systemd_analyze_exec_t };
> 
> I wouldnt remove systemd_analyze_t but i will leave that for others to
> decide (obviously)
> 
>>  corecmd_executable_file(bin_t)
>>  dev_associate(bin_t)	#For /dev/MAKEDEV
>>  
>> Index: refpolicy-2.20210120/policy/modules/system/systemd.te
>> ===================================================================
>> --- refpolicy-2.20210120.orig/policy/modules/system/systemd.te
>> +++ refpolicy-2.20210120/policy/modules/system/systemd.te
>> @@ -55,10 +55,6 @@ type systemd_activate_t;
>>  type systemd_activate_exec_t;
>>  init_system_domain(systemd_activate_t, systemd_activate_exec_t)
>>  
>> -type systemd_analyze_t;
>> -type systemd_analyze_exec_t;
>> -init_daemon_domain(systemd_analyze_t, systemd_analyze_exec_t)
>> -
>>  type systemd_backlight_t;
>>  type systemd_backlight_exec_t;
>>  init_system_domain(systemd_backlight_t, systemd_backlight_exec_t)
>> @@ -1361,6 +1357,7 @@ tunable_policy(`systemd_tmpfiles_manage_
>>  ')
>>  
>>  optional_policy(`
>> +	dbus_manage_lib_files(systemd_tmpfiles_t)
>>  	dbus_read_lib_files(systemd_tmpfiles_t)
>>  	dbus_relabel_lib_dirs(systemd_tmpfiles_t)
>>  ')
>> Index: refpolicy-2.20210120/policy/modules/services/cron.te
>> ===================================================================
>> --- refpolicy-2.20210120.orig/policy/modules/services/cron.te
>> +++ refpolicy-2.20210120/policy/modules/services/cron.te
>> @@ -489,6 +489,7 @@ kernel_getattr_core_if(system_cronjob_t)
>>  kernel_getattr_message_if(system_cronjob_t)
>>  
>>  kernel_read_crypto_sysctls(system_cronjob_t)
>> +kernel_read_fs_sysctls(system_cronjob_t)
>>  kernel_read_irq_sysctls(system_cronjob_t)
>>  kernel_read_kernel_sysctls(system_cronjob_t)
>>  kernel_read_network_state(system_cronjob_t)
>> Index: refpolicy-2.20210120/policy/modules/apps/pulseaudio.te
>> ===================================================================
>> --- refpolicy-2.20210120.orig/policy/modules/apps/pulseaudio.te
>> +++ refpolicy-2.20210120/policy/modules/apps/pulseaudio.te
>> @@ -156,6 +156,7 @@ userdom_search_user_home_content(pulseau
>>  userdom_manage_user_tmp_dirs(pulseaudio_t)
>>  userdom_manage_user_tmp_files(pulseaudio_t)
>>  userdom_manage_user_tmp_sockets(pulseaudio_t)
>> +userdom_write_all_user_runtime_named_sockets(pulseaudio_t)

forgot to comment on this one. this looks wrong. why did you add this?
dont want pulseaudio to write my gpg-agent sock file in
/run/user/UID/gnupg or anything except the pulseaudio socket for that matter

>> 
>>  tunable_policy(`pulseaudio_execmem',`
>>  	allow pulseaudio_t self:process execmem;
>>
> 

      reply	other threads:[~2021-01-21  8:37 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-20  9:37 [PATCH] strict 2 Russell Coker
2021-01-20 13:50 ` Dominick Grift
2021-01-21  8:36   ` Dominick Grift [this message]

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=5eac30f5-2c98-94e2-32d5-698d3792026c@defensec.nl \
    --to=dominick.grift@defensec.nl \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.