[refpolicy] [PATCH] Do not keep disabled modules during new policy load

[refpolicy] [PATCH] Do not keep disabled modules during new policy load

[Guido Trentalancia]

When loading a new modular policy, remove all policy modules that
have been previously loaded but have now been explicitly disabled.

If the batch removal process fails, for example because one or more
enabled modules depend on one or more modules to be removed, remove
each module separately (much slower but most effective).

Signed-off-by: Guido Trentalancia <guido@trentalancia.net>
---
 Rules.modular |    6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff -pru a/Rules.modular b/Rules.modular
--- a/Rules.modular	2016-12-15 19:23:50.693731447 +0100
+++ b/Rules.modular	2016-12-15 20:40:42.482313515 +0100
@@ -21,6 +21,7 @@ base_post_te_files := $(user_files) $(po
 base_fc_files := $(base_mods:.te=.fc)
 
 mod_pkgs := $(addprefix $(builddir),$(notdir $(mod_mods:.te=.pp)))
+off_mod_names := $(basename $(off_mods))
 
 # policy packages to install
 instpkg := $(addprefix $(modpkgdir)/,$(notdir $(base_pkg)) $(mod_pkgs))
@@ -48,7 +49,9 @@ install: $(instpkg) $(appfiles)
 
 ########################################
 #
-# Load all configured modules
+# Load all configured modules and remove
+# all modules that have been explicitly
+# disabled
 #
 load: $(instpkg) $(appfiles)
 # make sure two directories exist since they are not
@@ -56,6 +59,7 @@ load: $(instpkg) $(appfiles)
 	@echo "Loading configured modules."
 	@$(INSTALL) -d -m 0755 $(policypath) $(dir $(fcpath))
 	$(verbose) $(SEMODULE) -s $(NAME) -i $(modpkgdir)/$(notdir $(base_pkg)) $(foreach mod,$(mod_pkgs),-i $(modpkgdir)/$(mod))
+	$(verbose) $(SEMODULE) -s $(NAME) -r $(foreach offmod,$(off_mod_names),$(offmod)) || $(foreach offmod,$(off_mod_names),$(SEMODULE) -s $(NAME) -r $(offmod);)
 
 ########################################
 #

[refpolicy] [PATCH v2] Do not keep disabled modules during new policy load

[Guido Trentalancia]

When loading a new modular policy, remove all policy modules that
have been previously loaded but have now been explicitly disabled.

If the batch removal process fails, for example because one or more
enabled modules depend on one or more modules to be removed, remove
each module separately (much slower but most effective).

Signed-off-by: Guido Trentalancia <guido@trentalancia.net>
---
 Rules.modular |    6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff -pru a/Rules.modular b/Rules.modular
--- a/Rules.modular	2016-12-15 19:23:50.693731447 +0100
+++ b/Rules.modular	2016-12-15 20:40:42.482313515 +0100
@@ -21,6 +21,7 @@ base_post_te_files := $(user_files) $(po
 base_fc_files := $(base_mods:.te=.fc)
 
 mod_pkgs := $(addprefix $(builddir),$(notdir $(mod_mods:.te=.pp)))
+off_mod_names := $(basename $(off_mods))
 
 # policy packages to install
 instpkg := $(addprefix $(modpkgdir)/,$(notdir $(base_pkg)) $(mod_pkgs))
@@ -48,7 +49,9 @@ install: $(instpkg) $(appfiles)
 
 ########################################
 #
-# Load all configured modules
+# Load all configured modules and remove
+# all modules that have been explicitly
+# disabled
 #
 load: $(instpkg) $(appfiles)
 # make sure two directories exist since they are not
@@ -56,6 +59,7 @@ load: $(instpkg) $(appfiles)
 	@echo "Loading configured modules."
 	@$(INSTALL) -d -m 0755 $(policypath) $(dir $(fcpath))
 	$(verbose) $(SEMODULE) -s $(NAME) -i $(modpkgdir)/$(notdir $(base_pkg)) $(foreach mod,$(mod_pkgs),-i $(modpkgdir)/$(mod))
+	-$(verbose) $(SEMODULE) -s $(NAME) -r $(foreach offmod,$(off_mod_names),$(offmod)) || $(foreach offmod,$(off_mod_names),$(SEMODULE) -s $(NAME) -r $(offmod);)
 
 ########################################
 #

[refpolicy] [PATCH v2] Do not keep disabled modules during new policy load

[Chris PeBenito]

On 12/15/16 16:04, Guido Trentalancia via refpolicy wrote:
> When loading a new modular policy, remove all policy modules that
> have been previously loaded but have now been explicitly disabled.
>
> If the batch removal process fails, for example because one or more
> enabled modules depend on one or more modules to be removed, remove
> each module separately (much slower but most effective).

The policy makefiles were never meant to do this.  The targets for 
loading modules are just for convenience, and not meant to add another 
layer of policy management to what we already have with semodule/semanage.


> Signed-off-by: Guido Trentalancia <guido@trentalancia.net>
> ---
>  Rules.modular |    6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff -pru a/Rules.modular b/Rules.modular
> --- a/Rules.modular	2016-12-15 19:23:50.693731447 +0100
> +++ b/Rules.modular	2016-12-15 20:40:42.482313515 +0100
> @@ -21,6 +21,7 @@ base_post_te_files := $(user_files) $(po
>  base_fc_files := $(base_mods:.te=.fc)
>
>  mod_pkgs := $(addprefix $(builddir),$(notdir $(mod_mods:.te=.pp)))
> +off_mod_names := $(basename $(off_mods))
>
>  # policy packages to install
>  instpkg := $(addprefix $(modpkgdir)/,$(notdir $(base_pkg)) $(mod_pkgs))
> @@ -48,7 +49,9 @@ install: $(instpkg) $(appfiles)
>
>  ########################################
>  #
> -# Load all configured modules
> +# Load all configured modules and remove
> +# all modules that have been explicitly
> +# disabled
>  #
>  load: $(instpkg) $(appfiles)
>  # make sure two directories exist since they are not
> @@ -56,6 +59,7 @@ load: $(instpkg) $(appfiles)
>  	@echo "Loading configured modules."
>  	@$(INSTALL) -d -m 0755 $(policypath) $(dir $(fcpath))
>  	$(verbose) $(SEMODULE) -s $(NAME) -i $(modpkgdir)/$(notdir $(base_pkg)) $(foreach mod,$(mod_pkgs),-i $(modpkgdir)/$(mod))
> +	-$(verbose) $(SEMODULE) -s $(NAME) -r $(foreach offmod,$(off_mod_names),$(offmod)) || $(foreach offmod,$(off_mod_names),$(SEMODULE) -s $(NAME) -r $(offmod);)
>
>  ########################################
>  #
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
>


-- 
Chris PeBenito

[refpolicy] [PATCH v2] Do not keep disabled modules during new policy load

[Guido Trentalancia]

Hello Christopher !

On Thu, 15/12/2016 at 19.31 -0500, Chris PeBenito wrote:
> On 12/15/16 16:04, Guido Trentalancia via refpolicy wrote:
> > 
> > When loading a new modular policy, remove all policy modules that
> > have been previously loaded but have now been explicitly disabled.
> > 
> > If the batch removal process fails, for example because one or more
> > enabled modules depend on one or more modules to be removed, remove
> > each module separately (much slower but most effective).
> 
> The policy makefiles were never meant to do this.??The targets for?
> loading modules are just for convenience, and not meant to add
> another?
> layer of policy management to what we already have with
> semodule/semanage.

Even if originally it was not designed to provide such facility, it is
never too late to offer something more to the user.

Generally speaking, one would probably expect that the "load" target
only loads modules that are enabled in the policy/modules.conf file and
not modules that are disabled...

By the way, after removing several modules that I do not use, I came
across some strange behaviour of the system, so I wonder if you have
any idea of what is actually going on.

The system became unstable due to several permission denied errors and
it seems like parts of the policy have not been loaded, despite
"semodule -l" shows that the relevant modules are there.

For example:

#?sesearch -t xsession_exec_t -c file -p entrypoint -Ad

shows nothing, while it should show the result of calling the
xserver_xsession_entry_type() interface from?xserver_restricted_role()
which is called by xserver_role() as usual !

Another example is as follows. Despite the domain module is loaded
because "semodule -l" shows that the base is loaded, the following
command:

#?sesearch -s domain -c file -Ad

only shows:

Found 5 semantic av rules:
???allow domain ld_so_t : file { ioctl read getattr execute open } ;?
???allow domain ld_so_cache_t : file { ioctl read getattr lock open }
;?
???allow domain cpu_online_t : file { ioctl read getattr lock open } ;?
???allow domain lib_t : file { ioctl read getattr execute open } ;?
???allow domain textrel_shlib_t : file { ioctl read getattr execute
execmod open } ;?

while I believe is should at least show other "domain self:file"
permissions.

Do you know what is actually going on after I removed the unused
modules ? They were all optional stuff that it is not installed on the
system...

> > Signed-off-by: Guido Trentalancia <guido@trentalancia.net>
> > ---
> > ?Rules.modular |????6 +++++-
> > ?1 file changed, 5 insertions(+), 1 deletion(-)
> > 
> > diff -pru a/Rules.modular b/Rules.modular
> > --- a/Rules.modular	2016-12-15 19:23:50.693731447 +0100
> > +++ b/Rules.modular	2016-12-15 20:40:42.482313515 +0100
> > @@ -21,6 +21,7 @@ base_post_te_files := $(user_files) $(po
> > ?base_fc_files := $(base_mods:.te=.fc)
> > 
> > ?mod_pkgs := $(addprefix $(builddir),$(notdir $(mod_mods:.te=.pp)))
> > +off_mod_names := $(basename $(off_mods))
> > 
> > ?# policy packages to install
> > ?instpkg := $(addprefix $(modpkgdir)/,$(notdir $(base_pkg))
> > $(mod_pkgs))
> > @@ -48,7 +49,9 @@ install: $(instpkg) $(appfiles)
> > 
> > ?########################################
> > ?#
> > -# Load all configured modules
> > +# Load all configured modules and remove
> > +# all modules that have been explicitly
> > +# disabled
> > ?#
> > ?load: $(instpkg) $(appfiles)
> > ?# make sure two directories exist since they are not
> > @@ -56,6 +59,7 @@ load: $(instpkg) $(appfiles)
> > ?	@echo "Loading configured modules."
> > ?	@$(INSTALL) -d -m 0755 $(policypath) $(dir $(fcpath))
> > ?	$(verbose) $(SEMODULE) -s $(NAME) -i $(modpkgdir)/$(notdir
> > $(base_pkg)) $(foreach mod,$(mod_pkgs),-i $(modpkgdir)/$(mod))
> > +	-$(verbose) $(SEMODULE) -s $(NAME) -r $(foreach
> > offmod,$(off_mod_names),$(offmod)) || $(foreach
> > offmod,$(off_mod_names),$(SEMODULE) -s $(NAME) -r $(offmod);)
> > 
> > ?########################################
> > ?#

Regards,

Guido

[refpolicy] [PATCH v2] Do not keep disabled modules during new policy load

[Guido Trentalancia]

On Fri, 16/12/2016 at 18.18 +0100, Guido Trentalancia via refpolicy
wrote:
> Hello Christopher !
> 
> On Thu, 15/12/2016 at 19.31 -0500, Chris PeBenito wrote:
> > 
> > On 12/15/16 16:04, Guido Trentalancia via refpolicy wrote:
> > > 
> > > 
> > > When loading a new modular policy, remove all policy modules that
> > > have been previously loaded but have now been explicitly
> > > disabled.
> > > 
> > > If the batch removal process fails, for example because one or
> > > more
> > > enabled modules depend on one or more modules to be removed,
> > > remove
> > > each module separately (much slower but most effective).
> > 
> > The policy makefiles were never meant to do this.??The targets for?
> > loading modules are just for convenience, and not meant to add
> > another?
> > layer of policy management to what we already have with
> > semodule/semanage.
> 
> Even if originally it was not designed to provide such facility, it
> is
> never too late to offer something more to the user.
> 
> Generally speaking, one would probably expect that the "load" target
> only loads modules that are enabled in the policy/modules.conf file
> and
> not modules that are disabled...
> 
> By the way, after removing several modules that I do not use, I came
> across some strange behaviour of the system, so I wonder if you have
> any idea of what is actually going on.
> 
> The system became unstable due to several permission denied errors
> and
> it seems like parts of the policy have not been loaded, despite
> "semodule -l" shows that the relevant modules are there.

I found that part of the problem was due to the removal of the
"unconfined" domain.

> For example:
> 
> #?sesearch -t xsession_exec_t -c file -p entrypoint -Ad

But, even after re-enabling the unconfined domain, other permissions
such as the one above are not found, despite the relevant policy
modules have been loaded (in this case the xserver module).

> shows nothing, while it should show the result of calling the
> xserver_xsession_entry_type() interface
> from?xserver_restricted_role()
> which is called by xserver_role() as usual !
> 
> Another example is as follows. Despite the domain module is loaded
> because "semodule -l" shows that the base is loaded, the following
> command:
> 
> #?sesearch -s domain -c file -Ad
> 
> only shows:
> 
> Found 5 semantic av rules:
> ???allow domain ld_so_t : file { ioctl read getattr execute open } ;?
> ???allow domain ld_so_cache_t : file { ioctl read getattr lock open }
> ;?
> ???allow domain cpu_online_t : file { ioctl read getattr lock open }
> ;?
> ???allow domain lib_t : file { ioctl read getattr execute open } ;?
> ???allow domain textrel_shlib_t : file { ioctl read getattr execute
> execmod open } ;?
> 
> while I believe is should at least show other "domain self:file"
> permissions.
> 
> Do you know what is actually going on after I removed the unused
> modules ? They were all optional stuff that it is not installed on
> the
> system...
> 
> > 
> > > 
> > > Signed-off-by: Guido Trentalancia <guido@trentalancia.net>
> > > ---
> > > ?Rules.modular |????6 +++++-
> > > ?1 file changed, 5 insertions(+), 1 deletion(-)
> > > 
> > > diff -pru a/Rules.modular b/Rules.modular
> > > --- a/Rules.modular	2016-12-15 19:23:50.693731447 +0100
> > > +++ b/Rules.modular	2016-12-15 20:40:42.482313515 +0100
> > > @@ -21,6 +21,7 @@ base_post_te_files := $(user_files) $(po
> > > ?base_fc_files := $(base_mods:.te=.fc)
> > > 
> > > ?mod_pkgs := $(addprefix $(builddir),$(notdir
> > > $(mod_mods:.te=.pp)))
> > > +off_mod_names := $(basename $(off_mods))
> > > 
> > > ?# policy packages to install
> > > ?instpkg := $(addprefix $(modpkgdir)/,$(notdir $(base_pkg))
> > > $(mod_pkgs))
> > > @@ -48,7 +49,9 @@ install: $(instpkg) $(appfiles)
> > > 
> > > ?########################################
> > > ?#
> > > -# Load all configured modules
> > > +# Load all configured modules and remove
> > > +# all modules that have been explicitly
> > > +# disabled
> > > ?#
> > > ?load: $(instpkg) $(appfiles)
> > > ?# make sure two directories exist since they are not
> > > @@ -56,6 +59,7 @@ load: $(instpkg) $(appfiles)
> > > ?	@echo "Loading configured modules."
> > > ?	@$(INSTALL) -d -m 0755 $(policypath) $(dir $(fcpath))
> > > ?	$(verbose) $(SEMODULE) -s $(NAME) -i
> > > $(modpkgdir)/$(notdir
> > > $(base_pkg)) $(foreach mod,$(mod_pkgs),-i $(modpkgdir)/$(mod))
> > > +	-$(verbose) $(SEMODULE) -s $(NAME) -r $(foreach
> > > offmod,$(off_mod_names),$(offmod)) || $(foreach
> > > offmod,$(off_mod_names),$(SEMODULE) -s $(NAME) -r $(offmod);)
> > > 
> > > ?########################################
> > > ?#

Regards,

Guido

[refpolicy] [PATCH v2] Do not keep disabled modules during new policy load

[Guido Trentalancia]

On Fri, 16/12/2016 at 23.47 +0100, Guido Trentalancia via refpolicy
wrote:
> On Fri, 16/12/2016 at 18.18 +0100, Guido Trentalancia via refpolicy
> wrote:

[...]

> > By the way, after removing several modules that I do not use, I
> > came
> > across some strange behaviour of the system, so I wonder if you
> > have
> > any idea of what is actually going on.
> > 
> > The system became unstable due to several permission denied errors
> > and
> > it seems like parts of the policy have not been loaded, despite
> > "semodule -l" shows that the relevant modules are there.
> 
> I found that part of the problem was due to the removal of the
> "unconfined" domain.

It seems that the "unconfined" domain is defined through optional
policy in the "kernel" module, but I suppose this is wrong and it
should instead be defined outside of an optional block, as the kernel
module depends on it. See above.

Regards,

Guido

[refpolicy] [PATCH v2] Do not keep disabled modules during new policy load

[cgzones]

Why is the unconfined module required for the kernel one?
I am using a confined kernel_t with the standard debian sid kernel
4.8.11 and a mostly vanilla 4.9 one and the only permissions i had to
add were:

dev_setattr_xserver_misc_dev(kernel_t)
allow kernel_t xserver_misc_device_t:chr_file { getattr unlink };


2016-12-16 23:51 GMT+01:00 Guido Trentalancia via refpolicy
<refpolicy@oss.tresys.com>:
> On Fri, 16/12/2016 at 23.47 +0100, Guido Trentalancia via refpolicy
> wrote:
>> On Fri, 16/12/2016 at 18.18 +0100, Guido Trentalancia via refpolicy
>> wrote:
>
> [...]
>
>> > By the way, after removing several modules that I do not use, I
>> > came
>> > across some strange behaviour of the system, so I wonder if you
>> > have
>> > any idea of what is actually going on.
>> >
>> > The system became unstable due to several permission denied errors
>> > and
>> > it seems like parts of the policy have not been loaded, despite
>> > "semodule -l" shows that the relevant modules are there.
>>
>> I found that part of the problem was due to the removal of the
>> "unconfined" domain.
>
> It seems that the "unconfined" domain is defined through optional
> policy in the "kernel" module, but I suppose this is wrong and it
> should instead be defined outside of an optional block, as the kernel
> module depends on it. See above.
>
> Regards,
>
> Guido
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy

[refpolicy] [PATCH v2] Do not keep disabled modules during new policy load

[Chris PeBenito]

On 12/16/16 12:18, Guido Trentalancia via refpolicy wrote:
> By the way, after removing several modules that I do not use, I came
> across some strange behaviour of the system, so I wonder if you have
> any idea of what is actually going on.
>
> The system became unstable due to several permission denied errors and
> it seems like parts of the policy have not been loaded, despite
> "semodule -l" shows that the relevant modules are there.
>
> For example:
>
> # sesearch -t xsession_exec_t -c file -p entrypoint -Ad
>
> shows nothing, while it should show the result of calling the
> xserver_xsession_entry_type() interface from xserver_restricted_role()
> which is called by xserver_role() as usual !
>
> Another example is as follows. Despite the domain module is loaded
> because "semodule -l" shows that the base is loaded, the following
> command:
>
> # sesearch -s domain -c file -Ad
>
> only shows:
>
> Found 5 semantic av rules:
>    allow domain ld_so_t : file { ioctl read getattr execute open } ;
>    allow domain ld_so_cache_t : file { ioctl read getattr lock open }
> ;
>    allow domain cpu_online_t : file { ioctl read getattr lock open } ;
>    allow domain lib_t : file { ioctl read getattr execute open } ;
>    allow domain textrel_shlib_t : file { ioctl read getattr execute
> execmod open } ;
>
> while I believe is should at least show other "domain self:file"
> permissions.
>
> Do you know what is actually going on after I removed the unused
> modules ? They were all optional stuff that it is not installed on the
> system...

"self" rules are expanded out in the binary policy, so instead you'd see 
results like:

allow staff_t staff_t:file { append getattr ioctl lock open read write };

and not:

allow domain self:file { append getattr ioctl lock open read write };

-- 
Chris PeBenito

[refpolicy] [PATCH v2] Do not keep disabled modules during new policy load

[Chris PeBenito]

On 12/16/16 17:51, Guido Trentalancia via refpolicy wrote:
> On Fri, 16/12/2016 at 23.47 +0100, Guido Trentalancia via refpolicy
> wrote:
>> On Fri, 16/12/2016 at 18.18 +0100, Guido Trentalancia via refpolicy
>> wrote:
>
> [...]
>
>>> By the way, after removing several modules that I do not use, I
>>> came
>>> across some strange behaviour of the system, so I wonder if you
>>> have
>>> any idea of what is actually going on.
>>>
>>> The system became unstable due to several permission denied errors
>>> and
>>> it seems like parts of the policy have not been loaded, despite
>>> "semodule -l" shows that the relevant modules are there.
>>
>> I found that part of the problem was due to the removal of the
>> "unconfined" domain.

I can't reproduce your issue.  However, based on your sesearch syntax, 
you're using setools3, which could potentially have a bug, since it is 
unmaintained.

> It seems that the "unconfined" domain is defined through optional
> policy in the "kernel" module, but I suppose this is wrong and it
> should instead be defined outside of an optional block, as the kernel
> module depends on it. See above.

The unconfined module must absolutely be optional.  If there are missing 
rules, then they need to be added.


-- 
Chris PeBenito