> I imagine that the mitigation that is sought by pledge is to minimize > aberrent code reuse in whatever way a hacker can make code run again in a > way that it isn't supposed to. And maybe the programmer can choose what can > be problematic and what isn't if it runs again with their choice of the > calls. What problem could occur that EVFILT_PROC with NOTE_EXIT (as opposed > to EVFILT_PROC with maybe other fflags) could make that couldn't occur by > trying to put a kevent on a file descriptor. Is "abusively" monitoring a > process a security hole?
You want to avoid using pledge "proc" in your own code; you want EVFILT_PROC to just work. I guess you wish that EVFILT_PROC was always enabled, inside the pledge "stdio" environment, since you haven't described another proposal for what would toggle access. But that means you don't care about everyone else's code, in particular the whole base system. 1000+ code-chunks in the tree use "stdio" (or something else slightly more) for normal operation, but don't need or want EVFILT_PROC access as a matter of course. So you think those 1000+ code-chunks should gain EVFILT_PROC ability, because it is convenient for your code. Result is if any of those code-chunks has a buffer overflow or means for code execution achievement, then it can observe all processes in the system. Basically, you desire that all pledge "stdio" processes can scan for the existance of all pid's by doing EVFILT_PROC attempts. YES, that is exactly what you want, I am not mincing words! Basically you want to undo the annotation/safety of pledge, because you haven't thought things through. Like, you'd be OK if a bug in the sshd pre-auth sandbox allowed such an operation? > If it is, shouldn't a task manager be run as root to see when a root > process dies? That has nothing to do with pledge. If you want to ask an entirely seperate question, ask it in a seperate email.
