5

ptrace_scope is a sysctl value (/proc/sys/kernel/yama/ptrace_scope) that prevents the use of ptrace on non-child processes when set to 1. This is generally considered good security practice.

Unfortunately, being able to ptrace a process as a developer (and attach to a running process, so not a child process) is very useful. Using sudo with the CAP_SYS_PTRACE capability allows one to attach to any running process, not just processes owned by the user. On a shared dev box, it might not be desirable to allow ptrace via sudo for all processes, as that essentially allows arbitrary code to be run as any user.

What I would like to do is allow a user to sudo (or otherwise require authentication) to ptrace a non-child process, but not to allow them to ptrace arbitrary processes. Essentially allowing them to change ptrace_scope for themselves on a temporary, authentication guarded basis.

Is this possible?

Andrew Spott
  • 151
  • 4
  • How are you grouping what they can or can't `ptrace`? Maybe put the devs in containers? – user1794469 Jan 10 '20 at 19:29
  • 1
    @user1794469: I guess that Andrew is saying that he wants the developers to be able to trace *processes they own,* even if they aren’t child processes.  (I was confused by the question the first time I read it, too.) – G-Man Says 'Reinstate Monica' Jan 12 '20 at 02:51
  • @G-ManSays'ReinstateMonica': that is correct. Sorry that it isn't clear – Andrew Spott Jan 13 '20 at 21:54
  • Linux has no concept for limited time permissions or capabilities and it does not allow permissions on interpreted files. You can not user scripts and have to use either libcap2-bin, capsh without timeout. To get a timeout, I would recommend using the landlock API or the more general libcap one depending on your use case. – Jay-Pi Aug 30 '23 at 11:52
  • See also https://blog.container-solutions.com/linux-capabilities-in-practice and alike articles how capabilities are stored and used. – Jay-Pi Aug 30 '23 at 11:55

0 Answers0