On 2/23/22 12:04, Mimi Zohar wrote:
On Wed, 2022-02-23 at 11:37 -0500, Stefan Berger wrote:
On 2/23/22 10:38, Mimi Zohar wrote:
On Tue, 2022-02-01 at 15:37 -0500, Stefan Berger wrote:
Limit the number of policy rules one can set in non-init_ima_ns to a
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 describes 'what' you're doing, not 'why'. Please prefix
this paragraph with a short, probably one sentence, reason for the
change.
Switch the accounting for the memory allocated for IMA policy rules to
GFP_KERNEL_ACCOUNT so that cgroups kernel memory accounting takes effect.
Does this change affect the existing IMA policy rules for init_ima_ns?
There's typically no cgroup for the int_ima_ns, so not effect on
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.
The question is "why" there should be a difference between the
init_ima_ns and non-init_ima_ns cases. Perhaps something like, "Only
Chistian had suggested it to not have the number of policy rules unbounded.
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."
What does it have to do with CAP_SYS_ADMIN and CAP_MAC_ADMIN and why
mention these here? It seem primarily a limit of number of rules to
avoid huge kernel memory consumption in the case that a cgroup limit for
memory was not set up.
Ignore the added rules if the user attempts to exceed this
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.
thanks,
Mimi
