Re: [RFC PATCH v2 22/22] selinux: restrict policy strings

[Joe Nall]

> 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.
>