[Plash] Sending signals to sandboxed processes

[Thomas Leonard]

On 12/14/06, Mark Seaborn <address@hidden> wrote:
> Thomas Leonard <address@hidden> wrote:
>
> > I think perhaps I need a sandboxed process polling for a ".killed"
> > file, and then killing its whole process group if it finds one. Is
> > there an easier way?
>
> A similar approach, but without doing polling, would be to pass a pipe
> FD into the sandboxed process, and have it kill the process group when
> it receives a message via the pipe.

OK, that would be better that polling.

> It depends what you need it for, really.  Is it just for killing a
> test case that is taking too long, or is it for killing a malicious
> process?

I have two uses so far:

- Aborting a 0compile compilation when the user clicks on Cancel.

- Killing firefox when it hangs.

> Eventually I would like to switch to using a ptrace()-based monitor
> rather than doing setuid() for the sandboxed process.  That would not
> have this problem with sending signals.

I have an idea there are some kernel patches floating around that let
you disable certain system calls. One only allowed
read/write/exit_group/sbrk for example, I think (can't find it now).
With the addition of fork(), recvmsg(), etc would that work for plash?

That could remove the need to make plash setuid (on Linux anyway)...


--
Dr Thomas Leonard               http://rox.sourceforge.net
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1