Re: [RFC PATCH 00/22] selinux: harden against malformed policies

[Daniel Burgener <dburgener@linux.microsoft.com>]

On 11/15/2024 8:35 AM, Christian Göttsche wrote:
> From: Christian Göttsche <cgzones@googlemail.com>
> 
> With the SELinux namespace feature on the horizon it becomes important
> to identify and reject malformed policies at load time.  Otherwise
> memory corruptions can compromise the kernel or NULL-pointer dereferences
> and BUG() encounters can bring systems down.  Currently this is not a
> security relevant issue since loading a policy requires root privileges
> and permission of the current loaded SELinux policy, making it one of the
> most privileged operation.
> 
> The first 9 patches are cleanup commits with overseeable diffs.
> 
> Patch 10 unifies the underlying type used for security class identifiers.
> 
> Patch 11 to 21 add various checks at policy load time to reject malformed
> policies.
> 
> Patch 22 needs some discussion:
> It limits the valid set of characters and the length for strings defined
> by policies.  Currently there are no restrictions, so control characters
> are accepted, e.g. Esc as part of a type name, and their length can be
> arbitrary.  Human formatted security contexts however must not be
> arbitrarily long, one example is they must fit in a page size for
> selinuxfs interaction and network associations.
> Thus the patch introduces the following restrictions:
>    * Disallow control characters
>    * Limit characters of identifiers to alphanumeric, underscore, dash,
>      and dot
>    * Limit identifiers in length to 128, expect types to 1024 and
>      categories to 32, characters (excluding NUL-terminator)

I believe that those first two restrictions match what CIL will do today 
(https://github.com/SELinuxProject/selinux/blob/9b4eff9222b24d4b5f2784db281f4f53019263b0/libsepol/cil/src/cil_verify.c#L96), 
but the length restriction in CIL is 2048.

https://github.com/SELinuxProject/selinux/blob/9b4eff9222b24d4b5f2784db281f4f53019263b0/libsepol/cil/src/cil_internal.h#L49

I would think that we'd want to end up in a situation where the kernel 
is either equally restrictive or less restrictive than CIL.

-Daniel