Page MenuHomeFreeBSD

ptrace(2): Disabling: Describe influence of security.bsd.see_jail_proc
ClosedPublic

Authored by olce on Jul 20 2023, 10:45 AM.
Tags
None
Referenced Files
Unknown Object (File)
Sat, May 4, 11:23 PM
Unknown Object (File)
Thu, May 2, 2:55 AM
Unknown Object (File)
Mon, Apr 22, 4:51 PM
Unknown Object (File)
Apr 4 2024, 7:24 PM
Unknown Object (File)
Mar 21 2024, 1:56 AM
Unknown Object (File)
Feb 22 2024, 9:13 AM
Unknown Object (File)
Jan 10 2024, 1:57 AM
Unknown Object (File)
Dec 29 2023, 12:47 PM
Subscribers

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

olce requested review of this revision.Jul 20 2023, 10:45 AM
lib/libc/sys/ptrace.2
179

To me, this would be slightly clearer. In part, because the policy is enforced on processes belonging to no jail, AKA prison0.

lib/libc/sys/ptrace.2
171–182

minor edit suggested, but we might want to rewrite this to be more clear

olce marked 2 inline comments as done.Jul 25 2023, 6:23 PM
olce added inline comments.
lib/libc/sys/ptrace.2
171–182

Yes, it's a typo.

How about:

Setting this sysctl to zero value disallows
.Fn ptrace
requests from processes having one of their effective and supplementary groups not being the effective nor one of the supplementary groups of the target process.

But I'm not sure this is clearer. More accurate perhaps.

179

I don't see the connection between your proposed change and the fact that the requesting process may not be in a jail. Also, I don't see how replacing "ancestor" with "parent or ancestor" is clearer (I think it is likely to increase confusion, since the reader may then wonder what "ancestor" exactly means, and if it excludes "parent").

In terms of vocabulary, I don't like distinguishing "jailed" vs. "unjailed" processes, since even "unjailed" ones are in prison0 as you pointed out and because this would clearly complicate the text. In other words, I'm assuming that some process' jail is always well defined (be it prison0), i.e., that every process is jailed. So I'm not that inclined to change the formulation here, unless we absolutely want to maintain the "jailed" vs. "unjailed" difference throughout the documentation, which to me sounds like an artifact of a time before hierarchical jails.

What do you find unclear here exactly? Is it just the formulation, or the concepts? Is it the fact that the previous proposition talks about processes, and the last (after the comma) talks about jails, which are referred to with "former" and "latter" in reference to the previously described processes?

mhorne added inline comments.
lib/libc/sys/ptrace.2
179

I think it is fine with just "ancestor".

My formulation was primarily an effort to avoid "former and latter". Use of these words is common and understood, and yet they still obscure what you are referring to in some way, so I find it useful to avoid them when they seem to complicate rather than simplify a sentence. I find that they complicate the sentence here.

As for the jailed/unjailed thing, you are right that my wording doesn't meaningfully distinguish between them more than yours already did.

Anyhow this is a suggestion, the change is acceptable already, but I forgot to do that.

This revision is now accepted and ready to land.Jul 25 2023, 6:40 PM
olce marked 3 inline comments as done.Jul 25 2023, 8:32 PM
olce added inline comments.
lib/libc/sys/ptrace.2
171–182

At this point in the series, "effective" should in fact read "real" in the proposed text.

Anyway, I've just noticed that the initial text and my version in fact just don't correspond to reality.

So going to propose something else.

179

My formulation was primarily an effort to avoid "former and latter". Use of these words is common and understood, and yet they still obscure what you are referring to in some way, so I find it useful to avoid them when they seem to complicate rather than simplify a sentence. I find that they complicate the sentence here.

I see. I have another proposal going into this direction.

Anyhow this is a suggestion, the change is acceptable already, but I forgot to do that.

Yes, thanks.

olce marked an inline comment as done.

New formulations addressing reviewers' concerns.

While here, fix the English in descriptions for other security.bsd knobs.

This revision now requires review to proceed.Jul 25 2023, 8:35 PM
This revision is now accepted and ready to land.Aug 7 2023, 8:55 PM