3 ms·

I see what you mean about being setgid; I did not think to check for that. That said, I still don't think the processes group is what stops you from debugging

I see what you mean about being setgid; I did not think to check for that. That said, I still don't think the processes group is what stops you from debugging it (it's the undumpable flag). The group check wouldn't matter and would never take effect, since your uid matches that of the process, that would be sufficient to allow you access to the process, would it not?

geofft 8y ago
No - the debugging check pays attention to more than just UID, specifically because the point of being setgid is that a binary can be allowed to access files that the calling user isn't permitted to access. For instance, games are traditionally setgid games to update high scores, which users in general shouldn't be able to do. Being able to attach a debugger to a game would let you update high scores without actually playing the game. titan:~ geofft$ ls -ld /usr/games/battlestar -rwxr-sr-x 1 root games 213272 Jul 8 2014 /usr/games/battlestar titan:~ geofft$ battlestar [...] ^Z [1]+ Stopped battlestar titan:~ geofft$ jobs -p 6343 titan:~ geofft$ strace -p 6343 strace: attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted titan:~ geofft$ fg ^Cbye. Your rating was novice. titan:~ geofft$ ls -l /var/games/bsdgames/battlestar.log -rw-rw-r-- 1 root games 58 May 23 15:50 /var/games/bsdgames/battlestar.log titan:~ geofft$ cat /var/games/bsdgames/battlestar.log Wed May 23 15:50:51 2018 geofft novice One subtler thing is that, as 'tedunangst points out, ssh-agent changes back to your gid with the setgid syscall. But (at least on Linux, and I think on most UNIXes) that doesn't re-enable debug access, because there might be restricted data still in memory, or mmappings of restricted files, or whatever. You have to do an exec, which dumps the contents of memory, to re-enable debugging. The dumpable flag also blocks debugging on Linux, yes. The full algorithm is way at the bottom of the ptrace manpage http://man7.org/linux/man-pages/man2/ptrace.2.html#NOTES http://man7.org/linux/man-pages/man2/ptrace.2.html#NOTES , but it's basically: - allow debugging another thread from the same process (because threads share memory anyway) - allow if the debugger is privileged to debug anything (CAP_SYS_PTRACE) - require that real, effective, and saved UIDs and GIDs all match - require that the dumpable flag isn't set and, if you go over and read the prctl manpage http://man7.org/linux/man-pages/man2/prctl.2.html http://man7.org/linux/man-pages/man2/prctl.2.html , it points out that the dumpable flag is implicitly set to undumpable if the process changes euid/egid or exec a setuid/setgid/fscaps binary, and the execve manpage says it's set back to dumpable if you exec a normal binary.

geofft 8y ago

No - the debugging check pays attention to more than just UID, specifically because the point of being setgid is that a binary can be allowed to access files that the calling user isn't permitted to access. For instance, games are traditionally setgid games to update high scores, which users in general shouldn't be able to do. Being able to attach a debugger to a game would let you update high scores without actually playing the game. titan:~ geofft$ ls -ld /usr/games/battlestar -rwxr-sr-x 1 root games 213272 Jul 8 2014 /usr/games/battlestar titan:~ geofft$ battlestar [...] ^Z [1]+ Stopped battlestar titan:~ geofft$ jobs -p 6343 titan:~ geofft$ strace -p 6343 strace: attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted titan:~ geofft$ fg ^Cbye. Your rating was novice. titan:~ geofft$ ls -l /var/games/bsdgames/battlestar.log -rw-rw-r-- 1 root games 58 May 23 15:50 /var/games/bsdgames/battlestar.log titan:~ geofft$ cat /var/games/bsdgames/battlestar.log Wed May 23 15:50:51 2018 geofft novice One subtler thing is that, as 'tedunangst points out, ssh-agent changes back to your gid with the setgid syscall. But (at least on Linux, and I think on most UNIXes) that doesn't re-enable debug access, because there might be restricted data still in memory, or mmappings of restricted files, or whatever. You have to do an exec, which dumps the contents of memory, to re-enable debugging. The dumpable flag also blocks debugging on Linux, yes. The full algorithm is way at the bottom of the ptrace manpage http://man7.org/linux/man-pages/man2/ptrace.2.html#NOTES http://man7.org/linux/man-pages/man2/ptrace.2.html#NOTES , but it's basically: - allow debugging another thread from the same process (because threads share memory anyway) - allow if the debugger is privileged to debug anything (CAP_SYS_PTRACE) - require that real, effective, and saved UIDs and GIDs all match - require that the dumpable flag isn't set and, if you go over and read the prctl manpage http://man7.org/linux/man-pages/man2/prctl.2.html http://man7.org/linux/man-pages/man2/prctl.2.html , it points out that the dumpable flag is implicitly set to undumpable if the process changes euid/egid or exec a setuid/setgid/fscaps binary, and the execve manpage says it's set back to dumpable if you exec a normal binary.