virtlockd can re-exec itself to upgrade and keep its locks open.
path="/usr/sbin/virtlockd" dev="zfs" ino=153197
scontext=system_u:system_r:virtd_t
tcontext=system_u:object_r:virtd_exec_t tclass=file
---
virt.fc | 1 +
virt.te | 1 +
2 files changed, 2 insertions(+)
diff --git a/virt.fc b/virt.fc
index b38007b..a2facc9 100644
--- a/virt.fc
+++ b/virt.fc
@@ -27,6 +27,7 @@ HOME_DIR/VirtualMachines/isos(/.*)? gen_context(system_u:object_r:virt_content_t
/usr/sbin/fence_virtd -- gen_context(system_u:object_r:virsh_exec_t,s0)
/usr/sbin/libvirt-qmf -- gen_context(system_u:object_r:virt_qmf_exec_t,s0)
/usr/sbin/libvirtd -- gen_context(system_u:object_r:virtd_exec_t,s0)
+/usr/sbin/virtlockd -- gen_context(system_u:object_r:virtd_exec_t,s0)
/var/cache/libvirt(/.*)? gen_context(system_u:object_r:virt_cache_t,s0-mls_systemhigh)
diff --git a/virt.te b/virt.te
index f8a59e4..ab8440d 100644
--- a/virt.te
+++ b/virt.te
@@ -524,6 +524,7 @@ stream_connect_pattern(virtd_t, virtd_lxc_var_run_t, virtd_lxc_var_run_t, virtd_
stream_connect_pattern(virtd_t, svirt_var_run_t, svirt_var_run_t, virt_domain)
can_exec(virtd_t, virt_tmp_t)
+can_exec(virtd_t, virtd_exec_t)
kernel_read_crypto_sysctls(virtd_t)
kernel_read_system_state(virtd_t)
--
2.3.6
---
cron.if | 53 +++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 53 insertions(+)
diff --git a/cron.if b/cron.if
index cc225d1..60574e5 100644
--- a/cron.if
+++ b/cron.if
@@ -838,3 +838,56 @@ interface(`cron_dontaudit_write_system_job_tmp_files',`
dontaudit $1 system_cronjob_tmp_t:file write_file_perms;
')
+
+########################################
+## <summary>
+## All of the rules required to
+## administrate a cron environment.
+## </summary>
+## <param name="domain">
+## <summary>
+## Domain allowed access.
+## </summary>
+## </param>
+## <param name="role">
+## <summary>
+## Role allowed access.
+## </summary>
+## </param>
+## <rolecap/>
+#
+interface(`cron_admin',`
+ gen_require(`
+ type crond_t, crond_initrc_exec_t;
+ type cron_var_lib_t, system_cronjob_var_lib_t;
+ type crond_tmp_t, admin_crontab_tmp_t;
+ type crontab_tmp_t, system_cronjob_tmp_t;
+ type cron_var_run_t, system_cronjob_var_run_t, crond_var_run_t;
+ type cron_log_t, system_cronjob_lock_t, user_cron_spool_log_t;
+ attribute cron_spool_type;
+ ')
+
+ allow $1 crond_t:process { ptrace signal_perms };
+ ps_process_pattern($1, crond_t)
+
+ init_startstop_service($1, $2, crond_t, crond_initrc_exec_t)
+
+ files_search_var_lib($1)
+ admin_pattern($1, { cron_var_lib_t system_cronjob_var_lib_t })
+
+ files_search_tmp($1)
+ admin_pattern($1, { crond_tmp_t admin_crontab_tmp_t })
+ admin_pattern($1, { crontab_tmp_t system_cronjob_tmp_t })
+
+ files_search_pids($1)
+ admin_pattern($1, { cron_var_run_t crond_var_run_t system_cronjob_var_run_t })
+
+ files_search_locks($1)
+ admin_pattern($1, system_cronjob_lock_t)
+
+ logging_search_logs($1)
+ admin_pattern($1, { cron_log_t user_cron_spool_log_t })
+
+ files_search_spool($1)
+ admin_pattern($1, cron_spool_type)
+')
--
2.3.6
On Sat, Jul 11, 2015 at 01:16:42PM +0400, Jason Zaman wrote:
> virtlockd can re-exec itself to upgrade and keep its locks open.
I personally would prefer that this process is not associated with the virtd_t type
>
> path="/usr/sbin/virtlockd" dev="zfs" ino=153197
> scontext=system_u:system_r:virtd_t
> tcontext=system_u:object_r:virtd_exec_t tclass=file
> ---
> virt.fc | 1 +
> virt.te | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/virt.fc b/virt.fc
> index b38007b..a2facc9 100644
> --- a/virt.fc
> +++ b/virt.fc
> @@ -27,6 +27,7 @@ HOME_DIR/VirtualMachines/isos(/.*)? gen_context(system_u:object_r:virt_content_t
> /usr/sbin/fence_virtd -- gen_context(system_u:object_r:virsh_exec_t,s0)
> /usr/sbin/libvirt-qmf -- gen_context(system_u:object_r:virt_qmf_exec_t,s0)
> /usr/sbin/libvirtd -- gen_context(system_u:object_r:virtd_exec_t,s0)
> +/usr/sbin/virtlockd -- gen_context(system_u:object_r:virtd_exec_t,s0)
>
> /var/cache/libvirt(/.*)? gen_context(system_u:object_r:virt_cache_t,s0-mls_systemhigh)
>
> diff --git a/virt.te b/virt.te
> index f8a59e4..ab8440d 100644
> --- a/virt.te
> +++ b/virt.te
> @@ -524,6 +524,7 @@ stream_connect_pattern(virtd_t, virtd_lxc_var_run_t, virtd_lxc_var_run_t, virtd_
> stream_connect_pattern(virtd_t, svirt_var_run_t, svirt_var_run_t, virt_domain)
>
> can_exec(virtd_t, virt_tmp_t)
> +can_exec(virtd_t, virtd_exec_t)
>
> kernel_read_crypto_sysctls(virtd_t)
> kernel_read_system_state(virtd_t)
> --
> 2.3.6
>
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
--
02DFF788
4D30 903A 1CF3 B756 FB48 1514 3148 83A2 02DF F788
http://keys.gnupg.net/pks/lookup?op=vindex&search=0x314883A202DFF788
Dominick Grift
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 648 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20150712/74cbaec2/attachment.bin
On Sat, Jul 11, 2015 at 01:16:43PM +0400, Jason Zaman wrote:
> ---
I would probably take into account the cronjob_t domain, since that is probably a child of the process associated with the crond_t type
Problem is that if the job run with the user contexts then you have a problem. But yes on the other hand, in my humble view if you want to be able to effectively manage a service then you should also be able to manage the services' children.
That would probably also apply to apache_admin() and the various cgi scripts that it forks. I haven't verified that apache_admin can manage cgi script processes but i think it probably should.
> cron.if | 53 +++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 53 insertions(+)
>
> diff --git a/cron.if b/cron.if
> index cc225d1..60574e5 100644
> --- a/cron.if
> +++ b/cron.if
> @@ -838,3 +838,56 @@ interface(`cron_dontaudit_write_system_job_tmp_files',`
>
> dontaudit $1 system_cronjob_tmp_t:file write_file_perms;
> ')
> +
> +########################################
> +## <summary>
> +## All of the rules required to
> +## administrate a cron environment.
> +## </summary>
> +## <param name="domain">
> +## <summary>
> +## Domain allowed access.
> +## </summary>
> +## </param>
> +## <param name="role">
> +## <summary>
> +## Role allowed access.
> +## </summary>
> +## </param>
> +## <rolecap/>
> +#
> +interface(`cron_admin',`
> + gen_require(`
> + type crond_t, crond_initrc_exec_t;
> + type cron_var_lib_t, system_cronjob_var_lib_t;
> + type crond_tmp_t, admin_crontab_tmp_t;
> + type crontab_tmp_t, system_cronjob_tmp_t;
> + type cron_var_run_t, system_cronjob_var_run_t, crond_var_run_t;
> + type cron_log_t, system_cronjob_lock_t, user_cron_spool_log_t;
> + attribute cron_spool_type;
> + ')
> +
> + allow $1 crond_t:process { ptrace signal_perms };
> + ps_process_pattern($1, crond_t)
> +
> + init_startstop_service($1, $2, crond_t, crond_initrc_exec_t)
> +
> + files_search_var_lib($1)
> + admin_pattern($1, { cron_var_lib_t system_cronjob_var_lib_t })
> +
> + files_search_tmp($1)
> + admin_pattern($1, { crond_tmp_t admin_crontab_tmp_t })
> + admin_pattern($1, { crontab_tmp_t system_cronjob_tmp_t })
> +
> + files_search_pids($1)
> + admin_pattern($1, { cron_var_run_t crond_var_run_t system_cronjob_var_run_t })
> +
> + files_search_locks($1)
> + admin_pattern($1, system_cronjob_lock_t)
> +
> + logging_search_logs($1)
> + admin_pattern($1, { cron_log_t user_cron_spool_log_t })
> +
> + files_search_spool($1)
> + admin_pattern($1, cron_spool_type)
> +')
> --
> 2.3.6
>
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
--
02DFF788
4D30 903A 1CF3 B756 FB48 1514 3148 83A2 02DF F788
http://keys.gnupg.net/pks/lookup?op=vindex&search=0x314883A202DFF788
Dominick Grift
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 648 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20150712/0be3cfe3/attachment.bin
On 7/12/2015 1:05 PM, Dominick Grift wrote:
> On Sat, Jul 11, 2015 at 01:16:43PM +0400, Jason Zaman wrote:
>> ---
>
> I would probably take into account the cronjob_t domain, since that is probably a child of the process associated with the crond_t type
>
> Problem is that if the job run with the user contexts then you have a problem. But yes on the other hand, in my humble view if you want to be able to effectively manage a service then you should also be able to manage the services' children.
>
> That would probably also apply to apache_admin() and the various cgi scripts that it forks. I haven't verified that apache_admin can manage cgi script processes but i think it probably should.
I agree. The built-in domains like cronjob_t should be manageable via
the admin interfaces, but I wouldn't go beyond that (e.g. cron jobs
running in user domains). Something like ps_process_pattern, ptrace,
and signal perms seems reasonable for cronjob_t (i.e. similar to the
ones provided for crond_t).
>> cron.if | 53 +++++++++++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 53 insertions(+)
>>
>> diff --git a/cron.if b/cron.if
>> index cc225d1..60574e5 100644
>> --- a/cron.if
>> +++ b/cron.if
>> @@ -838,3 +838,56 @@ interface(`cron_dontaudit_write_system_job_tmp_files',`
>>
>> dontaudit $1 system_cronjob_tmp_t:file write_file_perms;
>> ')
>> +
>> +########################################
>> +## <summary>
>> +## All of the rules required to
>> +## administrate a cron environment.
>> +## </summary>
>> +## <param name="domain">
>> +## <summary>
>> +## Domain allowed access.
>> +## </summary>
>> +## </param>
>> +## <param name="role">
>> +## <summary>
>> +## Role allowed access.
>> +## </summary>
>> +## </param>
>> +## <rolecap/>
>> +#
>> +interface(`cron_admin',`
>> + gen_require(`
>> + type crond_t, crond_initrc_exec_t;
>> + type cron_var_lib_t, system_cronjob_var_lib_t;
>> + type crond_tmp_t, admin_crontab_tmp_t;
>> + type crontab_tmp_t, system_cronjob_tmp_t;
>> + type cron_var_run_t, system_cronjob_var_run_t, crond_var_run_t;
>> + type cron_log_t, system_cronjob_lock_t, user_cron_spool_log_t;
>> + attribute cron_spool_type;
>> + ')
>> +
>> + allow $1 crond_t:process { ptrace signal_perms };
>> + ps_process_pattern($1, crond_t)
>> +
>> + init_startstop_service($1, $2, crond_t, crond_initrc_exec_t)
>> +
>> + files_search_var_lib($1)
>> + admin_pattern($1, { cron_var_lib_t system_cronjob_var_lib_t })
>> +
>> + files_search_tmp($1)
>> + admin_pattern($1, { crond_tmp_t admin_crontab_tmp_t })
>> + admin_pattern($1, { crontab_tmp_t system_cronjob_tmp_t })
>> +
>> + files_search_pids($1)
>> + admin_pattern($1, { cron_var_run_t crond_var_run_t system_cronjob_var_run_t })
>> +
>> + files_search_locks($1)
>> + admin_pattern($1, system_cronjob_lock_t)
>> +
>> + logging_search_logs($1)
>> + admin_pattern($1, { cron_log_t user_cron_spool_log_t })
>> +
>> + files_search_spool($1)
>> + admin_pattern($1, cron_spool_type)
>> +')
>> --
>> 2.3.6
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com