diff options
| author | Evan Ducas <evan.j.ducas@gmail.com> | 2026-03-08 21:07:34 +0300 |
|---|---|---|
| committer | Fan Wu <wufan@kernel.org> | 2026-04-14 01:58:49 +0300 |
| commit | d46515ec0b1d4ae07f8f437515c43cfb6eb61ffa (patch) | |
| tree | b5a78869d7e71ed426bf19c47b05473f709181e0 /Documentation | |
| parent | 028ef9c96e96197026887c0f092424679298aae8 (diff) | |
| download | linux-d46515ec0b1d4ae07f8f437515c43cfb6eb61ffa.tar.xz | |
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>
Diffstat (limited to 'Documentation')
| -rw-r--r-- | Documentation/security/ipe.rst | 10 |
1 files changed, 5 insertions, 5 deletions
diff --git a/Documentation/security/ipe.rst b/Documentation/security/ipe.rst index 4a7d953abcdc..5eb3e6265fbd 100644 --- a/Documentation/security/ipe.rst +++ b/Documentation/security/ipe.rst @@ -18,7 +18,7 @@ strong integrity guarantees over both the executable code, and specific *data files* on the system, that were critical to its function. These specific data files would not be readable unless they passed integrity policy. A mandatory access control system would be present, and -as a result, xattrs would have to be protected. This lead to a selection +as a result, xattrs would have to be protected. This led to a selection of what would provide the integrity claims. At the time, there were two main mechanisms considered that could guarantee integrity for the system with these requirements: @@ -195,7 +195,7 @@ of the policy to apply the minute usermode starts. Generally, that storage can be handled in one of three ways: 1. The policy file(s) live on disk and the kernel loads the policy prior - to an code path that would result in an enforcement decision. + to a code path that would result in an enforcement decision. 2. The policy file(s) are passed by the bootloader to the kernel, who parses the policy. 3. There is a policy file that is compiled into the kernel that is @@ -235,8 +235,8 @@ Updatable, Rebootless Policy ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ As requirements change over time (vulnerabilities are found in previously -trusted applications, keys roll, etcetera). Updating a kernel to change the -meet those security goals is not always a suitable option, as updates are not +trusted applications, keys roll, etcetera), updating a kernel to meet +those security goals is not always a suitable option, as updates are not always risk-free, and blocking a security update leaves systems vulnerable. This means IPE requires a policy that can be completely updated (allowing revocations of existing policy) from a source external to the kernel (allowing @@ -370,7 +370,7 @@ Simplified Policy: Finally, IPE's policy is designed for sysadmins, not kernel developers. Instead of covering individual LSM hooks (or syscalls), IPE covers operations. This means instead of sysadmins needing to know that the syscalls ``mmap``, ``mprotect``, -``execve``, and ``uselib`` must have rules protecting them, they must simple know +``execve``, and ``uselib`` must have rules protecting them, they must simply know that they want to restrict code execution. This limits the amount of bypasses that could occur due to a lack of knowledge of the underlying system; whereas the maintainers of IPE, being kernel developers can make the correct choice to determine |