Hey Mark and Chris,
I've kept out of the ptrace discussion largely because I felt
trenches have been dug and they've been dug deep over time. For
some reason I do feel the need to chime in today. I hope you give
my opinion some consideration.
On Wed, Nov 26, 2025, at 11:49 PM, Mark Wielaard wrote:
> You are presenting this as some kind of users vs developers
> "fight". Where there is only some binary choice of being pro-users or
> pro-developers. I don't think this is useful. I do think we should
> encourage everybody to think of themselves as hackers and to make it
> easy to explore all levels of the "full stack".
We always have to weigh our own comfort and discomfort with those who
would abuse the freedoms we have on our systems. I think it'd be a good
idea for the 'users' here to think about the impact of this change to the
'developers'. The 'developers' can then think about 'what can I do with
access to and control over all sibling processes'.
However:
There's a third persona here that is overlooked and that is the person
with ill intent. We can call them Mallory since I don't think anyone is
actually called Mallory on this list (I apologize if so).
If I was Mallory (and in a previous life, I guess some of us have been)
then having access to read, write, and execute code in the context of
sibling processes is a great gift. It makes it exceptionally easy to
move laterally, hide my code, escalate my privileges, and in general have
a very good time on a system.
I guess this all boils down to if people expect separate processes as some
form of a security boundary or not. For me, personally, I would expect at
least some barriers to be in place :)
P.S. since major distributions have disabled this behavior for so long I
feel like the younger Mallories have luckily forgotten this to be
an option. We see very little of it in the public supply chain attacks
as of late. Perhaps that has to do with everyone and their dog running
their workloads containerized and under SECCOMP.
Thank you,
Simon
--
_______________________________________________
devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/[email protected]
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue