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: Wed, 20 Jan 2021 14:50:33 +0100	[thread overview]
Message-ID: <ypjl1refn2dy.fsf@defensec.nl> (raw)
In-Reply-To: <YAf58vwzUfndWAlS@xev> (Russell Coker's message of "Wed, 20 Jan 2021 20:37:54 +1100")

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)
>  
>  tunable_policy(`pulseaudio_execmem',`
>  	allow pulseaudio_t self:process execmem;
>

-- 
gpg --locate-keys dominick.grift@defensec.nl
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098
Dominick Grift

  reply	other threads:[~2021-01-20 20:38 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 [this message]
2021-01-21  8:36   ` Dominick Grift

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=ypjl1refn2dy.fsf@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.