On Mon, Jul 25, 2016 at 02:23:00PM +0200, Maxime Villard wrote: > Le 24/07/2016 à 22:57, Joerg Sonnenberger a écrit : > > On Sun, Jul 24, 2016 at 01:09:46PM +0200, Maxime Villard wrote: > > > The goal of sysrestrict (and pledge, and whatever else) is not to provide > > > the > > > perfect feature that will control absolutely everything. The goal is just > > > to > > > provide an additionnal, simple layer of restriction. It is a combination > > > of > > > such features that can mostly reach the granularity you want. Sysrestrict > > > for > > > syscalls, UNIX file permissions for VFS, kauth for kernel permissions, > > > Veriexec > > > for binary permissions, etc. > > > > Frankly, I haven't seen many use cases for pledge so far that actually > > make sense. While I do see a certain sense in allowing a fully sandboxed > > process hierachy, that can already be obtained to a degree with ptrace. > > If you want to actually get something like this into the tree, you should > > start at the beginning. What problem is it trying to solve, why is that > > problem relevant and how does is it gotten solved? > > > > It's just obvious: we don't want ftpd to call modctl, or execve (even if it > currently does), or mount, or reboot, or swapctl, etc. And it gets solved > by restricting those syscalls.
You haven't answered my question. "I don't want to allow calls to foo" is not a problem. Let's ignore for a moment that the majority of your list is restricted to root and you have lost already in the UNIX security model if your code is running as root. What's the purpose of not allowing execve? In a sensible capability system (which pledge is not for exactly this reason), switching to a different binary is just another form of running arbitrary code. If you can do the latter already, the former doesn't gain you anything. But this is still a detail of the mechanism. It doesn't answer the fundamental question of what problem you are trying to solve. What attack is this mechanism supposed to prevent? Joerg
