> On Jan 3, 2025, at 2:12 PM, Stephen Smalley <stephen.smalley.work@xxxxxxxxx> wrote: > > On Mon, Dec 16, 2024 at 11:42 AM Christian Göttsche > <cgoettsche@xxxxxxxxxxxxx> wrote: >> >> From: Christian Göttsche <cgzones@xxxxxxxxxxxxxx> >> >> Validate the characters and the lengths of strings parsed from binary >> policies. Excellent idea. >> * Disallow control characters Fine here. >> * Limit characters of identifiers to alphanumeric, underscore, dash, >> and dot Fine again. >> * Limit identifiers in length to 128, Fine again, our longest - type is 51 characters - attribute is 31 - boolean is 46 - role is 12 >> expect types to 1024 and I don’t understand what this means. >> categories to 32, characters (excluding NUL-terminator) One category or the whole category string? A single category longer than 7 characters seems pretty unlikely and 32 is wildly short for the whole string. Joe > One option if we are concerned about breaking backward compatibility > with policies in the wild would be to make these restrictions > conditional on whether the policy is being loaded into a non-init > SELinux namespace, similar to: > https://lore.kernel.org/selinux/20250102164509.25606-38-stephen.smalley.work@xxxxxxxxx/T/#u > > That said, it seems hard to imagine real-world policies that would > exceed these limits, and likely could make them even smaller. > But as Daniel said, we should make them consistently enforced in both > userspace and kernel, and potentially these should all be #define'd > symbols in a uapi header that can be referenced by both. > Looks like you left the type limit at 1024 despite Daniel's > observation that CIL uses 2048 as the limit, but as you noted, given > the page size limit on the entire context by various kernel > interfaces, > this is likely fine. >
