openssh unix dev - Nov 2022 - Disable tracing on FreeBSD using procctl. (OpenSSH Portable 8.8)

On Sat, 5 Nov 2022 at 20:41, Darren Tucker <dtucker at dtucker.net>
wrote:
>
> Thanks for following up.
>
> On Sun, 6 Nov 2022 at 05:34, Ed Maste <emaste at freebsd.org> wrote:
> [...]
> > -       if (procctl(P_PID, 0, PROC_TRACE_CTL, &disable_trace)
&& strict)
> > +       if (procctl(P_PID, getpid(), PROC_TRACE_CTL,
&disable_trace) && strict)
>
> You seem to be making the exact opposite change in your stable branches?
> https://github.com/freebsd/freebsd-src/commit/b5b1a69
>
> Is the situation that "0" only works on fixed kernels, but
"getpid()"
> works on all (albeit not optimally)?
That is correct. In the FreeBSD stable branches we know we're also
building a kernel which allows 0 instead of getpid(), but I imagine
that there are some people who will build a contemporary OpenSSH on
older FreeBSD versions.

We could add a test based on __FreeBSD_version or see if it could be
handled by autoconf, if you think it's worthwhile.

On Sun, 6 Nov 2022 at 11:54, Ed Maste <emaste at freebsd.org>
wrote:
> On Sat, 5 Nov 2022 at 20:41, Darren Tucker <dtucker at dtucker.net>
wrote:
[...]
> > Is the situation that "0" only works on fixed kernels, but
"getpid()"
> > works on all (albeit not optimally)?
>
> That is correct. In the FreeBSD stable branches we know we're also
> building a kernel which allows 0 instead of getpid(), but I imagine
> that there are some people who will build a contemporary OpenSSH on
> older FreeBSD versions.
>
> We could add a test based on __FreeBSD_version or see if it could be
> handled by autoconf, if you think it's worthwhile.
It's runtime behaviour so autoconf or compile-time checks are not a
good fit (eg you could build it on a kernel with one behaviour then
upgrade the kernel to one with different behaviour).  My concern is
about this part of the commit comment:

"""
At present if the security.bsd.unprivileged_proc_debug sysctl is 0 then
procctl(P_PID, getpid(), ... for a process to act on itself will fail,
but procctl(P_PID, 0, ... will succeed.  This should likely be addressed
with a kernel change.
"""

which seems to say that the getpid() version will fail in
circumstances where the "0" version will succeed.

Maybe it should try the "0" version, then if that fails try the
getpid() version and only then fail if "strict" is set?

-- 
Darren Tucker (dtucker at dtucker.net)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.