Received-SPF: pass (google.com: domain of selinux-refpolicy-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <d83ef10f-ae8b-08d2-55b7-66f2cf12ed9a@linux.microsoft.com>
Date:   Fri, 9 Dec 2022 11:09:10 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.5.1
Content-Language: en-US
To:     SELinux Reference Policy mailing list 
        <selinux-refpolicy@vger.kernel.org>
From:   Chris PeBenito <chpebeni@linux.microsoft.com>
Subject: [refpolicy3 RFC] Split broad file contexts
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

In refpolicy2, we have several types, such as bin_t, that have file 
contexts related to other modules, e.g.:

/etc/acpi/actions(/.*)?			gen_context(system_u:object_r:bin_t,s0)

/usr/lib/mailman/bin(/.*)?		gen_context(system_u:object_r:bin_t,s0)

/var/mailman/bin(/.*)?			gen_context(system_u:object_r:bin_t,s0)


relate to acpi and mailman.

Should we continue to put all of the bin_t labeling in files.cas or 
should we split it back to the individual modules?  This was originally 
done in refpolicy2 so users could look in a single place for everything 
about bin_t for encapsulation.  This is nice for users, but not so nice 
for maintenance and version control.

Since cascade has the "extend" feature, we can split up the labeling 
among relevant modules, and tooling can construct a single unified view 
of the file contexts of bin_t and the like.

For example, instead of this in file.cas:

resource bin_t inherits executable {
   ...many fcs...
   file_context(/etc/acpi/actions(/.*)?, any);
}

we have this in acpi.cas:

extend bin_t {
   file_context(/etc/acpi/actions(/.*)?, any);
}


Thoughts?


-- 
Chris PeBenito