Re: pledge(2) and exec
> 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.
pledge(2) and exec
On 10/10/15 02:10, Theo de Raadt wrote: CVSROOT:/cvs Module name:src Changes by: dera...@cvs.openbsd.org 2015/10/09 18:10:08 Modified files: bin/ksh: Makefile c_sh.c main.c distrib/special/ksh: Makefile Log message: ksh can run with pledge "stdio rpath wpath cpath getpw fattr proc exec tty" if the mknod builtin is disabled. It looks like a lot of abilities, but hey, this is a shell. can't open sockets or do other nasty stuff though. (we'll leave the mknod builtin enabled on the install media for now; there is work happening to regain the MAKEDEV performance in a different way) discussions with otto & millert in particular Hello tech@, First of all thank you Theo and all the other OpenBSD developers for bringing tame^Wpledge into our lives. I think it's a great system for adding security to applications. 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. (how else could applications spawned from the shell and still get their network interaction going?) 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? Another option that would seem interesting to me is to be able to pledge new applications before they get executed. This would for instance allow to revoke proc/exec in doas(1) before it execs the final application itself. This would allow for something similar to the NOEXEC function from sudo. Since my vias[1] patch was dismissed and some don't seem to mind to run their editor (with shell capabilities) as another user it would seem only fitting to me that doas(1) would be able to revoke executing privileges from the editor before it is fired up, so not to be able to do whatever we please as the user running the editor. Is something like this in the pipeline? Let the record show that this mail is written out of ignorance and merely intended to get myself educated on the subject and to poke the bear to see it's (future) capabilities. Not to criticise, or to get mauled by said bear. Sincerely, Martijn van Duren [1] a new version against the latest doas is up at http://imperialat.at/vias.diff for the potential few actually using it.
Re: pledge(2) and exec
On Sat, Oct 10, 2015 at 08:17:13AM +0200, Martijn van Duren wrote: > 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. (how else could applications spawned from the shell and still get > their network interaction going?) 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's too early for this conversation. We're iteratively introducing pledge requests and refining them as we go. Right now, "exec" allows us to make progress in other areas and it's no worse than the default. We still have a lot of diffs left to commit and write. We'll come back to this and other parts of pledge.
