From: guido@trentalancia.net (Guido Trentalancia) Date: Sat, 31 Dec 2016 18:42:32 +0100 Subject: [refpolicy] [PATCH v2] init: support sysvinit (was "run sysvinit without the dangerous unconfined_domain() call") In-Reply-To: <1483132224.2893.5.camel@trentalancia.net> References: <1425370720.18751.1482877006863.JavaMail.open-xchange@popper10.register.it> <20161227233846.6ed0ebf0@gentp.lnet> <1320659434.14525.1482879298312.JavaMail.open-xchange@popper05.register.it> <20161228000230.798bf64d@gentp.lnet> <1482957927.2738.12.camel@trentalancia.net> <1483132224.2893.5.camel@trentalancia.net> Message-ID: <1483206152.10088.0.camel@trentalancia.net> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com Hello again. On Fri, 30/12/2016 at 22.10 +0100, Guido Trentalancia via refpolicy wrote: > On Fri, 30/12/2016 at 14.24 -0500, Chris PeBenito wrote: > > > > On 12/28/16 15:45, Guido Trentalancia via refpolicy wrote: > > > > > > > > > Originally the aim of this patch was to start securing the init > > > module so that it could run in confined mode instead of in the > > > most unsafe unconfined mode and therefore the patch was removing > > > the call to unconfined_domain(). > > > > > > However, the removal of the unconfined_domain() call has been > > > rejected on the basis of the fact that it can be avoided by not > > > loading the "unconfined" policy module (which unfortunately at > > > the moment, still gets added to the configuration file during > > > "make conf"). > > > > > > Currently, this second version of the patch no longer removes the > > > call to unconfined_domain() and it only adds permissions needed > > > by sysvinit (most notably the ability to load the policy during > > > the system boot). > > > > > > Signed-off-by: Guido Trentalancia > > > --- > > > ?policy/modules/kernel/devices.if |???18 ++++++++++++++++++ > > > ?policy/modules/kernel/kernel.if??|???18 ++++++++++++++++++ > > > ?policy/modules/system/init.te????|????7 +++++++ > > > ?3 files changed, 43 insertions(+) [...] > > > diff -pru a/policy/modules/system/init.te > > > b/policy/modules/system/init.te > > > --- a/policy/modules/system/init.te 2016-12-22 > > > 23:12:47.784929729 +0100 > > > +++ b/policy/modules/system/init.te 2016-12-27 > > > 23:05:37.731451479 +0100 > > > @@ -134,6 +134,8 @@ dev_filetrans(init_t, initctl_t, fifo_fi > > > ?# Modify utmp. > > > ?allow init_t initrc_var_run_t:file { rw_file_perms setattr }; > > > > > > +kernel_mounton_proc_dirs(init_t) > > > +kernel_mount_proc(init_t) > > > ?kernel_read_system_state(init_t) > > > ?kernel_share_state(init_t) > > > ?kernel_dontaudit_search_unlabeled(init_t) > > > @@ -141,6 +143,8 @@ kernel_dontaudit_search_unlabeled(init_t > > > ?corecmd_exec_chroot(init_t) > > > ?corecmd_exec_bin(init_t) > > > > > > +dev_mounton_sysfs(init_t) > > > +dev_mount_sysfs(init_t) > > > ?dev_read_sysfs(init_t) > > > ?# Early devtmpfs > > > ?dev_rw_generic_chr_files(init_t) > > > @@ -162,6 +166,7 @@ files_exec_etc_files(init_t) > > > ?files_dontaudit_rw_root_files(init_t) > > > ?files_dontaudit_rw_root_chr_files(init_t) > > > > > > +fs_getattr_xattr_fs(init_t) > > > ?fs_list_inotifyfs(init_t) > > > ?# cjp: this may be related to /dev/log > > > ?fs_write_ramfs_sockets(init_t) > > > @@ -174,6 +179,8 @@ mls_file_write_all_levels(init_t) > > > ?mls_process_write_all_levels(init_t) > > > ?mls_fd_use_all_levels(init_t) > > > > > > +selinux_load_policy(init_t) > > > +selinux_mount_fs(init_t) > > > ?selinux_set_all_booleans(init_t) > > > > > > ?term_use_all_terms(init_t) > > > > I'm not clear why this is necessary.??Sysvinit should only be > > loading? > > the policy if is not loaded yet, so these permissions should be > > unnecessary. > > The init daemon absolutely needs to load the SELinux policy ! > > Perhaps, it is possible to get rid of the other similar permission in > the kernel module, but surely not here, otherwise the system won't > boot > ?! How about this patch ? The selinux_load_policy() permission is absolutely necessary for the init_t domain, when using sysvinit. Regards, Guido