Limiting syscall access for a Linux application

Assume a Linux binary foobar which has two different modes of operation:

• Mode A: A well-behaved mode in which syscalls a, b and c are used.
• Mode B: A things-gone-wrong mode in which syscalls a, b, c and d are used.

Syscalls a, b and c are harmless, whereas syscall d is potentially dangerous and could cause instability to the machine.

Assume further that which of the two modes the application runs is random: the application runs in mode A with probability 95 % and in mode B with probability 5 %. The application comes without source code so it cannot be modified, only run as-is.

I want to make sure that the application cannot execute syscall d. When executing syscall d the result should be either a NOOP or an immediate termination of the applicati开发者_运维技巧on.

How do I achieve that in a Linux environment?

Is the application linked statically?

If not, you may override some symbols, for example, let's redefine socket:

int socket(int domain, int type, int protocol)
{
        write(1,"Error\n",6);
        return -1;
}

Then build a shared library:

gcc -fPIC -shared test.c -o libtest.so

Let's run:

nc -l -p 6000

Ok.

And now:

$ LD_PRELOAD=./libtest.so nc -l -p 6000
Error
Can't get socket

What happens when you run with variable LD_PRELOAD=./libtest.so? It overrides with symbols defined in libtest.so over those defined in the C library.

It seems that systrace does exactly what you need. From the Wikipedia page:

An application is allowed to make only those system calls specified as permitted in the policy. If the application attempts to execute a system call that is not explicitly permitted an alarm gets raised.

This is one possible application of sandboxing (specifically, Rule-based Execution). One popular implementation is SELinux.

You will have to write the policy that corresponds to what you want to allow the process to do.

That's exactly what seccomp-bpf is for. See an example how to restrict access to syscalls.