git: bfd1b9fc85 - main - Status/2023Q3/process_visibility.adoc: Fixes

The branch main has been updated by salvadore:

URL: https://cgit.FreeBSD.org/doc/commit/?id=bfd1b9fc85b6a3482f8c179ee7747fc89502ad74

commit bfd1b9fc85b6a3482f8c179ee7747fc89502ad74
Author:     Graham Perrin <grahamperrin@gmail.com>
AuthorDate: 2023-10-02 08:18:54 +0000
Commit:     Lorenzo Salvadore <salvadore@FreeBSD.org>
CommitDate: 2023-10-02 08:20:31 +0000

    Status/2023Q3/process_visibility.adoc: Fixes
    
    Pull Request:   https://github.com/freebsd/freebsd-doc/pull/268
---
 .../en/status/report-2023-07-2023-09/process_visibility.adoc      | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/website/content/en/status/report-2023-07-2023-09/process_visibility.adoc b/website/content/en/status/report-2023-07-2023-09/process_visibility.adoc
index bbb29cab20..06cf80b33f 100644
--- a/website/content/en/status/report-2023-07-2023-09/process_visibility.adoc
+++ b/website/content/en/status/report-2023-07-2023-09/process_visibility.adoc
@@ -17,7 +17,7 @@ It can be activated by setting the sysctl `security.bsd.see_other_gids` to 0 (de
 
 The third one can prevent an unprivileged user's process from seeing or interacting with processes that are in a jail that is a strict sub-jail of the former.
 The jail subsystem already prevents such a process to see processes in jails that are not descendant of its own (see man:jail[8] and in particular the section "Hierarchical Jails").
-One possible use of this policy is, in conjunction with the first one above, to hide processes in sub-jails that have the same real UID as some user in an ancestor jail because users having identical UIDs in these different jails are logically considered as actually different users.
+One possible use of this policy is, in conjunction with the first one above, to hide processes in sub-jails that have the same real UID as some user in an ancestor jail, because users having identical UIDs in these different jails are logically considered as different users.
 It can be activated by setting the sysctl `security.bsd.see_jail_proc` to 0 (default is 1).
 
 After a review of these policies' code and real world testing, we noticed a number of problems and limitations which prompted us to work on this topic.
@@ -26,13 +26,13 @@ After a review of these policies' code and real world testing, we noticed a numb
 
 The policy controlled by the `security.bsd.see_jail_proc` sysctl has received the following fixes and improvements:
 
-- Harden the security.bsd.see_jail_proc policy by preventing unauthorized users from attempting to kill, change priority of or debug processes with same (real) UID in a sub-jail at random, which, provided the PID of such a process is guessed correctly, would succeed even if these processes are not visible to them.
-- Make this policy overridable by MAC policies, as are the other ones.
+- Harden the `security.bsd.see_jail_proc` policy by preventing unauthorized users from attempting to kill, change priority of or debug processes with same (real) UID in a sub-jail at random, which, provided the PID of such a process is guessed correctly, would succeed even if these processes are not visible to them.
+- Make this policy overridable by MAC policies, as are the others.
 
 The policy controlled by `security.bsd.see_other_gids` was fixed to consider the real group of a process instead of its effective group when determining whether the user trying to access the process is a member of one of the process' groups.
 The rationale is that some user should continue to see processes it has launched even when they acquire further privileges by virtue of the setgid bit.
 Conversely, they should not see processes launched by a privileged user that temporarily enters the user's primary group.
-This new behavior is consistent with what `security.bsd.see_other_uids` has always been doing for user IDs (i.e., considering some process' real user ID and not the effective one).
+This new behavior is consistent with what `security.bsd.see_other_uids` has always been doing for user IDs (i.e., considering some process' real user ID and not the effective ID).
 
 We have updated manual pages related to these security policies, including man:security[7], man:sysctl[8], and man:ptrace[2].
 Several manual pages of internal functions either implementing or leveraging these policies have also been revamped.