> I am however curious to this patch. By pledging ksh with exec it appears > to me that once a pledged process is execve(2)d it looses it's already > made pledges.
Yes, because that is what it needs. > This to me seems like > something that might be undesirable (find remote code execution->insert > exec of application->do some evil network activity) > Is above observation correct or am I missing something? It is entirely desirable. It is what a shell does. It runs other programs. Hopefully those other programs are also self-pledging. You need to step back. The only alternative you leave with your suggestion is that a shell cannot start programs with full unix functionality. What kind of a system would that be? Here's what pledge does bring to the table though. Let's say a shell like ksh has a bug inside it. An attacker gets control of the guts of ksh. Now what can he do? Lots. But what can't he do. He can't open a socket. There's lots he can't do. He has to go through the exec path. Less choices. This means an attacker has to write more detailed attack code. Let's look at ASLR. What if the attacker can guess. Yes, ASLR is useless. Let's look at W^X, which is just a policy the programmer should follow, not a mandatory mapping rule by the kernel. Let's say there is a page is incorrectly labelled by the programmer. Game over. Right? Let's look at the stack protector. Some functions don't have enough bytes in their frame, so for performance reasons they are not protected. Game over, right? Except, keeping it real, each of these things are cheap, but added up in a large pile, they act as a mitigation. About 15 programs in the tree are using "proc exec", either because they are in an intentional shell, or because historically unix had lots of !command support. We'll also push back on this latter thing, to try to shrink the usage. But ksh is a shell, and so is tmux. nicm and I have other plans for tmux, but I doubt you'll ever see a privsep ksh.
