[refpolicy3 RFC] Split broad file contexts

[refpolicy3 RFC] Split broad file contexts

[Dominick Grift]

I agree with Metthew.

In dssp5-debian I take this even further and I generally prefer to use
extend over optional where possible.

I only use optional if both module do not depend on eachother.

I do this for various reasons (aside from what Matthew mentioned)

* Keeps the output of semodule -vvv cleaner if you disable modules
* I try to avoid optional because of its limitations
* Keeps the policy and file_contexts cleaner/more efficient when you disable modules

-- 
gpg --locate-keys dominick.grift@defensec.nl
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
Dominick Grift

[refpolicy3 RFC] Split broad file contexts

[Chris PeBenito]

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

Re: [refpolicy3 RFC] Split broad file contexts

[Matthew Sheets]

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.