tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: FWIW: sysrestrict



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


Home | Main Index | Thread Index | Old Index