Introduction: The Unseen Shield of Native Android Apps

In the complex ecosystem of Android, security is paramount. While Java and Kotlin layers benefit from Android’s robust sandbox, native code, often written in C/C++, presents a unique set of challenges and opportunities for both attackers and defenders. Native libraries, essential for performance-critical tasks, graphics rendering, and interacting directly with the Linux kernel, operate closer to the system’s core. This proximity, however, also means a larger attack surface.

Enter Seccomp-BPF (Secure Computing with Berkeley Packet Filter), a powerful Linux kernel feature that allows a process to define a strict policy regarding the system calls (syscalls) it is permitted to make. On Android, Seccomp-BPF acts as a vital last line of defense, sandboxing native applications by restricting their access to potentially dangerous kernel functions. This article will guide you through a hands-on lab, exploring how Seccomp-BPF works, demonstrating its exploitation through weak policies, and ultimately, showcasing how to implement strong Seccomp filters to harden your native Android applications.

Understanding Seccomp-BPF: The Kernel’s Gatekeeper

What is Seccomp?

Seccomp (Secure Computing mode) is a Linux kernel feature that limits the syscalls available to a process. When enabled, a process can only make a predefined set of syscalls, or it will be terminated. There are two primary modes:

• SECCOMP_MODE_STRICT: The most restrictive, allowing only read(), write(), _exit(), and sigreturn(). It’s rarely used due to its extreme limitations.
• SECCOMP_MODE_FILTER: This is where BPF comes in. It allows a process to install a custom filter program expressed in Berkeley Packet Filter (BPF) bytecode. This program inspects each syscall attempt and decides whether to allow it, deny it, or perform other actions (e.g., send a signal).

How BPF Filters Work

BPF filters are small, virtual machine programs executed by the kernel. For Seccomp, these programs examine the syscall number, arguments, and process context. Based on these, the filter returns one of several actions:

• SECCOMP_RET_ALLOW: Permit the syscall.
• SECCOMP_RET_KILL: Terminate the process immediately.
• SECCOMP_RET_TRAP: Send a SIGSYS signal to the process, allowing it to handle the violation.
• SECCOMP_RET_ERRNO: Return an error code (e.g., EPERM) without terminating.
• SECCOMP_RET_LOG: Log the syscall violation (Android-specific).

On Android, Seccomp is leveraged system-wide for critical services and can be adopted by individual applications to further reduce their attack surface, especially for native components. A properly configured Seccomp policy prevents attackers from using vulnerable native code to make unauthorized syscalls, such as spawning new processes (`execve`) or escalating privileges.

Setting Up Your Android Native Lab Environment

To follow along, you’ll need:

• An Android device or emulator with ADB access (root access is beneficial for debugging and exploring system-level Seccomp).
• Android Studio with NDK and CMake installed.
• A basic understanding of C/C++ and Android NDK development.

Project Setup

Create a new Android Native C++ project in Android Studio. The key files will be your CMakeLists.txt and the native C++ source file (e.g., native-lib.cpp).

CMakeLists.txt (for `native-lib.cpp`)

cmake_minimum_required(VERSION 3.22 FATAL_ERROR)project("seccomp_demo")add_library( # Sets the name of the library.  native-lib  # Sets the library as a shared library.  SHARED  # Provides a relative path to your source file(s).  src/main/cpp/native-lib.cpp)find_library( # Sets the name of the path variable.  log-lib  # Specifies the name of the NDK library that CMake should locate.  log)target_link_libraries( # Specifies the target library for which to add dependencies.  native-lib  # Links the target library to the log library  ${log-lib})

app/src/main/cpp/native-lib.cpp (Initial boilerplate)

#include #include extern "C" JNIEXPORT jstring JNICALLJava_com_example_seccomp_demo_MainActivity_stringFromJNI(  JNIEnv* env,  jobject /* this */) {    std::string hello = "Hello from C++";    return env->NewStringUTF(hello.c_str());}

Crafting and Applying a Seccomp Policy

Our goal is to create a filter that allows essential syscalls but blocks dangerous ones like execve, which can be used to execute arbitrary commands.

Defining the Seccomp Filter

Instead of manually writing BPF bytecode, which is complex and error-prone, we’ll conceptually define our filter and discuss its application. A full libseccomp integration for Android cross-compilation is beyond this article’s scope, but we can illustrate the core BPF structure and how it’s loaded.

A minimal, hardening Seccomp filter for an Android app might allow:

• __NR_exit_group, __NR_exit
• __NR_read, __NR_write
• __NR_openat, __NR_close
• __NR_mmap, __NR_munmap, __NR_mprotect
• __NR_futex, __NR_set_tid_address, __NR_brk
• And many more required for standard library functions, IPC, and threading.

It would explicitly deny:

• __NR_execve, __NR_execveat (for spawning processes)
• __NR_reboot (system control)
• __NR_ptrace (debugging/process introspection)

For demonstration, let’s create a very strict filter and observe its effect:

app/src/main/cpp/native-lib.cpp (with Seccomp)

#include #include #include #include #include #include #include  // For __NR_* macros#include       // For execve#define  LOG_TAG    "SeccompDemo"#define  LOGI(...)  __android_log_print(ANDROID_LOG_INFO,LOG_TAG,__VA_ARGS__)#define  LOGE(...)  __android_log_print(ANDROID_LOG_ERROR,LOG_TAG,__VA_ARGS__)// Define a minimal BPF filter that allows exit_group and write, blocks execve.struct sock_filter seccomp_filter[] = {    // Load architecture (optional but good practice for portability/robustness)    BPF_STMT(BPF_LD+BPF_W+BPF_ABS, offsetof(struct seccomp_data, arch)),    // Example for ARM64. Adjust as needed for your target architecture.    // BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, AUDIT_ARCH_AARCH64, 1, 0),    // BPF_STMT(BPF_RET+BPF_K, SECCOMP_RET_KILL), // Kill if wrong arch (can be removed for simpler demo)    // Load syscall number    BPF_STMT(BPF_LD+BPF_W+BPF_ABS, offsetof(struct seccomp_data, nr)),    // Allow __NR_exit_group    BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, __NR_exit_group, 0, 1), BPF_STMT(BPF_RET+BPF_K, SECCOMP_RET_ALLOW),    // Allow __NR_write    BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, __NR_write, 0, 1), BPF_STMT(BPF_RET+BPF_K, SECCOMP_RET_ALLOW),    // Deny __NR_execve    BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, __NR_execve, 0, 1), BPF_STMT(BPF_RET+BPF_K, SECCOMP_RET_KILL),    // Default: Kill any other syscall    BPF_STMT(BPF_RET+BPF_K, SECCOMP_RET_KILL),};struct sock_fprog seccomp_prog = {    .len = (unsigned short)(sizeof(seccomp_filter)/sizeof(seccomp_filter[0])),    .filter = seccomp_filter,};void apply_seccomp_filter() {    if (prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, &seccomp_prog) == -1) {        LOGE("Failed to apply seccomp filter: %s", strerror(errno));        // Depending on your app's criticality, you might want to exit here.    } else {        LOGI("Seccomp filter applied successfully.");    }}extern "C" JNIEXPORT jstring JNICALLJava_com_example_seccomp_demo_MainActivity_stringFromJNI(  JNIEnv* env,  jobject /* this */) {    // Apply the filter early in your native code's lifecycle    apply_seccomp_filter();    // Attempt a benign operation    LOGI("Attempting to write to stdout (allowed by filter).");    write(STDOUT_FILENO, "Hello from native C++n", 22);    // Attempt a forbidden operation    LOGI("Attempting to call execve (should be blocked).");    char* argv[] = { (char*)"/system/bin/id", NULL };    char* envp[] = { NULL };    if (execve("/system/bin/id", argv, envp) == -1) {        LOGI("execve failed as expected: %s", strerror(errno));    } else {        LOGE("execve unexpectedly succeeded!");    }    std::string hello = "Seccomp demo complete.";    return env->NewStringUTF(hello.c_str());}

Build and Run

Build and run your Android application. Observe the logcat output:

adb logcat -s SeccompDemo

You should see output similar to this:

I/SeccompDemo: Seccomp filter applied successfully.I/SeccompDemo: Attempting to write to stdout (allowed by filter).I/SeccompDemo: Attempting to call execve (should be blocked).I/SeccompDemo: execve failed as expected: Operation not permitted

The `Operation not permitted` error (EPERM) for `execve` indicates that our Seccomp filter successfully blocked the syscall. If the filter returned SECCOMP_RET_KILL for an `execve` attempt, the application would crash with a SIGSYS signal.

Exploiting Weak Seccomp Policies (or Lack Thereof)

In a real-world scenario, attackers don’t directly