Plain Text ^^^^^^^^^^
IPE’s policy is plain-text. This introduces slightly larger policy files than other LSMs, but solves two major problems that occurs with some integrity policy solutions on other platforms.
The first issue is one of code maintenance and duplication. To author policies, the policy has to be some form of string representation (be it structured, through XML, JSON, YAML, etcetera), to allow the policy author to understand what is being written. In a hypothetical binary policy design, a serializer is necessary to write the policy from the human readable form, to the binary form, and a deserializer is needed to interpret the binary form into a data structure in the kernel.
Eventually, another deserializer will be needed to transform the binary from back into the human-readable form with as much information preserved. This is because a user of this access control system will have to keep a lookup table of a checksum and the original file itself to try to understand what policies have been deployed on this system and what policies have not. For a single user, this may be alright, as old policies can be discarded almost immediately after the update takes hold. For users that manage computer fleets in the thousands, if not hundreds of thousands, with multiple different operating systems, and multiple different operational needs, this quickly becomes an issue, as stale policies from years ago may be present, quickly resulting in the need to recover the policy or fund extensive infrastructure to track what each policy contains.
With now three separate serializer/deserializers, maintenance becomes costly. If the policy avoids the binary format, there is only one required serializer: from the human-readable form to the data structure in kernel, saving on code maintenance, and retaining operability.
The second issue with a binary format is one of transparency. As IPE controls access based on the trust of the system’s resources, it’s policy must also be trusted to be changed. This is done through signatures, resulting in needing signing as a process. Signing, as a process, is typically done with a high security bar, as anything signed can be used to attack integrity enforcement systems. It is also important that, when signing something, that the signer is aware of what they are signing. A binary policy can cause obfuscation of that fact; what signers see is an opaque binary blob. A plain-text policy, on the other hand, the signers see the actual policy submitted for signing.