On 12/9/2022 9:09 AM, Chris PeBenito wrote:
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?
If I turn of a module I want as little residue as possible in other modules.
I think using extend is the best option. Keep all relative types and
labeling in the singular module so if it is not used we heavily reduce
the possibility of unexpected labeling/access.
The users should understand that a single cas file does not define the
whole policy, so if they see something that may be "off" with labeling
they may need to look further. And with the new tooling, looking
further should be easy.
