On 11/15/2024 8:35 AM, Christian Göttsche wrote:
From: Christian Göttsche <cgzones@xxxxxxxxxxxxxx>
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
