Re: Re: Logic bug in the Linux kernel's __ptrace_may_access() function

[Simon McVittie <smcv () debian org>]

On Wed, 20 May 2026 at 15:46:05 +0000, Qualys Security Advisory wrote:
> In the following proof of concept, we (attackers) log in to the target
> computer as the user jane, remotely via sshd, while the real user jane
> is physically sitting at the computer (tty1)

Note that if you can do this on a typical desktop-class system, then any 
security framework where jane is trusted has already failed, because you 
can already arbitrarily overwrite jane's ~/.bashrc, 
~/.config/(anything), ~/.ssh/authorized_keys and so on to get a 
persistent compromise.

> even though we are not really an "allow_active" user

You are: your ssh'd-in process is not on an active local console, but 
the user whose account you have taken over *is* (concurrently) on an 
active local console (and you are not being confined by a sandbox like 
Flatpak, Snap or equivalent), and there is no effective security barrier 
between jane-via-ssh and jane-on-the-console. The assumption generally 
made by the Unix uid model is that user 'jane' is user 'jane', and if 
one login session is compromised then they are all equally compromised.

Having sandboxed processes that run as user 'jane', but do not have all 
of Jane's privileges, requires something beyond the uid model, for 
example containers (like Flatpak) or non-trivial LSMs (like Snap). One 
of the tasks of a sandboxing framework for privilege separation within a 
user account is to prevent the sandboxed processes from having 
unrestricted access to system facilities that follow the Unix uid model, 
and that includes the home directory and the D-Bus session and system 
buses.

    smcv