On Wed, 2022-02-23 at 11:37 -0500, Stefan Berger wrote:
On 2/23/22 10:38, Mimi Zohar wrote:The question is "why" there should be a difference between the
On Tue, 2022-02-01 at 15:37 -0500, Stefan Berger wrote:There's typically no cgroup for the int_ima_ns, so not effect on
Limit the number of policy rules one can set in non-init_ima_ns to aThis paragraph describes 'what' you're doing, not 'why'. Please prefix
hardcoded 1024 rules. If the user attempts to exceed this limit by
setting too many additional rules, emit an audit message with the cause
'too-many-rules' and simply ignore the newly added rules.
this paragraph with a short, probably one sentence, reason for the
change.
Switch the accounting for the memory allocated for IMA policy rules toDoes this change affect the existing IMA policy rules for init_ima_ns?
GFP_KERNEL_ACCOUNT so that cgroups kernel memory accounting takes effect.
init_ima_ns.
Here's the updated text:
Limit the number of policy rules one can set in non-init_ima_ns to a
hardcoded 1024 rules to restrict the amount of memory used for IMA's
policy.
init_ima_ns and non-init_ima_ns cases. Perhaps something like, "Only
host root with CAP_SYS_ADMIN may write init_ima_ns policy rules, but in
the non-init_ima_ns case root in the namespace with CAP_MAC_ADMIN
privileges may write IMA policy rules. Limit the total number of IMA
policy rules per namespace."
Ignore the added rules if the user attempts to exceed thisthanks,
limit by setting too many additional rules.
Switch the accounting for the memory allocated for IMA policy rules to
GFP_KERNEL_ACCOUNT so that cgroups kernel memory accounting takes effect.
This switch has no effect on the init_ima_ns.
Mimi