From: pebenito@ieee.org (Chris PeBenito)
Date: Sat, 17 Dec 2016 07:56:24 -0500
Subject: [refpolicy] [PATCH v2] Do not keep disabled modules during new
 policy load
In-Reply-To: <1481908711.2610.16.camel@trentalancia.net>
References: <1481831671.24835.1.camel@trentalancia.net>
	<1481835895.24835.3.camel@trentalancia.net>
	<efab45bb-9375-eb0d-32be-a2a1a9dd3912@ieee.org>
	<1481908711.2610.16.camel@trentalancia.net>
Message-ID: <60bf48e1-8a40-8a89-a1fc-183a7fced367@ieee.org>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

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