From: pebenito@ieee.org (Chris PeBenito) Date: Sat, 17 Dec 2016 08:02:03 -0500 Subject: [refpolicy] [PATCH v2] Do not keep disabled modules during new policy load In-Reply-To: <1481928662.3283.5.camel@trentalancia.net> References: <1481831671.24835.1.camel@trentalancia.net> <1481835895.24835.3.camel@trentalancia.net> <1481908711.2610.16.camel@trentalancia.net> <1481928436.3283.2.camel@trentalancia.net> <1481928662.3283.5.camel@trentalancia.net> Message-ID: <7817d27e-2c18-1abe-8f21-07591a1eb468@ieee.org> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com 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