Sending signals to sandboxed processes

Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Sending signals to sandboxed processes

Thomas Leonard-3
Is there any way to send a signal (e.g. SIGTERM) to a plash process
from outside the sandbox?

Sending signals via the tty (^C etc) works fine, but sending using
kill(2) doesn't seem to be possible (presumably because all the uids
are different).

You can kill the server process, which will usually kill the child
process next time it tries to open a file.

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?

Thanks,


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


_______________________________________________
Plash mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/plash
Reply | Threaded
Open this post in threaded view
|

Re: Sending signals to sandboxed processes

Mark Seaborn-2
Thomas Leonard <[hidden email]> 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.

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?

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.

Mark


_______________________________________________
Plash mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/plash
Reply | Threaded
Open this post in threaded view
|

Sending signals to sandboxed processes

Thomas Leonard-3
On 12/14/06, Mark Seaborn <[hidden email]> wrote:
> Thomas Leonard <[hidden email]> 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


_______________________________________________
Plash mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/plash
Reply | Threaded
Open this post in threaded view
|

Re: Sending signals to sandboxed processes

Thomas Leonard-3
In reply to this post by Thomas Leonard-3
On 19 November 2006 20:40, Thomas Leonard <[hidden email]> wrote:
> Is there any way to send a signal (e.g. SIGTERM) to a plash process
> from outside the sandbox?
>
> Sending signals via the tty (^C etc) works fine, but sending using
> kill(2) doesn't seem to be possible (presumably because all the uids
> are different).

Would it be possible to use clone(2) with CLONE_NEWPID to get this behaviour?

Then the sandboxed processes would run with the same UID as the user,
but they can only send signals within the sandbox because PIDs are
unique to the sandbox. e.g. within the sandbox, the top-level process
is PID 1. Outside of the sandbox, it has a different PID and can be
killed by the user with no special privileges. This also allows
processes to see a restricted view of /proc.


--
Dr Thomas Leonard        http://0install.net/
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

_______________________________________________
Plash mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/plash
Reply | Threaded
Open this post in threaded view
|

Re: Sending signals to sandboxed processes

Thomas Leonard-3
On 13 February 2011 16:19, Thomas Leonard <[hidden email]> wrote:

> On 19 November 2006 20:40, Thomas Leonard <[hidden email]> wrote:
>> Is there any way to send a signal (e.g. SIGTERM) to a plash process
>> from outside the sandbox?
>>
>> Sending signals via the tty (^C etc) works fine, but sending using
>> kill(2) doesn't seem to be possible (presumably because all the uids
>> are different).
>
> Would it be possible to use clone(2) with CLONE_NEWPID to get this behaviour?
>
> Then the sandboxed processes would run with the same UID as the user,
> but they can only send signals within the sandbox because PIDs are
> unique to the sandbox. e.g. within the sandbox, the top-level process
> is PID 1. Outside of the sandbox, it has a different PID and can be
> killed by the user with no special privileges. This also allows
> processes to see a restricted view of /proc.

I see Linux 3.5 now lets processes restrict which system calls they can make:

"Seccomp-based system call filtering"

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/prctl/seccomp_filter.txt;hb=HEAD

Could this remove the need to run sandboxed processes as a different
user? If so, killing would work, fchmod would work, and we wouldn't
need the SUID helper either...


--
Dr Thomas Leonard        http://0install.net/
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

_______________________________________________
Plash mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/plash