Linux kernel mirror (for testing)
git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel
os
linux
docs: security: ipe: fix typos and grammar
Fix several spelling and grammar mistakes in the IPE
documentation.
No functional change.
Signed-off-by: Evan Ducas <evan.j.ducas@gmail.com>
Acked-by: Bagas Sanjaya <bagasdotme@gmail.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Fan Wu <wufan@kernel.org>
authored by
Evan Ducas
and committed by
Fan Wu
d46515ec
028ef9c9
+5
-5
+5
-5
Documentation/security/ipe.rst
+5
-5
Documentation/security/ipe.rst
···
18
18
*data files* on the system, that were critical to its function. These
19
19
specific data files would not be readable unless they passed integrity
20
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
21
+
as a result, xattrs would have to be protected. This led to a selection
22
22
of what would provide the integrity claims. At the time, there were two
23
23
main mechanisms considered that could guarantee integrity for the system
24
24
with these requirements:
···
195
195
can be handled in one of three ways:
196
196
197
197
1. The policy file(s) live on disk and the kernel loads the policy prior
198
-
to an code path that would result in an enforcement decision.
198
+
to a code path that would result in an enforcement decision.
199
199
2. The policy file(s) are passed by the bootloader to the kernel, who
200
200
parses the policy.
201
201
3. There is a policy file that is compiled into the kernel that is
···
235
235
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
236
236
237
237
As requirements change over time (vulnerabilities are found in previously
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
238
+
trusted applications, keys roll, etcetera), updating a kernel to meet
239
+
those security goals is not always a suitable option, as updates are not
240
240
always risk-free, and blocking a security update leaves systems vulnerable.
241
241
This means IPE requires a policy that can be completely updated (allowing
242
242
revocations of existing policy) from a source external to the kernel (allowing
···
370
370
Finally, IPE's policy is designed for sysadmins, not kernel developers. Instead
371
371
of covering individual LSM hooks (or syscalls), IPE covers operations. This means
372
372
instead of sysadmins needing to know that the syscalls ``mmap``, ``mprotect``,
373
-
``execve``, and ``uselib`` must have rules protecting them, they must simple know
373
+
``execve``, and ``uselib`` must have rules protecting them, they must simply know
374
374
that they want to restrict code execution. This limits the amount of bypasses that
375
375
could occur due to a lack of knowledge of the underlying system; whereas the
376
376
maintainers of IPE, being kernel developers can make the correct choice to determine