Update the initrc_t domain policy in the init module with some
missing permissions.
Signed-off-by: Guido Trentalancia <[email protected]>
---
policy/modules/kernel/terminal.if | 21 +++++++++++++++++++++
policy/modules/system/init.te | 19 +++++++++++++++++--
2 files changed, 38 insertions(+), 2 deletions(-)
diff -pru a/policy/modules/kernel/terminal.if b/policy/modules/kernel/terminal.if
--- a/policy/modules/kernel/terminal.if 2016-12-27 22:41:00.664390360 +0100
+++ b/policy/modules/kernel/terminal.if 2016-12-29 23:30:56.342306506 +0100
@@ -1102,6 +1102,27 @@ interface(`term_relabel_all_user_ptys',`
########################################
## <summary>
+## Unlink BSD-style pty device
+## nodes.
+## </summary>
+## <param name="domain">
+## <summary>
+## Domain allowed access.
+## </summary>
+## </param>
+## <rolecap/>
+#
+interface(`term_unlink_bsd_ptys',`
+ gen_require(`
+ type bsdpty_device_t;
+ ')
+
+ dev_list_all_dev_nodes($1)
+ allow $1 bsdpty_device_t:chr_file { unlink };
+')
+
+########################################
+## <summary>
## Get the attributes of all unallocated
## tty device nodes.
## </summary>
diff -pru a/policy/modules/system/init.te b/policy/modules/system/init.te
--- a/policy/modules/system/init.te 2016-12-29 22:48:16.456818544 +0100
+++ b/policy/modules/system/init.te 2016-12-29 23:44:28.212518135 +0100
@@ -415,12 +415,16 @@ kernel_clear_ring_buffer(initrc_t)
kernel_get_sysvipc_info(initrc_t)
kernel_read_all_sysctls(initrc_t)
kernel_rw_all_sysctls(initrc_t)
+kernel_use_fds(initrc_t)
# for lsof which is used by alsa shutdown:
kernel_dontaudit_getattr_message_if(initrc_t)
# cjp: not sure why these are here; should use mount policy
kernel_list_unlabeled(initrc_t)
kernel_mounton_unlabeled_dirs(initrc_t)
+# plymouth
+kernel_stream_connect(initrc_t)
+
files_create_lock_dirs(initrc_t)
files_pid_filetrans_lock_dir(initrc_t, "lock")
files_read_kernel_symbol_table(initrc_t)
@@ -462,6 +466,8 @@ dev_getattr_all_blk_files(initrc_t)
dev_getattr_all_chr_files(initrc_t)
# Early devtmpfs
dev_rw_generic_chr_files(initrc_t)
+# mcelog service
+dev_read_kmsg(initrc_t)
domain_kill_all_domains(initrc_t)
domain_signal_all_domains(initrc_t)
@@ -496,6 +502,8 @@ files_exec_etc_files(initrc_t)
files_read_usr_files(initrc_t)
files_manage_urandom_seed(initrc_t)
files_manage_generic_spool(initrc_t)
+# manage the restorecond lock file
+files_manage_generic_locks(initrc_t)
# Mount and unmount file systems.
# cjp: not sure why these are here; should use mount policy
files_list_default(initrc_t)
@@ -532,10 +540,12 @@ storage_setattr_removable_dev(initrc_t)
term_use_all_terms(initrc_t)
term_reset_tty_labels(initrc_t)
+term_unlink_bsd_ptys(initrc_t)
auth_rw_login_records(initrc_t)
auth_setattr_login_records(initrc_t)
auth_rw_lastlog(initrc_t)
+auth_manage_faillog(initrc_t)
auth_read_pam_pid(initrc_t)
auth_delete_pam_pid(initrc_t)
auth_delete_pam_console_data(initrc_t)
@@ -831,12 +841,13 @@ optional_policy(`
')
optional_policy(`
- dev_getattr_printer_dev(initrc_t)
-
+ cups_domtrans(initrc_t)
cups_read_log(initrc_t)
cups_read_rw_config(initrc_t)
#cups init script clears error log
cups_write_log(initrc_t)
+
+ dev_getattr_printer_dev(initrc_t)
')
optional_policy(`
@@ -900,6 +911,10 @@ optional_policy(`
')
optional_policy(`
+ iptables_read_config(initrc_t)
+')
+
+optional_policy(`
iscsi_stream_connect(initrc_t)
iscsi_read_lib_files(initrc_t)
')
On 12/29/16 17:49, Guido Trentalancia via refpolicy wrote:
> Update the initrc_t domain policy in the init module with some
> missing permissions.
>
> Signed-off-by: Guido Trentalancia <[email protected]>
> ---
> policy/modules/kernel/terminal.if | 21 +++++++++++++++++++++
> policy/modules/system/init.te | 19 +++++++++++++++++--
> 2 files changed, 38 insertions(+), 2 deletions(-)
>
> diff -pru a/policy/modules/kernel/terminal.if b/policy/modules/kernel/terminal.if
> --- a/policy/modules/kernel/terminal.if 2016-12-27 22:41:00.664390360 +0100
> +++ b/policy/modules/kernel/terminal.if 2016-12-29 23:30:56.342306506 +0100
> @@ -1102,6 +1102,27 @@ interface(`term_relabel_all_user_ptys',`
>
> ########################################
> ## <summary>
> +## Unlink BSD-style pty device
> +## nodes.
> +## </summary>
> +## <param name="domain">
> +## <summary>
> +## Domain allowed access.
> +## </summary>
> +## </param>
> +## <rolecap/>
> +#
> +interface(`term_unlink_bsd_ptys',`
> + gen_require(`
> + type bsdpty_device_t;
> + ')
> +
> + dev_list_all_dev_nodes($1)
> + allow $1 bsdpty_device_t:chr_file { unlink };
> +')
> +
> +########################################
> +## <summary>
> ## Get the attributes of all unallocated
> ## tty device nodes.
> ## </summary>
> diff -pru a/policy/modules/system/init.te b/policy/modules/system/init.te
> --- a/policy/modules/system/init.te 2016-12-29 22:48:16.456818544 +0100
> +++ b/policy/modules/system/init.te 2016-12-29 23:44:28.212518135 +0100
> @@ -415,12 +415,16 @@ kernel_clear_ring_buffer(initrc_t)
> kernel_get_sysvipc_info(initrc_t)
> kernel_read_all_sysctls(initrc_t)
> kernel_rw_all_sysctls(initrc_t)
> +kernel_use_fds(initrc_t)
> # for lsof which is used by alsa shutdown:
> kernel_dontaudit_getattr_message_if(initrc_t)
> # cjp: not sure why these are here; should use mount policy
> kernel_list_unlabeled(initrc_t)
> kernel_mounton_unlabeled_dirs(initrc_t)
>
> +# plymouth
> +kernel_stream_connect(initrc_t)
Plymouth has a domain, so this seems unnecessary.
> files_create_lock_dirs(initrc_t)
> files_pid_filetrans_lock_dir(initrc_t, "lock")
> files_read_kernel_symbol_table(initrc_t)
> @@ -462,6 +466,8 @@ dev_getattr_all_blk_files(initrc_t)
> dev_getattr_all_chr_files(initrc_t)
> # Early devtmpfs
> dev_rw_generic_chr_files(initrc_t)
> +# mcelog service
> +dev_read_kmsg(initrc_t)
mcelog is a service, so it shouldn't be running in initrc_t.
> domain_kill_all_domains(initrc_t)
> domain_signal_all_domains(initrc_t)
> @@ -496,6 +502,8 @@ files_exec_etc_files(initrc_t)
> files_read_usr_files(initrc_t)
> files_manage_urandom_seed(initrc_t)
> files_manage_generic_spool(initrc_t)
> +# manage the restorecond lock file
> +files_manage_generic_locks(initrc_t)
initrc_t can already delete all locks. Why does it need to create locks?
> # Mount and unmount file systems.
> # cjp: not sure why these are here; should use mount policy
> files_list_default(initrc_t)
> @@ -532,10 +540,12 @@ storage_setattr_removable_dev(initrc_t)
>
> term_use_all_terms(initrc_t)
> term_reset_tty_labels(initrc_t)
> +term_unlink_bsd_ptys(initrc_t)
>
> auth_rw_login_records(initrc_t)
> auth_setattr_login_records(initrc_t)
> auth_rw_lastlog(initrc_t)
> +auth_manage_faillog(initrc_t)
> auth_read_pam_pid(initrc_t)
> auth_delete_pam_pid(initrc_t)
> auth_delete_pam_console_data(initrc_t)
> @@ -831,12 +841,13 @@ optional_policy(`
> ')
>
> optional_policy(`
> - dev_getattr_printer_dev(initrc_t)
> -
> + cups_domtrans(initrc_t)
This should not be necessary, as cups is already an init_daemon_domain().
> cups_read_log(initrc_t)
> cups_read_rw_config(initrc_t)
> #cups init script clears error log
> cups_write_log(initrc_t)
> +
> + dev_getattr_printer_dev(initrc_t)
> ')
>
> optional_policy(`
> @@ -900,6 +911,10 @@ optional_policy(`
> ')
>
> optional_policy(`
> + iptables_read_config(initrc_t)
> +')
> +
> +optional_policy(`
> iscsi_stream_connect(initrc_t)
> iscsi_read_lib_files(initrc_t)
> ')
--
Chris PeBenito
On 12/30/2016 08:30 PM, Chris PeBenito via refpolicy wrote:
> On 12/29/16 17:49, Guido Trentalancia via refpolicy wrote:
>> Update the initrc_t domain policy in the init module with some
>> missing permissions.
>>
>> Signed-off-by: Guido Trentalancia <[email protected]>
>> ---
>> policy/modules/kernel/terminal.if | 21 +++++++++++++++++++++
>> policy/modules/system/init.te | 19 +++++++++++++++++--
>> 2 files changed, 38 insertions(+), 2 deletions(-)
>>
>> diff -pru a/policy/modules/kernel/terminal.if b/policy/modules/kernel/terminal.if
>> --- a/policy/modules/kernel/terminal.if 2016-12-27 22:41:00.664390360 +0100
>> +++ b/policy/modules/kernel/terminal.if 2016-12-29 23:30:56.342306506 +0100
>> @@ -1102,6 +1102,27 @@ interface(`term_relabel_all_user_ptys',`
>>
>> ########################################
>> ## <summary>
>> +## Unlink BSD-style pty device
>> +## nodes.
>> +## </summary>
>> +## <param name="domain">
>> +## <summary>
>> +## Domain allowed access.
>> +## </summary>
>> +## </param>
>> +## <rolecap/>
>> +#
>> +interface(`term_unlink_bsd_ptys',`
>> + gen_require(`
>> + type bsdpty_device_t;
>> + ')
>> +
>> + dev_list_all_dev_nodes($1)
>> + allow $1 bsdpty_device_t:chr_file { unlink };
>> +')
>> +
>> +########################################
>> +## <summary>
>> ## Get the attributes of all unallocated
>> ## tty device nodes.
>> ## </summary>
>> diff -pru a/policy/modules/system/init.te b/policy/modules/system/init.te
>> --- a/policy/modules/system/init.te 2016-12-29 22:48:16.456818544 +0100
>> +++ b/policy/modules/system/init.te 2016-12-29 23:44:28.212518135 +0100
>> @@ -415,12 +415,16 @@ kernel_clear_ring_buffer(initrc_t)
>> kernel_get_sysvipc_info(initrc_t)
>> kernel_read_all_sysctls(initrc_t)
>> kernel_rw_all_sysctls(initrc_t)
>> +kernel_use_fds(initrc_t)
>> # for lsof which is used by alsa shutdown:
>> kernel_dontaudit_getattr_message_if(initrc_t)
>> # cjp: not sure why these are here; should use mount policy
>> kernel_list_unlabeled(initrc_t)
>> kernel_mounton_unlabeled_dirs(initrc_t)
>>
>> +# plymouth
>> +kernel_stream_connect(initrc_t)
>
> Plymouth has a domain, so this seems unnecessary.
Plymouthd is running from initramfs before policy is loaded. So once the
policy gets loaded and root is switched the kernel isid kicks in and
associates kernel_t with the process
>
>> files_create_lock_dirs(initrc_t)
>> files_pid_filetrans_lock_dir(initrc_t, "lock")
>> files_read_kernel_symbol_table(initrc_t)
>> @@ -462,6 +466,8 @@ dev_getattr_all_blk_files(initrc_t)
>> dev_getattr_all_chr_files(initrc_t)
>> # Early devtmpfs
>> dev_rw_generic_chr_files(initrc_t)
>> +# mcelog service
>> +dev_read_kmsg(initrc_t)
>
> mcelog is a service, so it shouldn't be running in initrc_t.
>
>> domain_kill_all_domains(initrc_t)
>> domain_signal_all_domains(initrc_t)
>> @@ -496,6 +502,8 @@ files_exec_etc_files(initrc_t)
>> files_read_usr_files(initrc_t)
>> files_manage_urandom_seed(initrc_t)
>> files_manage_generic_spool(initrc_t)
>> +# manage the restorecond lock file
>> +files_manage_generic_locks(initrc_t)
>
> initrc_t can already delete all locks. Why does it need to create locks?
>
>
>> # Mount and unmount file systems.
>> # cjp: not sure why these are here; should use mount policy
>> files_list_default(initrc_t)
>> @@ -532,10 +540,12 @@ storage_setattr_removable_dev(initrc_t)
>>
>> term_use_all_terms(initrc_t)
>> term_reset_tty_labels(initrc_t)
>> +term_unlink_bsd_ptys(initrc_t)
>>
>> auth_rw_login_records(initrc_t)
>> auth_setattr_login_records(initrc_t)
>> auth_rw_lastlog(initrc_t)
>> +auth_manage_faillog(initrc_t)
>> auth_read_pam_pid(initrc_t)
>> auth_delete_pam_pid(initrc_t)
>> auth_delete_pam_console_data(initrc_t)
>> @@ -831,12 +841,13 @@ optional_policy(`
>> ')
>>
>> optional_policy(`
>> - dev_getattr_printer_dev(initrc_t)
>> -
>> + cups_domtrans(initrc_t)
>
> This should not be necessary, as cups is already an init_daemon_domain().
>
>> cups_read_log(initrc_t)
>> cups_read_rw_config(initrc_t)
>> #cups init script clears error log
>> cups_write_log(initrc_t)
>> +
>> + dev_getattr_printer_dev(initrc_t)
>> ')
>>
>> optional_policy(`
>> @@ -900,6 +911,10 @@ optional_policy(`
>> ')
>>
>> optional_policy(`
>> + iptables_read_config(initrc_t)
>> +')
>> +
>> +optional_policy(`
>> iscsi_stream_connect(initrc_t)
>> iscsi_read_lib_files(initrc_t)
>> ')
>
>
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 648 bytes
Desc: OpenPGP digital signature
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20161230/86333304/attachment.bin
On Fri, 30/12/2016 at 21.01 +0100, Dominick Grift via refpolicy wrote:
> On 12/30/2016 08:30 PM, Chris PeBenito via refpolicy wrote:
> >
> > On 12/29/16 17:49, Guido Trentalancia via refpolicy wrote:
> > >
> > > Update the initrc_t domain policy in the init module with some
> > > missing permissions.
> > >
> > > Signed-off-by: Guido Trentalancia <[email protected]>
> > > ---
> > > ?policy/modules/kernel/terminal.if |???21 +++++++++++++++++++++
> > > ?policy/modules/system/init.te?????|???19 +++++++++++++++++--
> > > ?2 files changed, 38 insertions(+), 2 deletions(-)
> > >
> > > diff -pru a/policy/modules/kernel/terminal.if
> > > b/policy/modules/kernel/terminal.if
> > > --- a/policy/modules/kernel/terminal.if 2016-12-27
> > > 22:41:00.664390360 +0100
> > > +++ b/policy/modules/kernel/terminal.if 2016-12-29
> > > 23:30:56.342306506 +0100
> > > @@ -1102,6 +1102,27 @@ interface(`term_relabel_all_user_ptys',`
> > >
> > > ?########################################
> > > ?## <summary>
> > > +## Unlink BSD-style pty device
> > > +## nodes.
> > > +## </summary>
> > > +## <param name="domain">
> > > +## <summary>
> > > +## Domain allowed access.
> > > +## </summary>
> > > +## </param>
> > > +## <rolecap/>
> > > +#
> > > +interface(`term_unlink_bsd_ptys',`
> > > + gen_require(`
> > > + type bsdpty_device_t;
> > > + ')
> > > +
> > > + dev_list_all_dev_nodes($1)
> > > + allow $1 bsdpty_device_t:chr_file { unlink };
> > > +')
> > > +
> > > +########################################
> > > +## <summary>
> > > ?## Get the attributes of all unallocated
> > > ?## tty device nodes.
> > > ?## </summary>
> > > diff -pru a/policy/modules/system/init.te
> > > b/policy/modules/system/init.te
> > > --- a/policy/modules/system/init.te 2016-12-29
> > > 22:48:16.456818544 +0100
> > > +++ b/policy/modules/system/init.te 2016-12-29
> > > 23:44:28.212518135 +0100
> > > @@ -415,12 +415,16 @@ kernel_clear_ring_buffer(initrc_t)
> > > ?kernel_get_sysvipc_info(initrc_t)
> > > ?kernel_read_all_sysctls(initrc_t)
> > > ?kernel_rw_all_sysctls(initrc_t)
> > > +kernel_use_fds(initrc_t)
> > > ?# for lsof which is used by alsa shutdown:
> > > ?kernel_dontaudit_getattr_message_if(initrc_t)
> > > ?# cjp: not sure why these are here; should use mount policy
> > > ?kernel_list_unlabeled(initrc_t)
> > > ?kernel_mounton_unlabeled_dirs(initrc_t)
> > >
> > > +# plymouth
> > > +kernel_stream_connect(initrc_t)
> >
> > Plymouth has a domain, so this seems unnecessary.
>
> Plymouthd is running from initramfs before policy is loaded. So once
> the
> policy gets loaded and root is switched the kernel isid kicks in and
> associates kernel_t with the process
Yes, I confirm. Plymouthd is running in the kernel_t domain because it
is started before the policy is loaded.
> > > ?files_create_lock_dirs(initrc_t)
> > > ?files_pid_filetrans_lock_dir(initrc_t, "lock")
> > > ?files_read_kernel_symbol_table(initrc_t)
> > > @@ -462,6 +466,8 @@ dev_getattr_all_blk_files(initrc_t)
> > > ?dev_getattr_all_chr_files(initrc_t)
> > > ?# Early devtmpfs
> > > ?dev_rw_generic_chr_files(initrc_t)
> > > +# mcelog service
> > > +dev_read_kmsg(initrc_t)
> >
> > mcelog is a service, so it shouldn't be running in initrc_t.
> >
> > >
> > > ?domain_kill_all_domains(initrc_t)
> > > ?domain_signal_all_domains(initrc_t)
> > > @@ -496,6 +502,8 @@ files_exec_etc_files(initrc_t)
> > > ?files_read_usr_files(initrc_t)
> > > ?files_manage_urandom_seed(initrc_t)
> > > ?files_manage_generic_spool(initrc_t)
> > > +# manage the restorecond lock file
> > > +files_manage_generic_locks(initrc_t)
> >
> > initrc_t can already delete all locks.??Why does it need to create
> > locks?
> >
> >
> > >
> > > ?# Mount and unmount file systems.
> > > ?# cjp: not sure why these are here; should use mount policy
> > > ?files_list_default(initrc_t)
> > > @@ -532,10 +540,12 @@ storage_setattr_removable_dev(initrc_t)
> > >
> > > ?term_use_all_terms(initrc_t)
> > > ?term_reset_tty_labels(initrc_t)
> > > +term_unlink_bsd_ptys(initrc_t)
> > >
> > > ?auth_rw_login_records(initrc_t)
> > > ?auth_setattr_login_records(initrc_t)
> > > ?auth_rw_lastlog(initrc_t)
> > > +auth_manage_faillog(initrc_t)
> > > ?auth_read_pam_pid(initrc_t)
> > > ?auth_delete_pam_pid(initrc_t)
> > > ?auth_delete_pam_console_data(initrc_t)
> > > @@ -831,12 +841,13 @@ optional_policy(`
> > > ?')
> > >
> > > ?optional_policy(`
> > > - dev_getattr_printer_dev(initrc_t)
> > > -
> > > + cups_domtrans(initrc_t)
> >
> > This should not be necessary, as cups is already an
> > init_daemon_domain().
> >
> > >
> > > ? cups_read_log(initrc_t)
> > > ? cups_read_rw_config(initrc_t)
> > > ?#cups init script clears error log
> > > ? cups_write_log(initrc_t)
> > > +
> > > + dev_getattr_printer_dev(initrc_t)
> > > ?')
> > >
> > > ?optional_policy(`
> > > @@ -900,6 +911,10 @@ optional_policy(`
> > > ?')
> > >
> > > ?optional_policy(`
> > > + iptables_read_config(initrc_t)
> > > +')
> > > +
> > > +optional_policy(`
> > > ? iscsi_stream_connect(initrc_t)
> > > ? iscsi_read_lib_files(initrc_t)
> > > ?')
Regards,
Guido
On 12/30/2016 09:09 PM, Guido Trentalancia via refpolicy wrote:
> On Fri, 30/12/2016 at 21.01 +0100, Dominick Grift via refpolicy wrote:
>> On 12/30/2016 08:30 PM, Chris PeBenito via refpolicy wrote:
>>>
>>> On 12/29/16 17:49, Guido Trentalancia via refpolicy wrote:
>>>>
>>>> Update the initrc_t domain policy in the init module with some
>>>> missing permissions.
>>>>
>>>> Signed-off-by: Guido Trentalancia <[email protected]>
>>>> ---
>>>> policy/modules/kernel/terminal.if | 21 +++++++++++++++++++++
>>>> policy/modules/system/init.te | 19 +++++++++++++++++--
>>>> 2 files changed, 38 insertions(+), 2 deletions(-)
>>>>
>>>> diff -pru a/policy/modules/kernel/terminal.if
>>>> b/policy/modules/kernel/terminal.if
>>>> --- a/policy/modules/kernel/terminal.if 2016-12-27
>>>> 22:41:00.664390360 +0100
>>>> +++ b/policy/modules/kernel/terminal.if 2016-12-29
>>>> 23:30:56.342306506 +0100
>>>> @@ -1102,6 +1102,27 @@ interface(`term_relabel_all_user_ptys',`
>>>>
>>>> ########################################
>>>> ## <summary>
>>>> +## Unlink BSD-style pty device
>>>> +## nodes.
>>>> +## </summary>
>>>> +## <param name="domain">
>>>> +## <summary>
>>>> +## Domain allowed access.
>>>> +## </summary>
>>>> +## </param>
>>>> +## <rolecap/>
>>>> +#
>>>> +interface(`term_unlink_bsd_ptys',`
>>>> + gen_require(`
>>>> + type bsdpty_device_t;
>>>> + ')
>>>> +
>>>> + dev_list_all_dev_nodes($1)
>>>> + allow $1 bsdpty_device_t:chr_file { unlink };
>>>> +')
>>>> +
>>>> +########################################
>>>> +## <summary>
>>>> ## Get the attributes of all unallocated
>>>> ## tty device nodes.
>>>> ## </summary>
>>>> diff -pru a/policy/modules/system/init.te
>>>> b/policy/modules/system/init.te
>>>> --- a/policy/modules/system/init.te 2016-12-29
>>>> 22:48:16.456818544 +0100
>>>> +++ b/policy/modules/system/init.te 2016-12-29
>>>> 23:44:28.212518135 +0100
>>>> @@ -415,12 +415,16 @@ kernel_clear_ring_buffer(initrc_t)
>>>> kernel_get_sysvipc_info(initrc_t)
>>>> kernel_read_all_sysctls(initrc_t)
>>>> kernel_rw_all_sysctls(initrc_t)
>>>> +kernel_use_fds(initrc_t)
>>>> # for lsof which is used by alsa shutdown:
>>>> kernel_dontaudit_getattr_message_if(initrc_t)
>>>> # cjp: not sure why these are here; should use mount policy
>>>> kernel_list_unlabeled(initrc_t)
>>>> kernel_mounton_unlabeled_dirs(initrc_t)
>>>>
>>>> +# plymouth
>>>> +kernel_stream_connect(initrc_t)
>>>
>>> Plymouth has a domain, so this seems unnecessary.
>>
>> Plymouthd is running from initramfs before policy is loaded. So once
>> the
>> policy gets loaded and root is switched the kernel isid kicks in and
>> associates kernel_t with the process
>
> Yes, I confirm. Plymouthd is running in the kernel_t domain because it
> is started before the policy is loaded.
>
The question is then what is running in initrc_t in that event? is it
the plymouth client stream connecting to plymouthd?
is the plymouth client an init_system_domain()?
>>>> files_create_lock_dirs(initrc_t)
>>>> files_pid_filetrans_lock_dir(initrc_t, "lock")
>>>> files_read_kernel_symbol_table(initrc_t)
>>>> @@ -462,6 +466,8 @@ dev_getattr_all_blk_files(initrc_t)
>>>> dev_getattr_all_chr_files(initrc_t)
>>>> # Early devtmpfs
>>>> dev_rw_generic_chr_files(initrc_t)
>>>> +# mcelog service
>>>> +dev_read_kmsg(initrc_t)
>>>
>>> mcelog is a service, so it shouldn't be running in initrc_t.
>>>
>>>>
>>>> domain_kill_all_domains(initrc_t)
>>>> domain_signal_all_domains(initrc_t)
>>>> @@ -496,6 +502,8 @@ files_exec_etc_files(initrc_t)
>>>> files_read_usr_files(initrc_t)
>>>> files_manage_urandom_seed(initrc_t)
>>>> files_manage_generic_spool(initrc_t)
>>>> +# manage the restorecond lock file
>>>> +files_manage_generic_locks(initrc_t)
>>>
>>> initrc_t can already delete all locks. Why does it need to create
>>> locks?
>>>
>>>
>>>>
>>>> # Mount and unmount file systems.
>>>> # cjp: not sure why these are here; should use mount policy
>>>> files_list_default(initrc_t)
>>>> @@ -532,10 +540,12 @@ storage_setattr_removable_dev(initrc_t)
>>>>
>>>> term_use_all_terms(initrc_t)
>>>> term_reset_tty_labels(initrc_t)
>>>> +term_unlink_bsd_ptys(initrc_t)
>>>>
>>>> auth_rw_login_records(initrc_t)
>>>> auth_setattr_login_records(initrc_t)
>>>> auth_rw_lastlog(initrc_t)
>>>> +auth_manage_faillog(initrc_t)
>>>> auth_read_pam_pid(initrc_t)
>>>> auth_delete_pam_pid(initrc_t)
>>>> auth_delete_pam_console_data(initrc_t)
>>>> @@ -831,12 +841,13 @@ optional_policy(`
>>>> ')
>>>>
>>>> optional_policy(`
>>>> - dev_getattr_printer_dev(initrc_t)
>>>> -
>>>> + cups_domtrans(initrc_t)
>>>
>>> This should not be necessary, as cups is already an
>>> init_daemon_domain().
>>>
>>>>
>>>> cups_read_log(initrc_t)
>>>> cups_read_rw_config(initrc_t)
>>>> #cups init script clears error log
>>>> cups_write_log(initrc_t)
>>>> +
>>>> + dev_getattr_printer_dev(initrc_t)
>>>> ')
>>>>
>>>> optional_policy(`
>>>> @@ -900,6 +911,10 @@ optional_policy(`
>>>> ')
>>>>
>>>> optional_policy(`
>>>> + iptables_read_config(initrc_t)
>>>> +')
>>>> +
>>>> +optional_policy(`
>>>> iscsi_stream_connect(initrc_t)
>>>> iscsi_read_lib_files(initrc_t)
>>>> ')
>
> Regards,
>
> Guido
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
>
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 648 bytes
Desc: OpenPGP digital signature
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20161230/fe856286/attachment.bin
On Fri, 30/12/2016 at 14.30 -0500, Chris PeBenito wrote:
> On 12/29/16 17:49, Guido Trentalancia via refpolicy wrote:
> >
> > Update the initrc_t domain policy in the init module with some
> > missing permissions.
> >
> > Signed-off-by: Guido Trentalancia <[email protected]>
> > ---
> > ?policy/modules/kernel/terminal.if |???21 +++++++++++++++++++++
> > ?policy/modules/system/init.te?????|???19 +++++++++++++++++--
> > ?2 files changed, 38 insertions(+), 2 deletions(-)
> >
> > diff -pru a/policy/modules/kernel/terminal.if
> > b/policy/modules/kernel/terminal.if
> > --- a/policy/modules/kernel/terminal.if 2016-12-27
> > 22:41:00.664390360 +0100
> > +++ b/policy/modules/kernel/terminal.if 2016-12-29
> > 23:30:56.342306506 +0100
> > @@ -1102,6 +1102,27 @@ interface(`term_relabel_all_user_ptys',`
> >
> > ?########################################
> > ?## <summary>
> > +## Unlink BSD-style pty device
> > +## nodes.
> > +## </summary>
> > +## <param name="domain">
> > +## <summary>
> > +## Domain allowed access.
> > +## </summary>
> > +## </param>
> > +## <rolecap/>
> > +#
> > +interface(`term_unlink_bsd_ptys',`
> > + gen_require(`
> > + type bsdpty_device_t;
> > + ')
> > +
> > + dev_list_all_dev_nodes($1)
> > + allow $1 bsdpty_device_t:chr_file { unlink };
> > +')
> > +
> > +########################################
> > +## <summary>
> > ?## Get the attributes of all unallocated
> > ?## tty device nodes.
> > ?## </summary>
> > diff -pru a/policy/modules/system/init.te
> > b/policy/modules/system/init.te
> > --- a/policy/modules/system/init.te 2016-12-29
> > 22:48:16.456818544 +0100
> > +++ b/policy/modules/system/init.te 2016-12-29
> > 23:44:28.212518135 +0100
[...]
> > ?files_create_lock_dirs(initrc_t)
> > ?files_pid_filetrans_lock_dir(initrc_t, "lock")
> > ?files_read_kernel_symbol_table(initrc_t)
> > @@ -462,6 +466,8 @@ dev_getattr_all_blk_files(initrc_t)
> > ?dev_getattr_all_chr_files(initrc_t)
> > ?# Early devtmpfs
> > ?dev_rw_generic_chr_files(initrc_t)
> > +# mcelog service
> > +dev_read_kmsg(initrc_t)
>
> mcelog is a service, so it shouldn't be running in initrc_t.
You see, unfortunately, the mcelog.init script, has a limitation in
that sense because it checks that /dev/mcelog is readable otherwise it
exits without starting the mcelog service.
It's not a bug strictly speaking, however, it causes such limitation in
the security domain.
Of course, mcelog then runs in its own domain...
Regards,
Guido
On 12/30/2016 09:15 PM, Guido Trentalancia via refpolicy wrote:
> On Fri, 30/12/2016 at 14.30 -0500, Chris PeBenito wrote:
>> On 12/29/16 17:49, Guido Trentalancia via refpolicy wrote:
>>>
>>> Update the initrc_t domain policy in the init module with some
>>> missing permissions.
>>>
>>> Signed-off-by: Guido Trentalancia <[email protected]>
>>> ---
>>> policy/modules/kernel/terminal.if | 21 +++++++++++++++++++++
>>> policy/modules/system/init.te | 19 +++++++++++++++++--
>>> 2 files changed, 38 insertions(+), 2 deletions(-)
>>>
>>> diff -pru a/policy/modules/kernel/terminal.if
>>> b/policy/modules/kernel/terminal.if
>>> --- a/policy/modules/kernel/terminal.if 2016-12-27
>>> 22:41:00.664390360 +0100
>>> +++ b/policy/modules/kernel/terminal.if 2016-12-29
>>> 23:30:56.342306506 +0100
>>> @@ -1102,6 +1102,27 @@ interface(`term_relabel_all_user_ptys',`
>>>
>>> ########################################
>>> ## <summary>
>>> +## Unlink BSD-style pty device
>>> +## nodes.
>>> +## </summary>
>>> +## <param name="domain">
>>> +## <summary>
>>> +## Domain allowed access.
>>> +## </summary>
>>> +## </param>
>>> +## <rolecap/>
>>> +#
>>> +interface(`term_unlink_bsd_ptys',`
>>> + gen_require(`
>>> + type bsdpty_device_t;
>>> + ')
>>> +
>>> + dev_list_all_dev_nodes($1)
>>> + allow $1 bsdpty_device_t:chr_file { unlink };
>>> +')
>>> +
>>> +########################################
>>> +## <summary>
>>> ## Get the attributes of all unallocated
>>> ## tty device nodes.
>>> ## </summary>
>>> diff -pru a/policy/modules/system/init.te
>>> b/policy/modules/system/init.te
>>> --- a/policy/modules/system/init.te 2016-12-29
>>> 22:48:16.456818544 +0100
>>> +++ b/policy/modules/system/init.te 2016-12-29
>>> 23:44:28.212518135 +0100
>
> [...]
>
>>> files_create_lock_dirs(initrc_t)
>>> files_pid_filetrans_lock_dir(initrc_t, "lock")
>>> files_read_kernel_symbol_table(initrc_t)
>>> @@ -462,6 +466,8 @@ dev_getattr_all_blk_files(initrc_t)
>>> dev_getattr_all_chr_files(initrc_t)
>>> # Early devtmpfs
>>> dev_rw_generic_chr_files(initrc_t)
>>> +# mcelog service
>>> +dev_read_kmsg(initrc_t)
>>
>> mcelog is a service, so it shouldn't be running in initrc_t.
>
> You see, unfortunately, the mcelog.init script, has a limitation in
> that sense because it checks that /dev/mcelog is readable otherwise it
> exits without starting the mcelog service.
>
> It's not a bug strictly speaking, however, it causes such limitation in
> the security domain.
how about adding a:
dev_audit_read_access_kmsg()
allow ARG1 kmsg_dev_t:chr_file { getattr read };
>
> Of course, mcelog then runs in its own domain...
>
> Regards,
>
> Guido
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
>
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 648 bytes
Desc: OpenPGP digital signature
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20161230/1933dd40/attachment.bin
On Fri, 30/12/2016 at 21.12 +0100, Dominick Grift via refpolicy wrote:
> On 12/30/2016 09:09 PM, Guido Trentalancia via refpolicy wrote:
> >
> > On Fri, 30/12/2016 at 21.01 +0100, Dominick Grift via refpolicy
> > wrote:
> > >
> > > On 12/30/2016 08:30 PM, Chris PeBenito via refpolicy wrote:
> > > >
> > > >
> > > > On 12/29/16 17:49, Guido Trentalancia via refpolicy wrote:
> > > > >
> > > > >
> > > > > Update the initrc_t domain policy in the init module with
> > > > > some
> > > > > missing permissions.
> > > > >
> > > > > Signed-off-by: Guido Trentalancia <[email protected]>
> > > > > ---
> > > > > ?policy/modules/kernel/terminal.if |???21
> > > > > +++++++++++++++++++++
> > > > > ?policy/modules/system/init.te?????|???19 +++++++++++++++++--
> > > > > ?2 files changed, 38 insertions(+), 2 deletions(-)
[...]
> > > > > +# plymouth
> > > > > +kernel_stream_connect(initrc_t)
> > > >
> > > > Plymouth has a domain, so this seems unnecessary.
> > >
> > > Plymouthd is running from initramfs before policy is loaded. So
> > > once
> > > the
> > > policy gets loaded and root is switched the kernel isid kicks in
> > > and
> > > associates kernel_t with the process
> >
> > Yes, I confirm. Plymouthd is running in the kernel_t domain because
> > it
> > is started before the policy is loaded.
> >
>
> The question is then what is running in initrc_t in that event? is it
> the plymouth client stream connecting to plymouthd?
>
> is the plymouth client an init_system_domain()?
The comment is misleading in some sense. It's plymouthd, I wrote
"plymouth" referring to the package.
I'll fix the comment in the next version.
Regards,
Guido
On 12/30/2016 09:19 PM, Guido Trentalancia via refpolicy wrote:
> On Fri, 30/12/2016 at 21.12 +0100, Dominick Grift via refpolicy wrote:
>> On 12/30/2016 09:09 PM, Guido Trentalancia via refpolicy wrote:
>>>
>>> On Fri, 30/12/2016 at 21.01 +0100, Dominick Grift via refpolicy
>>> wrote:
>>>>
>>>> On 12/30/2016 08:30 PM, Chris PeBenito via refpolicy wrote:
>>>>>
>>>>>
>>>>> On 12/29/16 17:49, Guido Trentalancia via refpolicy wrote:
>>>>>>
>>>>>>
>>>>>> Update the initrc_t domain policy in the init module with
>>>>>> some
>>>>>> missing permissions.
>>>>>>
>>>>>> Signed-off-by: Guido Trentalancia <[email protected]>
>>>>>> ---
>>>>>> policy/modules/kernel/terminal.if | 21
>>>>>> +++++++++++++++++++++
>>>>>> policy/modules/system/init.te | 19 +++++++++++++++++--
>>>>>> 2 files changed, 38 insertions(+), 2 deletions(-)
>
> [...]
>
>>>>>> +# plymouth
>>>>>> +kernel_stream_connect(initrc_t)
>>>>>
>>>>> Plymouth has a domain, so this seems unnecessary.
>>>>
>>>> Plymouthd is running from initramfs before policy is loaded. So
>>>> once
>>>> the
>>>> policy gets loaded and root is switched the kernel isid kicks in
>>>> and
>>>> associates kernel_t with the process
>>>
>>> Yes, I confirm. Plymouthd is running in the kernel_t domain because
>>> it
>>> is started before the policy is loaded.
>>>
>>
>> The question is then what is running in initrc_t in that event? is it
>> the plymouth client stream connecting to plymouthd?
>>
>> is the plymouth client an init_system_domain()?
>
> The comment is misleading in some sense. It's plymouthd, I wrote
> "plymouth" referring to the package.
>
> I'll fix the comment in the next version.
Yes ok, but then why does a process associated with initrc_t need to
stream connect to it?
what is that process running in initrc_t?
>
> Regards,
>
> Guido
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
>
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 648 bytes
Desc: OpenPGP digital signature
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20161230/a3f202b8/attachment.bin
On Fri, 30/12/2016 at 21.20 +0100, Dominick Grift via refpolicy wrote:
> On 12/30/2016 09:19 PM, Guido Trentalancia via refpolicy wrote:
> >
> > On Fri, 30/12/2016 at 21.12 +0100, Dominick Grift via refpolicy
> > wrote:
> > >
> > > On 12/30/2016 09:09 PM, Guido Trentalancia via refpolicy wrote:
> > > >
> > > >
> > > > On Fri, 30/12/2016 at 21.01 +0100, Dominick Grift via refpolicy
> > > > wrote:
> > > > >
> > > > >
> > > > > On 12/30/2016 08:30 PM, Chris PeBenito via refpolicy wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 12/29/16 17:49, Guido Trentalancia via refpolicy wrote:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Update the initrc_t domain policy in the init module with
> > > > > > > some
> > > > > > > missing permissions.
> > > > > > >
> > > > > > > Signed-off-by: Guido Trentalancia <[email protected]
> > > > > > > >
> > > > > > > ---
> > > > > > > ?policy/modules/kernel/terminal.if |???21
> > > > > > > +++++++++++++++++++++
> > > > > > > ?policy/modules/system/init.te?????|???19
> > > > > > > +++++++++++++++++--
> > > > > > > ?2 files changed, 38 insertions(+), 2 deletions(-)
> >
> > [...]
> >
> > >
> > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > > +# plymouth
> > > > > > > +kernel_stream_connect(initrc_t)
> > > > > >
> > > > > > Plymouth has a domain, so this seems unnecessary.
> > > > >
> > > > > Plymouthd is running from initramfs before policy is loaded.
> > > > > So
> > > > > once
> > > > > the
> > > > > policy gets loaded and root is switched the kernel isid kicks
> > > > > in
> > > > > and
> > > > > associates kernel_t with the process
> > > >
> > > > Yes, I confirm. Plymouthd is running in the kernel_t domain
> > > > because
> > > > it
> > > > is started before the policy is loaded.
> > > >
> > >
> > > The question is then what is running in initrc_t in that event?
> > > is it
> > > the plymouth client stream connecting to plymouthd?
> > >
> > > is the plymouth client an init_system_domain()?
> >
> > The comment is misleading in some sense. It's plymouthd, I wrote
> > "plymouth" referring to the package.
> >
> > I'll fix the comment in the next version.
>
> Yes ok, but then why does a process associated with initrc_t need to
> stream connect to it?
>
> what is that process running in initrc_t?
It's actually the other way around. The comment is correct.
The client is eventually running in initrc_t...
Such permission is absolutely necessary for the correct functioning of
the plymouth terminal interface.
Regards,
Guido
On 12/30/2016 09:50 PM, Guido Trentalancia via refpolicy wrote:
> On Fri, 30/12/2016 at 21.20 +0100, Dominick Grift via refpolicy wrote:
>> On 12/30/2016 09:19 PM, Guido Trentalancia via refpolicy wrote:
>>>
>>> On Fri, 30/12/2016 at 21.12 +0100, Dominick Grift via refpolicy
>>> wrote:
>>>>
>>>> On 12/30/2016 09:09 PM, Guido Trentalancia via refpolicy wrote:
>>>>>
>>>>>
>>>>> On Fri, 30/12/2016 at 21.01 +0100, Dominick Grift via refpolicy
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> On 12/30/2016 08:30 PM, Chris PeBenito via refpolicy wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 12/29/16 17:49, Guido Trentalancia via refpolicy wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Update the initrc_t domain policy in the init module with
>>>>>>>> some
>>>>>>>> missing permissions.
>>>>>>>>
>>>>>>>> Signed-off-by: Guido Trentalancia <[email protected]
>>>>>>>>>
>>>>>>>> ---
>>>>>>>> policy/modules/kernel/terminal.if | 21
>>>>>>>> +++++++++++++++++++++
>>>>>>>> policy/modules/system/init.te | 19
>>>>>>>> +++++++++++++++++--
>>>>>>>> 2 files changed, 38 insertions(+), 2 deletions(-)
>>>
>>> [...]
>>>
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> +# plymouth
>>>>>>>> +kernel_stream_connect(initrc_t)
>>>>>>>
>>>>>>> Plymouth has a domain, so this seems unnecessary.
>>>>>>
>>>>>> Plymouthd is running from initramfs before policy is loaded.
>>>>>> So
>>>>>> once
>>>>>> the
>>>>>> policy gets loaded and root is switched the kernel isid kicks
>>>>>> in
>>>>>> and
>>>>>> associates kernel_t with the process
>>>>>
>>>>> Yes, I confirm. Plymouthd is running in the kernel_t domain
>>>>> because
>>>>> it
>>>>> is started before the policy is loaded.
>>>>>
>>>>
>>>> The question is then what is running in initrc_t in that event?
>>>> is it
>>>> the plymouth client stream connecting to plymouthd?
>>>>
>>>> is the plymouth client an init_system_domain()?
>>>
>>> The comment is misleading in some sense. It's plymouthd, I wrote
>>> "plymouth" referring to the package.
>>>
>>> I'll fix the comment in the next version.
>>
>> Yes ok, but then why does a process associated with initrc_t need to
>> stream connect to it?
>>
>> what is that process running in initrc_t?
>
> It's actually the other way around. The comment is correct.
>
> The client is eventually running in initrc_t...
>
> Such permission is absolutely necessary for the correct functioning of
> the plymouth terminal interface.
ok then i believe you should instead add:
init_system_domain(plymouth_t, plymouth_exec_t)
or somthing along those lines
>
> Regards,
>
> Guido
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
>
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 648 bytes
Desc: OpenPGP digital signature
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20161230/50f33dfa/attachment-0001.bin
On Fri, 30/12/2016 at 21.15 +0100, Guido Trentalancia via refpolicy
wrote:
> On Fri, 30/12/2016 at 14.30 -0500, Chris PeBenito wrote:
> >
> > On 12/29/16 17:49, Guido Trentalancia via refpolicy wrote:
> > >
> > >
> > > Update the initrc_t domain policy in the init module with some
> > > missing permissions.
> > >
> > > Signed-off-by: Guido Trentalancia <[email protected]>
> > > ---
> > > ?policy/modules/kernel/terminal.if |???21 +++++++++++++++++++++
> > > ?policy/modules/system/init.te?????|???19 +++++++++++++++++--
> > > ?2 files changed, 38 insertions(+), 2 deletions(-)
> > >
> > > diff -pru a/policy/modules/kernel/terminal.if
> > > b/policy/modules/kernel/terminal.if
> > > --- a/policy/modules/kernel/terminal.if 2016-12-27
> > > 22:41:00.664390360 +0100
> > > +++ b/policy/modules/kernel/terminal.if 2016-12-29
> > > 23:30:56.342306506 +0100
> > > @@ -1102,6 +1102,27 @@ interface(`term_relabel_all_user_ptys',`
> > >
> > > ?########################################
> > > ?## <summary>
> > > +## Unlink BSD-style pty device
> > > +## nodes.
> > > +## </summary>
> > > +## <param name="domain">
> > > +## <summary>
> > > +## Domain allowed access.
> > > +## </summary>
> > > +## </param>
> > > +## <rolecap/>
> > > +#
> > > +interface(`term_unlink_bsd_ptys',`
> > > + gen_require(`
> > > + type bsdpty_device_t;
> > > + ')
> > > +
> > > + dev_list_all_dev_nodes($1)
> > > + allow $1 bsdpty_device_t:chr_file { unlink };
> > > +')
> > > +
> > > +########################################
> > > +## <summary>
> > > ?## Get the attributes of all unallocated
> > > ?## tty device nodes.
> > > ?## </summary>
> > > diff -pru a/policy/modules/system/init.te
> > > b/policy/modules/system/init.te
> > > --- a/policy/modules/system/init.te 2016-12-29
> > > 22:48:16.456818544 +0100
> > > +++ b/policy/modules/system/init.te 2016-12-29
> > > 23:44:28.212518135 +0100
>
> [...]
>
> >
> > >
> > > ?files_create_lock_dirs(initrc_t)
> > > ?files_pid_filetrans_lock_dir(initrc_t, "lock")
> > > ?files_read_kernel_symbol_table(initrc_t)
> > > @@ -462,6 +466,8 @@ dev_getattr_all_blk_files(initrc_t)
> > > ?dev_getattr_all_chr_files(initrc_t)
> > > ?# Early devtmpfs
> > > ?dev_rw_generic_chr_files(initrc_t)
> > > +# mcelog service
> > > +dev_read_kmsg(initrc_t)
> >
> > mcelog is a service, so it shouldn't be running in initrc_t.
>
> You see, unfortunately, the mcelog.init script, has a limitation in
> that sense because it checks that /dev/mcelog is readable otherwise
> it
> exits without starting the mcelog service.
>
> It's not a bug strictly speaking, however, it causes such limitation
> in
> the security domain.
>
> Of course, mcelog then runs in its own domain...
Actually, the mcelog init script does not exit, however it prints an
(annoying and false) error message about /dev/mcelog not being active !
I think we'd better keep the dev_read_kmsg(initrc_t) permission,
although theoretically it could be removed.
Regards,
Guido
On Fri, 30/12/2016 at 21.52 +0100, Dominick Grift via refpolicy wrote:
> On 12/30/2016 09:50 PM, Guido Trentalancia via refpolicy wrote:
[...]
> > > > > > > > >
> > > > > > > > > +# plymouth
> > > > > > > > > +kernel_stream_connect(initrc_t)
> > > > > > > >
> > > > > > > > Plymouth has a domain, so this seems unnecessary.
> > > > > > >
> > > > > > > Plymouthd is running from initramfs before policy is
> > > > > > > loaded.
> > > > > > > So
> > > > > > > once
> > > > > > > the
> > > > > > > policy gets loaded and root is switched the kernel isid
> > > > > > > kicks
> > > > > > > in
> > > > > > > and
> > > > > > > associates kernel_t with the process
> > > > > >
> > > > > > Yes, I confirm. Plymouthd is running in the kernel_t domain
> > > > > > because
> > > > > > it
> > > > > > is started before the policy is loaded.
> > > > > >
> > > > >
> > > > > The question is then what is running in initrc_t in that
> > > > > event?
> > > > > is it
> > > > > the plymouth client stream connecting to plymouthd?
> > > > >
> > > > > is the plymouth client an init_system_domain()?
> > > >
> > > > The comment is misleading in some sense. It's plymouthd, I
> > > > wrote
> > > > "plymouth" referring to the package.
> > > >
> > > > I'll fix the comment in the next version.
> > >
> > > Yes ok, but then why does a process associated with initrc_t need
> > > to
> > > stream connect to it?
> > >
> > > what is that process running in initrc_t?
> >
> > It's actually the other way around. The comment is correct.
> >
> > The client is eventually running in initrc_t...
> >
> > Such permission is absolutely necessary for the correct functioning
> > of
> > the plymouth terminal interface.
>
> ok then i believe you should instead add:
>
> init_system_domain(plymouth_t, plymouth_exec_t)
>
> or somthing along those lines
Yes, the above works and is the correct solution, thanks for the tip.
This leads to a new patch for the plymouth module...
Regards,
Guido
On 12/30/2016 10:06 PM, Guido Trentalancia via refpolicy wrote:
> On Fri, 30/12/2016 at 21.52 +0100, Dominick Grift via refpolicy wrote:
>> On 12/30/2016 09:50 PM, Guido Trentalancia via refpolicy wrote:
>
> [...]
>
>>>>>>>>>>
>>>>>>>>>> +# plymouth
>>>>>>>>>> +kernel_stream_connect(initrc_t)
>>>>>>>>>
>>>>>>>>> Plymouth has a domain, so this seems unnecessary.
>>>>>>>>
>>>>>>>> Plymouthd is running from initramfs before policy is
>>>>>>>> loaded.
>>>>>>>> So
>>>>>>>> once
>>>>>>>> the
>>>>>>>> policy gets loaded and root is switched the kernel isid
>>>>>>>> kicks
>>>>>>>> in
>>>>>>>> and
>>>>>>>> associates kernel_t with the process
>>>>>>>
>>>>>>> Yes, I confirm. Plymouthd is running in the kernel_t domain
>>>>>>> because
>>>>>>> it
>>>>>>> is started before the policy is loaded.
>>>>>>>
>>>>>>
>>>>>> The question is then what is running in initrc_t in that
>>>>>> event?
>>>>>> is it
>>>>>> the plymouth client stream connecting to plymouthd?
>>>>>>
>>>>>> is the plymouth client an init_system_domain()?
>>>>>
>>>>> The comment is misleading in some sense. It's plymouthd, I
>>>>> wrote
>>>>> "plymouth" referring to the package.
>>>>>
>>>>> I'll fix the comment in the next version.
>>>>
>>>> Yes ok, but then why does a process associated with initrc_t need
>>>> to
>>>> stream connect to it?
>>>>
>>>> what is that process running in initrc_t?
>>>
>>> It's actually the other way around. The comment is correct.
>>>
>>> The client is eventually running in initrc_t...
>>>
>>> Such permission is absolutely necessary for the correct functioning
>>> of
>>> the plymouth terminal interface.
>>
>> ok then i believe you should instead add:
>>
>> init_system_domain(plymouth_t, plymouth_exec_t)
>>
>> or somthing along those lines
>
> Yes, the above works and is the correct solution, thanks for the tip.
>
> This leads to a new patch for the plymouth module...
So plymouth client stream connects to plymouthd (running with kernel_t
because it was already running when the policy got loaded)
>
> Regards,
>
> Guido
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
>
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 648 bytes
Desc: OpenPGP digital signature
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20161230/2f76e8e0/attachment.bin
Hello again.
> On the 30th of December 2016 at 20.30 Chris PeBenito <[email protected]>
> wrote:
>
>
> On 12/29/16 17:49, Guido Trentalancia via refpolicy wrote:
> > Update the initrc_t domain policy in the init module with some
> > missing permissions.
> >
> > Signed-off-by: Guido Trentalancia <[email protected]>
> > ---
> > policy/modules/kernel/terminal.if | 21 +++++++++++++++++++++
> > policy/modules/system/init.te | 19 +++++++++++++++++--
> > 2 files changed, 38 insertions(+), 2 deletions(-)
[...]
> > domain_kill_all_domains(initrc_t)
> > domain_signal_all_domains(initrc_t)
> > @@ -496,6 +502,8 @@ files_exec_etc_files(initrc_t)
> > files_read_usr_files(initrc_t)
> > files_manage_urandom_seed(initrc_t)
> > files_manage_generic_spool(initrc_t)
> > +# manage the restorecond lock file
> > +files_manage_generic_locks(initrc_t)
>
> initrc_t can already delete all locks. Why does it need to create locks?
The init scripts usually create the lock file upon starting up the service (and
delete it when stopping the service).
If you look at the script file restorecond.init from
policycoreutils/restorecond, you'll find the following:
touch /var/lock/subsys/restorecond
which implies files_manage_generic_locks(initrc_t).
I hope it helps...
Regards,
Guido
Update the initrc_t domain policy in the init module with some
missing permissions.
Signed-off-by: Guido Trentalancia <[email protected]>
---
policy/modules/kernel/terminal.if | 21 +++++++++++++++++++++
policy/modules/system/init.te | 15 +++++++++++++--
2 files changed, 34 insertions(+), 2 deletions(-)
diff -pru a/policy/modules/kernel/terminal.if
b/policy/modules/kernel/terminal.if
--- a/policy/modules/kernel/terminal.if 2016-12-27 22:41:00.664390360 +0100
+++ b/policy/modules/kernel/terminal.if 2016-12-30 23:17:49.135396217 +0100
@@ -1102,6 +1102,27 @@ interface(`term_relabel_all_user_ptys',`
########################################
## <summary>
+## Unlink BSD-style pty device
+## nodes.
+## </summary>
+## <param name="domain">
+## <summary>
+## Domain allowed access.
+## </summary>
+## </param>
+## <rolecap/>
+#
+interface(`term_unlink_bsd_ptys',`
+ gen_require(`
+ type bsdpty_device_t;
+ ')
+
+ dev_list_all_dev_nodes($1)
+ allow $1 bsdpty_device_t:chr_file { unlink };
+')
+
+########################################
+## <summary>
## Get the attributes of all unallocated
## tty device nodes.
## </summary>
diff -pru a/policy/modules/system/init.te b/policy/modules/system/init.te
--- a/policy/modules/system/init.te 2016-12-29 22:48:16.456818544 +0100
+++ b/policy/modules/system/init.te 2016-12-30 23:18:06.332953421 +0100
@@ -415,6 +415,7 @@ kernel_clear_ring_buffer(initrc_t)
kernel_get_sysvipc_info(initrc_t)
kernel_read_all_sysctls(initrc_t)
kernel_rw_all_sysctls(initrc_t)
+kernel_use_fds(initrc_t)
# for lsof which is used by alsa shutdown:
kernel_dontaudit_getattr_message_if(initrc_t)
# cjp: not sure why these are here; should use mount policy
@@ -462,6 +463,8 @@ dev_getattr_all_blk_files(initrc_t)
dev_getattr_all_chr_files(initrc_t)
# Early devtmpfs
dev_rw_generic_chr_files(initrc_t)
+# mcelog service
+dev_read_kmsg(initrc_t)
domain_kill_all_domains(initrc_t)
domain_signal_all_domains(initrc_t)
@@ -496,6 +499,8 @@ files_exec_etc_files(initrc_t)
files_read_usr_files(initrc_t)
files_manage_urandom_seed(initrc_t)
files_manage_generic_spool(initrc_t)
+# manage the restorecond lock file
+files_manage_generic_locks(initrc_t)
# Mount and unmount file systems.
# cjp: not sure why these are here; should use mount policy
files_list_default(initrc_t)
@@ -532,10 +537,12 @@ storage_setattr_removable_dev(initrc_t)
term_use_all_terms(initrc_t)
term_reset_tty_labels(initrc_t)
+term_unlink_bsd_ptys(initrc_t)
auth_rw_login_records(initrc_t)
auth_setattr_login_records(initrc_t)
auth_rw_lastlog(initrc_t)
+auth_manage_faillog(initrc_t)
auth_read_pam_pid(initrc_t)
auth_delete_pam_pid(initrc_t)
auth_delete_pam_console_data(initrc_t)
@@ -831,12 +838,12 @@ optional_policy(`
')
optional_policy(`
- dev_getattr_printer_dev(initrc_t)
-
cups_read_log(initrc_t)
cups_read_rw_config(initrc_t)
#cups init script clears error log
cups_write_log(initrc_t)
+
+ dev_getattr_printer_dev(initrc_t)
')
optional_policy(`
@@ -900,6 +907,10 @@ optional_policy(`
')
optional_policy(`
+ iptables_read_config(initrc_t)
+')
+
+optional_policy(`
iscsi_stream_connect(initrc_t)
iscsi_read_lib_files(initrc_t)
')
On 12/30/16 15:53, Guido Trentalancia via refpolicy wrote:
> On Fri, 30/12/2016 at 21.15 +0100, Guido Trentalancia via refpolicy
> wrote:
>> On Fri, 30/12/2016 at 14.30 -0500, Chris PeBenito wrote:
>>> On 12/29/16 17:49, Guido Trentalancia via refpolicy wrote:
>>>> @@ -462,6 +466,8 @@ dev_getattr_all_blk_files(initrc_t)
>>>> dev_getattr_all_chr_files(initrc_t)
>>>> # Early devtmpfs
>>>> dev_rw_generic_chr_files(initrc_t)
>>>> +# mcelog service
>>>> +dev_read_kmsg(initrc_t)
>>>
>>> mcelog is a service, so it shouldn't be running in initrc_t.
>>
>> You see, unfortunately, the mcelog.init script, has a limitation in
>> that sense because it checks that /dev/mcelog is readable otherwise
>> it
>> exits without starting the mcelog service.
>>
>> It's not a bug strictly speaking, however, it causes such limitation
>> in
>> the security domain.
>>
>> Of course, mcelog then runs in its own domain...
>
> Actually, the mcelog init script does not exit, however it prints an
> (annoying and false) error message about /dev/mcelog not being active !
>
> I think we'd better keep the dev_read_kmsg(initrc_t) permission,
> although theoretically it could be removed.
Which distro is this on? The Gentoo init script doesn't do that.
--
Chris PeBenito
Hello !
On Sat, 31/12/2016 at 10.43 -0500, Chris PeBenito wrote:
> On 12/30/16 15:53, Guido Trentalancia via refpolicy wrote:
> >
> > On Fri, 30/12/2016 at 21.15 +0100, Guido Trentalancia via refpolicy
> > wrote:
> > >
> > > On Fri, 30/12/2016 at 14.30 -0500, Chris PeBenito wrote:
> > > >
> > > > On 12/29/16 17:49, Guido Trentalancia via refpolicy wrote:
>
> >
> > >
> > > >
> > > > >
> > > > > @@ -462,6 +466,8 @@ dev_getattr_all_blk_files(initrc_t)
> > > > > ?dev_getattr_all_chr_files(initrc_t)
> > > > > ?# Early devtmpfs
> > > > > ?dev_rw_generic_chr_files(initrc_t)
> > > > > +# mcelog service
> > > > > +dev_read_kmsg(initrc_t)
> > > >
> > > > mcelog is a service, so it shouldn't be running in initrc_t.
> > >
> > > You see, unfortunately, the mcelog.init script, has a limitation
> > > in
> > > that sense because it checks that /dev/mcelog is readable
> > > otherwise
> > > it
> > > exits without starting the mcelog service.
> > >
> > > It's not a bug strictly speaking, however, it causes such
> > > limitation
> > > in
> > > the security domain.
> > >
> > > Of course, mcelog then runs in its own domain...
> >
> > Actually, the mcelog init script does not exit, however it prints
> > an
> > (annoying and false) error message about /dev/mcelog not being
> > active !
> >
> > I think we'd better keep the dev_read_kmsg(initrc_t) permission,
> > although theoretically it could be removed.
>
> Which distro is this on???The Gentoo init script doesn't do that.
It is latest mcelog release and latest mcelog git.
Regards,
Guido
On 12/31/16 11:05, Guido Trentalancia via refpolicy wrote:
> Hello !
>
> On Sat, 31/12/2016 at 10.43 -0500, Chris PeBenito wrote:
>> On 12/30/16 15:53, Guido Trentalancia via refpolicy wrote:
>>>
>>> On Fri, 30/12/2016 at 21.15 +0100, Guido Trentalancia via refpolicy
>>> wrote:
>>>>
>>>> On Fri, 30/12/2016 at 14.30 -0500, Chris PeBenito wrote:
>>>>>
>>>>> On 12/29/16 17:49, Guido Trentalancia via refpolicy wrote:
>>
>>>
>>>>
>>>>>
>>>>>>
>>>>>> @@ -462,6 +466,8 @@ dev_getattr_all_blk_files(initrc_t)
>>>>>> dev_getattr_all_chr_files(initrc_t)
>>>>>> # Early devtmpfs
>>>>>> dev_rw_generic_chr_files(initrc_t)
>>>>>> +# mcelog service
>>>>>> +dev_read_kmsg(initrc_t)
>>>>>
>>>>> mcelog is a service, so it shouldn't be running in initrc_t.
>>>>
>>>> You see, unfortunately, the mcelog.init script, has a limitation
>>>> in
>>>> that sense because it checks that /dev/mcelog is readable
>>>> otherwise
>>>> it
>>>> exits without starting the mcelog service.
>>>>
>>>> It's not a bug strictly speaking, however, it causes such
>>>> limitation
>>>> in
>>>> the security domain.
>>>>
>>>> Of course, mcelog then runs in its own domain...
>>>
>>> Actually, the mcelog init script does not exit, however it prints
>>> an
>>> (annoying and false) error message about /dev/mcelog not being
>>> active !
>>>
>>> I think we'd better keep the dev_read_kmsg(initrc_t) permission,
>>> although theoretically it could be removed.
>>
>> Which distro is this on? The Gentoo init script doesn't do that.
>
> It is latest mcelog release and latest mcelog git.
The point is that systemd systems probably don't need this access, nor
does Gentoo, so which distro does?
--
Chris PeBenito
On Sat, 31/12/2016 at 11.22 -0500, Chris PeBenito wrote:
> On 12/31/16 11:05, Guido Trentalancia via refpolicy wrote:
> >
> > Hello !
> >
> > On Sat, 31/12/2016 at 10.43 -0500, Chris PeBenito wrote:
> > >
> > > On 12/30/16 15:53, Guido Trentalancia via refpolicy wrote:
> > > >
> > > >
> > > > On Fri, 30/12/2016 at 21.15 +0100, Guido Trentalancia via
> > > > refpolicy
> > > > wrote:
> > > > >
> > > > >
> > > > > On Fri, 30/12/2016 at 14.30 -0500, Chris PeBenito wrote:
> > > > > >
> > > > > >
> > > > > > On 12/29/16 17:49, Guido Trentalancia via refpolicy wrote:
> > >
> > > >
> > > >
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > @@ -462,6 +466,8 @@ dev_getattr_all_blk_files(initrc_t)
> > > > > > > ?dev_getattr_all_chr_files(initrc_t)
> > > > > > > ?# Early devtmpfs
> > > > > > > ?dev_rw_generic_chr_files(initrc_t)
> > > > > > > +# mcelog service
> > > > > > > +dev_read_kmsg(initrc_t)
> > > > > >
> > > > > > mcelog is a service, so it shouldn't be running in
> > > > > > initrc_t.
> > > > >
> > > > > You see, unfortunately, the mcelog.init script, has a
> > > > > limitation
> > > > > in
> > > > > that sense because it checks that /dev/mcelog is readable
> > > > > otherwise
> > > > > it
> > > > > exits without starting the mcelog service.
> > > > >
> > > > > It's not a bug strictly speaking, however, it causes such
> > > > > limitation
> > > > > in
> > > > > the security domain.
> > > > >
> > > > > Of course, mcelog then runs in its own domain...
> > > >
> > > > Actually, the mcelog init script does not exit, however it
> > > > prints
> > > > an
> > > > (annoying and false) error message about /dev/mcelog not being
> > > > active !
> > > >
> > > > I think we'd better keep the dev_read_kmsg(initrc_t)
> > > > permission,
> > > > although theoretically it could be removed.
> > >
> > > Which distro is this on???The Gentoo init script doesn't do that.
> >
> > It is latest mcelog release and latest mcelog git.
>
> The point is that systemd systems probably don't need this access,
> nor?
> does Gentoo, so which distro does?
I do not know precisely.
All systems that do not modify the original mcelog init script are
affected.
Regards,
Guido