Lines Matching +full:keep +full:- +full:a +full:- +full:live
1 .. SPDX-License-Identifier: GPL-2.0
3 Integrity Policy Enforcement (IPE) - Kernel Documentation
10 :doc:`IPE admin guide </admin-guide/LSM/ipe>`.
13 ---------------------
16 of a locked-down system. This system would be born-secure, and have
20 policy. A mandatory access control system would be present, and
21 as a result, xattrs would have to be protected. This lead to a selection
27 2. DM-Verity
29 Both options were carefully considered, however the choice to use DM-Verity
40 there must be some form of selector to determine whether a read should
46 modify filesystem offline, the attacker could wipe all the xattrs -
50 With DM-Verity, as the xattrs are saved as part of the Merkel tree, if
51 offline mount occurs against the filesystem protected by dm-verity, the
54 * As userspace binaries are paged in Linux, dm-verity also offers the
55 additional protection against a hostile block device. In such an attack,
59 dm-verity will check the data when the page fault occurs (and the disk
64 * dm-verity provides integrity verification on demand as blocks are
73 * The signature supports an x.509-based signing infrastructure.
75 The next step was to choose a *policy* to enforce the integrity mechanism.
81 3. The policy enforcement must have a permissive-like mode.
83 a reboot.
87 7. The policy must be auditable, at any point-of-time.
92 requirements was considered, but ultimately discarded for a
103 Due to these reasons, it was decided that a new LSM should be created,
107 --------------
113 There are several different integrity solutions that provide a different
128 -----------------
132 implementations, there were a few pitfalls identified:
134 1. Policies were not readable by humans, usually requiring a binary
136 2. A single, non-customizable action was implicitly taken as a default.
138 4. Authoring a policy required an in-depth knowledge of the larger system,
149 IPE's policy is plain-text. This introduces slightly larger policy files than
156 what is being written. In a hypothetical binary policy design, a serializer
158 form, and a deserializer is needed to interpret the binary form into a data
162 back into the human-readable form with as much information preserved. This is because a
163 user of this access control system will have to keep a lookup table of a checksum
165 on this system and what policies have not. For a single user, this may be alright,
175 human-readable form to the data structure in kernel, saving on code maintenance,
178 The second issue with a binary format is one of transparency. As IPE controls
181 signing as a process. Signing, as a process, is typically done with a
184 the signer is aware of what they are signing. A binary policy can cause
185 obfuscation of that fact; what signers see is an opaque binary blob. A
186 plain-text policy, on the other hand, the signers see the actual policy
192 IPE, if configured appropriately, is able to enforce a policy as soon as a
197 1. The policy file(s) live on disk and the kernel loads the policy prior
201 3. There is a policy file that is compiled into the kernel that is
207 The second option also has problems: Linux supports a variety of bootloaders
208 across its entire ecosystem - every bootloader would have to support this
214 keep this policy generalized enough that userspace can load a new, more
218 The initramfs provides a way that this bootup path can be established. The
219 kernel starts with a minimal policy, that trusts the initramfs only. Inside
221 it deploys and activates a policy that trusts the new root filesystem.
223 to a minimal size.
231 make the compiled-in policy a full IPE policy, it allows system builders
238 trusted applications, keys roll, etcetera). Updating a kernel to change the
239 meet those security goals is not always a suitable option, as updates are not
240 always risk-free, and blocking a security update leaves systems vulnerable.
241 This means IPE requires a policy that can be completely updated (allowing
242 revocations of existing policy) from a source external to the kernel (allowing
246 policy files off the disk from kernel space is a bad idea(tm), then the
250 so this policy needs to have a way to be identified as trusted. This is
251 done via a signature chained to a trust source in the kernel. Arbitrarily,
252 this is the ``SYSTEM_TRUSTED_KEYRING``, a keyring that is initially
253 populated at kernel compile-time, as this matches the expectation that the
254 author of the compiled-in policy described above is the same entity that can
257 Anti-Rollback / Anti-Replay
262 instances where a mistaken policy author deploys an insecure policy,
263 before correcting it with a secure policy.
266 acquires the insecure policy, IPE needs a way to prevent rollback
269 Initially, IPE's policy can have a policy_version that states the
271 the system. This will prevent rollback while the system is live.
278 deployed ASAP after a boot to ensure that the window of
285 a mixed level of security bars across multiple operations in a system.
286 For example, consider a system that has strong integrity guarantees
291 1. A policy in which failure to match any rules in the policy results
293 2. A policy in which failure to match any rules in the policy results
295 3. A policy in which the action taken when no rules are matched is
298 The first option could make a policy like this::
305 This would result in a policy like this (assuming each line is
314 is executed in order and that the default is a denial; however, the
316 required, because in a realistic system, there are some unverified
317 reads (imagine appending to a log file).
333 and override the default with an empty rule, force the end-user
346 When developing a policy, it is useful to know what line of the policy
350 information that was used in the evaluation. This then requires a correlation
354 of the investigation to the exact policy line (in the case of a specific
355 rule), or the section (in the case of a DEFAULT). This decreases iteration
359 IPE's policy engine is also designed in a way that it makes it obvious to
360 a human of how to investigate a policy failure. Each line is evaluated in
365 algorithm may not always be clear to the end-user without reading the code first.
375 could occur due to a lack of knowledge of the underlying system; whereas the
380 --------------------
387 or ``file_mprotect`` hook, but with a ``NULL`` file object. This is submitted to
389 evaluate to false, as they are all file-based and the operation is not
390 associated with a file.
395 loading data from a userspace buffer that is not backed by a file. In this
401 The per-policy securityfs tree is somewhat unique. For example, for
402 a standard securityfs policy tree::
405 |- active
406 |- delete
407 |- name
408 |- pkcs7
409 |- policy
410 |- update
411 |- version
413 The policy is stored in the ``->i_private`` data of the MyPolicy inode.
416 -----
444 In addition, IPE has a python based integration
445 `test suite <https://github.com/microsoft/ipe/tree/test-suite>`_ that